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.
Subject:Re: The Agile / Xtreme TW From:John Garison <john -at- garisons -dot- com> To:Tara Charter <chartertmc -at- yahoo -dot- com> Date:Sun, 08 Feb 2009 20:37:33 -0500
I haven't worked in a full Agile environment, but worked for 6 years in
an environment that had a lot of agile components and an agile
philosophy. I followed my usual process of developing documentation:
John's Swamp Analogy Methodology (TM)
The goal is to drain the swamp and map the dry land. On day one, the
plug at the bottom of the swamp is pulled, and the water level begins to
fall. Since it's not a perfect world, some places become dry land sooner
than others. Having done a general topological assessment before things
started, I know where the high ground is and verify that it dries up
early one, and make the map. I also know where the pits are, and I
periodically check them to see if they have dried up enough for me to
survey and start mapping. The code is the dry land - as it appears, it's
ready to be mapped/documented. Since it's not a perfect world, you have
to verify the map even after things are "done" just to make sure that
they haven't changed. As with most projects, some features pretty much
cannot change, but other things remain volatile until the end; indeed,
they may not dry up in time and become the areas at the edge of the map
that are cut at the last minute to meet the release date.
My 2¢ ... it works for me.
John Garison
Tara Charter said the following on 2/7/2009 3:48 PM:
> The transcript refers to 'user docs' - as 'risky if you do it too early' - - I've written user docs in parallel on Agile projects and it isn't any more risky than writing code too early - Agile iterations create usable software - usable software translates to usable user docs. But TWs have always worked in an iterative fashion, and in an agile manner (independently thinking through the tasks at hand, selecting one, without governance, finishing it, going to the next one). And so, I think that Agile is not new to technical writing at all. I think the Agile development community could relate to what TWs have been doing all along.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
