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?

November 25, 2009

November Scrub Club – Scrum and Kanban

Filed under: Uncategorized — heratech @ 12:45 pm
Tags: , , ,

Bulletin board with post it notesLast Thursday night’s Nashua Scrum Club introduced me to yet another new software development term.  Kanban.  The speaker was Damon Poole, who spoke on the topic “Scrum and Kanban, Chocolate and Peanut Butter?”

Since I’d never heard the term Kanban before, I hit Wikipedia before the meeting to look it up.  But only ended up confused about how a manufacturing process applied to software development? 

After the meeting, it seems that the answer is not so much kanban, but “lean software development.”

I only took a few notes, mostly listening and trying to understand what was, for me, a new concept.  Damon started out giving a brief overview of Agile (which was useful for the majority of the audience, who were not working in an Agile environment).  Then he talked a little bit about Lean.  My notes say “providing value” and “continuous improvement”.  Aha,  I know that one, kaizen!   He mentioned 14 critical mass Agile practices, but I was only able to scribble down five before he flipped to the next slide.  I do hope that the slide deck is posted online at some point.

The next part of his talk focused on process.  He had some color coded slides that showed several iterations, with Development doing their work during one iteration, and QA doing the testing during the next iteration.  My notes say “This is not Agile.”

He talked a bit about how to break down large stories into smaller ones by listing the tasks, and then determining the critical tasks and the dependencies between them.  He had some great slides for this, which I appreciated, because I’m a visual learner.  And I was grateful that when he talked about workflow that he included Documentation (Specify > Design > Code > Unit Test > Integration/Doc > Testing) because so many people seem to forget or ignore Doc when talking about Agile.

Then there were color coded slides, showing several small stories being worked on during several different sprints and showing how there were bits of downtime for the testers while they waited for the code.  Then he had a rather spiffy animation that removed the lines indicating the iterations, and sliding the testing tasks right up to match the coding tasks.  “Getting rid of the iteration fills the gaps between coding and testing.”

He talked about decoupling the tasks of Agile from the iteration/Sprint.  Backlog grooming can happen anytime.  Story point estimating can happen anytime.  These tasks can be decoupled from the Retrospective or the Planning phase of a Sprint.  “Done” is decoupled.  Done is no longer the end of the iteration, but the end of the story.  And when you’re finished with a story, you pull the next story off the top of the backlog and start working on that.  He also talked about a Work In Progress (WIP) limit, that no more than X story points could be in progress at any one time.  During the Q & A someone asked when you demo?  His answer was not every time you finish a story (which might be every day or two) but when it makes sense to the team.

Damon finished his talk with a list of Lean and Kanban concepts that he thinks can be applied to Agile:

  • Decoupling
  • Lean thinking
  • One piece flow
  • Work in Progress limits
  • Eliminating waste


Related Blog posts that I found while researching Kanban:

Defining Kanban

Between kanban and pair programming lies the feature brigade

Related Books:

Do It Yourself Agile by Damon Poole – Free download!

Lean Software Development by Mary and Tom Poppendieck

Blog at WordPress.com.