HeraTech

November 28, 2009

Lean Software Development – Eliminating Waste

Filed under: Uncategorized — heratech @ 1:20 pm
Tags: , , , , ,

Waste barrelI’m still digesting last week’s Nashua Scrum Club meeting. As a technical writer, one of my roles in the organization is to be a user advocate, so I’m pondering the concept that “everything not adding value to the Customer is considered waste.”

I’ve been fan of the concept of kaizen or continuous, incremental improvement, for a couple of years now. Now I can add to that muda, the Japanese term for an activity that is wasteful and doesn’t add value or is unproductive. I wish I’d been exposed to lean principles last spring when I was talking to my manager about how I wanted to handle documentation bugs.

When I was hired last October there was a pretty big backlog of documentation bugs because 1) the company had been without a technical writer for six months before I was hired and 2) the Support manager had recently had the members of the Support organization read through the entire doc set and enter bugs and enhancement requests.

Since I’m a lone writer, I would prefer that when someone finds a simple typo (misspelled word, missing punctuation) that they simply e-mail me so that I can correct it. This would lead to a very simple workflow:

1. Employee sends an e-mail to the technical writer.
2. Technical writer reads e-mail.
3. Technical writer opens document files and fixes typo.

This workflow can lead to a simple typo being fixed within a few minutes of it being found. As a fan of efficiency, this is my preferred method of dealing with typos. If someone e-mails me a problem that takes more than five minutes to fix, it makes sense to create a documentation issue to track the work on that issue (and to make sure that it doesn’t fall between the cracks and get lost in my inbox).

However, my manager wanted to track ALL documentation issues, no matter how small, in our issue tracking system. This leads to a workflow like the following:

1. Employee enters an issue. Note that not all of our employees have permissions to create issues in our system, so the employee may need to find someone else to enter the issue for them.
2. The issue has to be triaged by one or more managers, assigned a priority and a target release, and assigned to the technical writer.
3. When the writer receives the automated e-mail that the issue has been assigned to them, they may have to go to the issue tracking system to view the issue.
4. Writer opens the document file and fixes the typo.
5. Writer has to go back into the issue tracking system and change the issue status to “fixed” and then assign it to the QA manager. Because I don’t generate PDFs on a daily basis, this may not happen until days or weeks after I’ve actually fixed the typo.
6. QA manager assigns the issue to a QA tester to verify that the issue has been fixed. Sometimes this doesn’t happen until we are nearing a patch release, as the testers are testing code, not checking that typos have been corrected.
7. QA tester checks the documentation and closes the issue.

This was the workflow that we used at one of my previous jobs, where I was a member of a large doc group and the writer responsible for any particular document might change at the end of a release. But since I’m the only writer at my current job, and typos aren’t something that I need other members of the team to assist me in correcting, it doesn’t make sense to me to have so many people involved in verifying whether or not a word was spelled correctly or a period was added at the end of a sentence. Instead of a process that takes two people and five minutes, my manager wanted a process that involved at least seven people and could possibly take days or weeks to complete.

This just seems wasteful to me and not very Agile.

How do other lone writers, who don’t have peer reviewers or editors, handle editorial tasks? Especially in an Agile environment?

Advertisements

Blog at WordPress.com.