The flavor of the day; was: Agile development, user stories, etc.

[David Neeley <dbneeley -at- gmail -dot- com>]

Over the years, I have observed many times that there are a precious few who
embrace new methods with insight and understanding--and who often benefit
hugely from doing so.

There are many others, though, that apply these methodologies with little
insight. These types often simply want to be thought of as "cool" or
"cutting edge"--but they often create frustration at the very least, both in
their organization and, too often, among their customers.

An insightful manager, for example, will assure that the entire team
understands both why and how a new methodology is to be applied, and how to
contribute to the team's success in doing so.

The others will create utter chaos.

For example, use cases (apparently now called "user stories") can be useful
tools if well crafted with true understanding of users and their needs.
Applying them by rote, however, and they are mostly useless.

I think I have related before how I was given an engineering document
created by an application engineer in India (meaning communication was very
difficult at best). It had six so-called use cases that were confusing, to
put it mildly. Each was accompanied by a flow chart, even. It took me three
days, and countless iterations on a white board, to finally understand just
what the engineer was trying to say.

In the end, I reduced the flow charts from six to one, with four simple
elements and about a half page of explanation. This was for a new feature in
the software for an electronic telecom switch. The engineers responsible for
early adopter implementation went out of their way to let me know that they
finally understood what the new feature was intended to do after they saw my
documentation--they had been given a copy of the engineering document at the
same time I had, and hadn't been able to figure it out.

As a result, I was asked for by name for a new and upcoming project.
Unfortunately, that was right before I was laid off in the mass downsizing
that hit Nortel at that time. The point is, though, that use cases may not
be a boon at all unless they are carefully crafted by people who understand
the users and who communicate that understanding clearly.

Thus, blindly imposing any technique or methodology is too often to court
disaster.

Where the tech writer can help in these cases is to aid in the communication
of this kind of detail among the developers and between all parties
involved--management, developers, support staff, and customers.

Thinking that our roles are limited to finished documentation is often to
shortchange the valuable contributions we can make to the success of the
process.

David
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Are you looking for one documentation tool that does it all? Author, 
build, test, and publish your Help files with just one easy-to-use tool.
Try the latest Doc-To-Help 2009 v3 risk-free for 30-days at:
http://www.doctohelp.com/ 

Help & Manual 5: The all-in-one help authoring tool. True single- sourcing -- 
generate 8 different formats and as many different versions as you need 
from just one project. Fast and intuitive.  http://www.helpandmanual.com/

---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -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%40web.techwr-l.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/ for more resources and info. 

Please move off-topic discussions to the Chat list, at:
http://lists.techwr-l.com/mailman/listinfo/techwr-l-chat