Re: The Technical Writer vs. Agile Development Methodologies

["A" <aurora -at- identicloak -dot- com>]

Kevin McGowan said:
> Hi all,
>
> 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.
>
> 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.

I've been through it. The people that tout Agile methodology are
locked in a box with very little oxygen. As a result, they promote
assinine concepts like designing very complex software (think: 10,000
lines of code) on the back of flash cards. That's satirical, but not
by much.

Y'see, Agile works for small-to-medium-sized programs where the
customer is readily available and willing to participate. Can you see
the narrowing sets of circumstances that this technique works in? If
so, you're ten miles ahead of most managers. The problem is that
managers latch on to some fashionable, hyped idea without really
seeing if their department, or the project is suited for the task.
That's another thing about Agile -- it requires a whole culture change
to be truly effective. Most managers can't pull that off. Most
companies are not that committed.

I didn't have to do much. When it became obvious that the managers
couldn't create a sea-change in the culture, the whole agile concept
fizzled out. Yes, the developers were reorganized and we all played
musical chairs. Yes, new terms and concepts were bandied about. But
when it all came down to it, the schedule was still written in stone.
All I had to do was sit tight and watch upper management create
schedules so that they could get their bonuses. That, in turn,
translated into the software being made as it always was, and the docs
being made as they always were.

Sit tight. The fallacy of Agile is that software can be made so that
it requires no documentation. Even if it were 100% intuitive
(impossible), it'd still docs that instead of describing the
interface, describe how to use the tool to do something specific. So
at the worst, the kind of documentation you'll write will change, but
even that stands about a 0% chance of happening. :>

A.u.r.o.r.a

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

Doc-To-Help includes a one-click RoboHelp project converter. It's that easy.  Watch the demo at http://www.componentone.com/TECHWRL/DocToHelp2005

---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot- 

To unsubscribe send a blank email to 
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40infoinfocus.com

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.