Re: Agile, SCRUM and Technical Writing
After the project is judged a success or not, and after you've decided if it had a good team and insight or not, then you could try to use the results to explain what was happening, even if the sample turned out to be all not-good teams having not-good insight.
I have never seen what I thought was a "good team" with "good insight"
that did not at least *try* to write down what the product they were
starting to develop was supposed to do, and have seen no successful
products that came out of teams with "poor" insight.
Another after-the-fact document is the specification that gets written after product development is completed. A dev manager once candidly explained these to me: How could they possibly know what the specification of the final product is, unless the product is already finished?
There is a difference between a development spec that describes
to your team what they are trying to do (eyes on the prize and all
that) and a product spec that describes to your prospective buyers
what the finished effort looks like.
I think that if you boiled down all of the variations on this theme, you'd end up with the idea that they're working on an evolving prototype that will change (and probably a lot). I also suspect that this is another way of saying 'good team but no insight.'
Rigidly hewing to your original requirements without making the
occaisional adjustment to allow for things you discover were just
a bit too ambitious, or to changes that occur in your target market
as your work progresses is probably almost as bad a mistake as
jumping feet first into a project without some sort of roadmap
that says where you're trying to go. I would expect a good project's requirements documents to have been revised numerous times along the way to product completion, but with review and buy-in from the various stakeholders, unlike the chaos model of development where the end result often has little to do with what was originally conceived and nobody quite knows how they ended
up where they did.
Gene Kim-Eng
"Do you feel you've learnt by your mistakes here?"
"I think I have, yes, and I think I can probably repeat them almost perfectly."
Peter Cook & Dudley Moore, "The Frog and Peach"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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-
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:
- Re: Agile, SCRUM and Technical Writing, Ned Bedinger
References:
Agile, SCRUM and Technical Writing: From: Gillespie, Terilyn
Re: Agile, SCRUM and Technical Writing: From: Gene Kim-Eng
Re: Agile, SCRUM and Technical Writing: From: Peter Neilson
Re: Agile, SCRUM and Technical Writing: From: Ned Bedinger
Previous by Author:
Re: Writing test Fridays
Next by Author:
Re: Technology Product Managers (was Re: Writing test Fridays)
Previous by Thread:
Re: Agile, SCRUM and Technical Writing
Next by Thread:
Re: Agile, SCRUM and Technical Writing
Search our Technical Writing Archives & Magazine
Visit TechWhirl's Other Sites
Sponsored Ads