Re: User Documentation in Agile Development Teams

Subject: Re: User Documentation in Agile Development Teams
From: "Peter Neilson" <neilson -at- windstream -dot- net>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Fri, 24 Mar 2017 11:41:11 -0400

Fundamentally this is a high-level management issue. The underlying idea is that no money at all needs to be spent on documentation. It's been a recurring theme for decades, and what you see pushed forward as "Agile" is merely the latest incarnation. In the manufacturing business the problem is called "flavor of the month" and it's always some new scheme for reducing costs, such as "just in time," that is going to result in inexorable and possibly catastrophic failure.

Here's just one sample: The extruder had a half-million dollar pump screw, and they always kept two on hand. My wife watched as management eliminated the standing orders for them, believing that they could order a new one as needed. Lead time for the custom-made screw was six months. The cost of the ensuing down-time was far greater than that of tying up a million dollars in "unnecessary" spare parts.

Attitude from the shop floor, concerning each month's new flavor, was, "Just do your job, guys. We've seen 'em come, we've seen 'em go."

Your management and THEIR management need to see the wider picture. It's hard to push up from the bottom, and your very best option is to try to have your exit strategy in place for whenever you need it.

For your more immediate concern, it would not hurt to have e-mails from disgruntled customers, ten or twenty of them. Have them printed out. The folks who make the decisions STILL don't read anything unless it's printed on paper. Bring to meeting.

On Fri, 24 Mar 2017 10:40:04 -0400, Sue McKinney <smckinn2001 -at- gmail -dot- com> wrote:

I am a long-time tech writer very familiar with Waterfall development and
am now getting familiar with Agile. I understand the idea behind lean
documentation for what I call "back-end" documentation (e.g., requirements,
user stories, design) but am trying to learn more about getting end user
documentation into the development cycle. It's tough, given the frequent
releases, and I now am faced with push-back from managers and developers
claiming that documentation is way less important in Agile. In fact, it's
just as important! Even though the software is supposed to "intuitive,"
we're finding out that users want assistance; we're in the middle of
creating online help for a second release of something that was deemed
intuitive enough to not require online help for the first release. And
then, of course, users complained about not know how to get their work
done. I'm looking for ways to identify best practices for user
documentation (online help, user guides) to present to management so that
the new writer alone on a project has more credibility when he or she
argues in favor of, say, online help.
Visit TechWhirl for the latest on content technology, content strategy and content development |


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-leave -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at

Looking for the archived Techwr-l email discussions? Search our public email archives @

User Documentation in Agile Development Teams: From: Sue McKinney

Previous by Author: Re: Managed Services
Next by Author: Re: A question for the list in general
Previous by Thread: Re: User Documentation in Agile Development Teams
Next by Thread: RE: User Documentation in Agile Development Teams

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

Sponsored Ads