Posts
We started working in
an Agile way last year. We began with classroom training and
workshops, then retained the instructor on an as-needed basis for
coaching. We also implemented a web-based tool called Jira, not only
for tracking issues, but to record our planned features (defined as
epics and stories), set tasks for sprints, estimate points, and track
our velocity. In all of this, I (the lone technical communicator),
have been treated like one of the developers. I’m part of the
sprint planning meetings, retrospectives, and daily stand-ups.
We are still trying out
new processes and procedures when it comes to developing a product,
and although we’ve called our way of working “Agile”, our
manager is committed to doing what works, whether it’s Agile or
not. Agile evangelists will tell you that Agile isn’t really a
methodology with a rigid set of procedures; it’s really a set of
values and principles that guide you to make the best decisions about
how you work. As a result, no two companies working “Agile” are
going to do exactly the same thing. In fact, right now, no two groups
are doing the same thing either, so I will describe what two of the
teams are doing.
Team A is working on a
new product, so the documentation is being developed from scratch. We
created an outline at the beginning of the project because we had a
good idea of what all the features would eventually be, and we still
had to estimate resources and schedule, so I needed an idea of the
page count. From this outline, I created a skeleton document in
FrameMaker with all the subheadings that I knew of at the time. As
the developers add new features, they are documenting them directly
in the manual. In fact, they cannot consider their task closed until
it is also documented, or a new task is opened to do the
documentation (but most of the time the documentation is quicker to
do than to create a new issue in Jira and then do it, so they just do
it). I then become one of the reviewers for the issue, except I’m
reviewing the documentation instead of the code. I’ve been doing
the usual checks for grammar, clarity, consistency, conciseness,
accuracy (I can also try out the feature), sometimes on a change that
is as small as a sentence.
We have still allotted
time for a complete edit and technical review of the manual when all
the features are done (or mostly done), but we expect that the
editing and technical review should take considerably less time than
if we weren’t doing that on a continuous basis.
Yes, there has been and
will be rework because the features change. Sometimes they are
reworked because of feedback from our users or the product manager.
But the documentation that is released with the product at the end of
every sprint is matches that release, or at most, is one sprint
behind.
Team B was working on
an update to an existing product. Our tasks were defined by bugs and
new features that were entered in Jira. If a new feature required
documenting, we had to add a task for it, define the work and
estimate it. There were dependencies: we had to know that a feature
would be included before I could document it, but it didn’t have to
be finished before I could start. Several times, the developer ran
into problems, delaying the completion of a feature, but we agreed as
a team that I could go ahead and document the way it was going to
work. Yes, sometimes I had to adjust the documentation again, but it
kept us moving forward and avoided the “do everything in the last
two weeks” scenario that usually befalls the technical
communicator.
After
working Agile for about seven months, I have to say that I prefer it
to the old Waterfall method. Mostly I appreciate the constant flow of
communication: the daily stand-ups, sprint planning and
retrospectives. It’s forced us to really think about how we work
and how we can do better. It keeps me up-to-date on all the
development work; no one has to remember to tell me about a new
feature or change that needs documenting because that communication
is part of the process. It also gives me an opportunity to make
suggestions about how the product works every time they’re working
on a new fature.
Agile isn’t necessarily less work, with all the
meetings and rework, but it prevents the massive crunch at the end,
and it helps to control management’s expectations because they can
get a progress report every two weeks. It also helps us to produce a
better product because the constant feedback from customers or those
who represent the customers, including me. We haven’t quite settled
on the best way to do everything yet, but in true Agile style, we’re
willing to keep trying and changing.
No comments:
Post a Comment