Re: Agile, SCRUM and Technical Writing

Subject: Re: Agile, SCRUM and Technical Writing
From: "Tlyn" <terilyn -dot- gillespie -at- ddiworld -dot- com>
To: "Peter Neilson" <neilson -at- windstream -dot- net>
Date: Fri, 16 Feb 2007 11:22:13 -0800

OK, I really don't expect anyone on this list to agree with the
aforementioned "research" telling us that comprehensive requirements
and functional specs are overkill; afterall, that's what many of us
"do".

What would be more useful to me would be hearing from writers who have/
are currently working with an Agile methodology, again, in terms of
how this may be affecting your writing tasks/products, function on the
team, successes/failures, etc. Has the switch to agile changed how
you "do" documentation? Thanks.

Terilyn


On Feb 16, 2:09 pm, Peter Neilson <neil -dot- -dot- -dot- -at- windstream -dot- net> wrote:
> Lemme try to think through what might be going on here. We can divide
> software projects up into various binary categories:
>
> 1(a/b). Have (or do not have) a good insight on a product and a good team.
> 2(a/b). Perform (or do not perform) early documentation of plans and
> designs.
> 3(a/b). Produce (or do not produce) a successful product.
>
> 1b rarely leads to 3a, I'm sure, regardless of what is done with 2.
> Including a large number of badly conceived projects in a study will
> indeed show that documentation efforts do not help. "You can't wash
> sh*t," as a fellow TW once said.
>
> So a proper study on the effectiveness of early documentation should
> focus mostly on projects that were started by experienced and/or
> cohesive teams working towards a reasonably well understood goal. But
> how would one select those, the "1a" subgroup, from the entire 1a+1b?
> How could one tell which is which?
>
> The only way that I could imagine is by reading the planning and process
> documents. Those are hard to come by for successful projects, because
> they are generally proprietary. For failed projects they (if any) are
> either going to be pieces of crap that are part of the failure, or
> after-the-fact memoranda that show why someone else was to blame for the
> failure. Once in a while they might be gold that was set aside in a vain
> attempt to use the precious dross.
>
> What have I come up with? Am I right, or am I instead all out of focus,
> or involved in petitio principii, or perhaps merely echoing someone
> else's much more erudite and well constructed research?


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

Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList

Now shipping: Help &amp; Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help &amp; Manual: http://www.helpandmanual.com

---
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 admin -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.


Follow-Ups:

References:
Agile, SCRUM and Technical Writing: From: Gillespie, Terilyn
Re: Agile, SCRUM and Technical Writing: From: Gene Kim-Eng

Previous by Author: Re: Translation Services
Next by Author: RE:
Previous by Thread: RE: Agile, SCRUM and Technical Writing
Next by Thread: RE: Agile, SCRUM and Technical Writing


What this post helpful? Share it with friends and colleagues:


Sponsored Ads