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.
How Do You Decide How Long Things Will Take (in a SCRUM Shop)?
Subject:How Do You Decide How Long Things Will Take (in a SCRUM Shop)? From:Geoff Hart <ghart -at- videotron -dot- ca> To:TECHWR-L Writing <techwr-l -at- lists -dot- techwr-l -dot- com>, Yannia Vodrovich <coralfire -at- rocketmail -dot- com> Date:Wed, 17 Jun 2009 14:57:31 -0400
Yannia Vodrovich describes the predictable chaos that arises in Agile
shops where no specific provisions are made for the writing: <<The
difficulties are obvious: I don't always know (1) how thorough the
documentation is that is already there. Sometimes I can go look and
figure it out, sometimes I can't as there is not enough time to dig or
it is not obvious as there is topic overlap; (2) I am just learning
the software which is moderately complex to complex; and (3) there are
intervening things that come up, as do things at any job, and being
new (2.5 months) I don't totally have a feel for that either.>>
I think it was Sue Gallagher who was famed in the early days of techwr-
l for her statement that "the documentation will be ready 2 weeks
after you freeze the interface". That's probably the best answer for a
micromanager who wants to know how long it will take. Point out
cheerfully that this statement applies to the documentation for each
chunk of the code, not for the software as a whole, and that you might
be able to squeeze it down to 1 week per chunk if they can guarantee
quick turnaround time reviewing and approving the docs.
When the micromanager screams, point out that there's a good reason
nobody builds houses, battleships, or factories using Agile methods,
nor will they ever: they recognize that you must design the human
interface and overall flow of a product first, make sure that it works
for the users, and only then do you figure out how to actually
implement the design. IMHO, that's the Achilles heel of (poorly
implemented? all?) Agile-like methods: they assume that the interface
will eventually evolve into something usable, rather than designing it
to be usable right from the start.
In practice, the interface design is the easy part; it's the coding
that makes the interface work that can drive programmers (and the
eventual users) mad with developing and debugging algorithms. It's
certainly true that the interface may evolve slightly as you gain more
experience with the users and how they will use your product. But if
you made an honest effort to learn this before you started the
programming, the changes should be relatively minor.
A good way to sell this approach would be the following: Point out
that the user interface can stabilize fairly quickly, and as soon as
it does, you can start documenting it. And once the interface is
stable, they can tear out and redesign the plumbing (revise the
underlying code) as often as they want without affecting your work in
the slightest, which means that your work (documenting the interface)
will be finished before their work. They won't like it, but they will
like the fact that the documentation will be ready before the product
is ready to ship instead of 2 weeks later.
Some time in the next month, I'm planning to read and review the
following book: "Designing for the digital age: how to create human-
centered products and services" (Kim Goodwin, 2009, Wiley books). If
it follows logically from the other books produced by the Cooper
Design people, it will describe a process much like what I've proposed
here, which should give it some credibility among your managers.
------------------------------------------------------------------------
Geoff Hart (www.geoff-hart.com)
ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
------------------------------------------------------------------------
Effective Onscreen Editing: http://www.geoff-hart.com/books/eoe/onscreen-book.htm
------------------------------------------------------------------------
Free Software Documentation Project Web Cast: Covers developing Table of
Contents, Context IDs, and Index, as well as Doc-To-Help
2009 tips, tricks, and best practices. http://www.doctohelp.com/SuperPages/Webcasts/
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-
