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.
Our department is in the process of implementing the SCRUM methodology
while modifying the organizational structure, too. I am attempting to
structure the system documentation (requirements, specifications, test
plans). I have been working through "Mastering the Requirements Process
Second Edition" by Suzanne Robertson and James Robertson (ISBN:
0596102097). They state that business use cases are the most effective
way to gather requirements in an agile environment. Our first
implementation of the SCRUM methodology had a more robust set of
requirements already begun, although not fully documented. As the
"sprints" were completed (We are currently on our third sprint, with the
next two already planned.), the content of those sprints organically
centered on business use cases.
Granted, we are early in our experience with agile development, but my
personal experience with it leads me to believe that comprehensive
requirements and functional specs are not overkill, but may not be
necessary prior to beginning development. Since I arrived at my job two
years ago, this is the third software development life cycle this
department has adopted. The latest, and the one for which my
documentation deliverables were designed, was a "feature/release"
methodology. For this new methodology, I am still investigating what my
writing tasks (I am the lone writer in the department.) and deliverables
are for each product. I am involved with the development team from the
initial planning of the first sprint, so I have some input into design
and usability. The jury is still out on whether we have successes or
failures, but we do have a "lessons learned" session at the end of each
sprint, and I am confident in our potential for success. Our initial
customer participants have responded well thus far. YMMV.
I hope this helps.
Darrell
-----Original Message-----
From: techwr-l-bounces+dzuerche=tva -dot- gov -at- lists -dot- techwr-l -dot- com
[mailto:techwr-l-bounces+dzuerche=tva -dot- gov -at- lists -dot- techwr-l -dot- com] On Behalf
Of Tlyn
Sent: Friday, February 16, 2007 2:22 PM
To: Peter Neilson
Cc: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: Re: Agile, SCRUM and Technical Writing
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 & 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 & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as dzuerche -at- tva -dot- gov -dot-
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 & 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 & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
