Lean Software Development – 1

This post was partly inspired by Mary & Tom Poppendieck, who are experts in Lean Software Development.

It was also inspired by an inquiry. So, I wanted to talk some about Lean. Specifically, about waste, which is known as muda in Japanese.

Earlier I posted about waste. This is a different perspective on the same basic subject.

Those who know Lean manufacturing know that Shigeo Shingo defined the Seven Wastes for manufacturing (derived from his work at Toyota). (Well, some say Taiichi Ohno identified them. Oh well.)  The Poppendiecks have defined the Seven Wastes of software development:

Manufacturing	Software Development
In-Process Inventory	Partially Done Work
Over-Production	Extra Features
Extra Processing	Relearning
Transportation	Handoffs
Motion	Task Switching
Waiting	Delays
Defects	Defects

Some of them are obvious, some maybe not.

Let’s take the first row. What is partially done work?

The Poppendiecks identify several examples:

• Uncoded documentation
• Unsynchronized code
• Untested code
• Undocumented code (if documentation will be needed; usually some will be needed in my experience)
• Undeployed code

In fact, any work done prior to receiving the business benefits of the deployed software is “partially done work.”

Why is this waste? After all, from an accounting point of view, this is “inventory,” which is an asset. Right? (And so thought the auto industry for the longest time.)

But, if we imagine undelivered ‘finished inventory’ (a completed car on Toyota’s lot) what good can happen with or to partially done work? (My answer: Almost nothing.)

And what bad can happen to partially done work? Lots.

Every minute it is undeployed is a minute the customer is left unsatisfied. With time, the customer’s needs may also change. Ever happen to you? I would bet it has.

We lose our knowledge and understanding of that unfinished work. (What’s the half-life of our memory of a Requirements Doc, when we have worked on two more in the meantime?) People lose it, it gets harmed. We have to do Task Switching to come back to it.

Further, thousands of dollars have been invested in that unfinished work, which often can’t even be shown to the customer. The firm has to fund that investment, and the customer loses confidence that the development team can produce anything worthwhile.

The development team is unsure — how near finished is it, really? You have a guess, but nothing beats getting the ball over the goal line (oops, football metaphor, wrong season).

“But, but, but,” you complain, “I must have some partially done work.” Yes, indeed the team must. So, the goal is to limit that waste to the smallest amount possible. An example that might fit your situation: Only one story in-flight at a time.

More on waste later.

« « Agile is not like golf || The Elements of Agile Style – 2 » »