TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
The Technical Writer vs. Agile Development Methodologies
Subject:The Technical Writer vs. Agile Development Methodologies From:Geoff Hart <ghart -at- videotron -dot- ca> To:TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>, Kevin McGowan <thatguy_80 -at- hotmail -dot- com> Date:Tue, 31 Jan 2006 14:41:54 -0500
Kevin McGowan wondered: <<Is anyone else out there struggling with a
development team determined to use Agile Development methodologies? I'm
trying to research on what the ideal role for the tech writer in all of
this Agile madness.>>
My limited understanding (all based on reading, not personal
experience*) is that the main flavor of this method, or at least the
recurring theme in a family of methods, is a focus on implementing
features in small, focused time periods. At the end of the various
iterations, you have something resembling the final feature and can
move on.
In theory, this means that you can largely ignore the process during
the iterative design and testing (unless you're fortunate enough to be
included in the design team), and can focus on the documentation only
after the feature is complete and the team moves on to the next
feature. This is kind of techwriter nerdvana--the elusive "interface
freeze" we so desire before we begin writing.
In practice, I'm given to understand that there are different flavors
of "agile" and that the process probably doesn't work this cleanly.
Among other things, programmers trained in "the old ways" may revert to
those ways under stress, particularly if their managers are also
old-school managers who don't understand the new process and simply
keep adding features and modifying old features just like they used to
do in "waterfall development"*.
* So named because it mimics the process of everybody diving into the
river, being swept over a series of waterfalls and dashed upon the
rocks below, then climbing out and repeating the process until nobody
is left alive, the company declares bankruptcy, or something vaguely
resembling the original design (battered by water and rocks) emerges
and is thrown at the unsuspecting user like a log being hurled off the
top of a high waterfall in a B movie.
<<In one of our courses, we actually had a trainer say something to the
effect that end-user docs aren't a concern in agile... I know that's
not exactly the best way to say it, but it seems that Agile methodology
may well be suffering with a bias (intentional or not) against the tech
writers who must keep up with all the Agile-ness to create end-user
documentation.>>
Is it possible that the trainer simply failed to correctly deliver the
message that the documentation is the final stage of each feature
implementation? Note also that the WikiPedia description does not
clearly distinguish between end-user documentation and code
documentation; I get the impression that your trainer may have been
referring to the code documentation, which is left to the end of the
process, when the feature is actually working, rather than being
started early on and constantly revised (or not) as the team rejiggers
the algorithms.
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
