Providing Value with Lean

Posted on March 31, 2008 by admin

While I haven't been blogging much over the winter, I wasn't entirely idle. I co-authored two important papers. The second of which is the forthcoming Technical Note from the SEI entitled "CMMI and Agile: Why not embrace both?" with Mike Konrad, Hillel Glazer and Jeff Dalton [More on this when the SEI publishes it.] The first is an academic paper that appeared in the Journal of Software Process: Improvement and Practice, co-authored with Merwan Mehta and David Raffo "Providing Value to Customers in Software Development Through Lean Principles." [Unfortunately, this paper though available online is a download from Wiley, both the journal subscription and the paper re-print are very expensive. If you have an interest in this paper, send me an email.]

I'm very pleased with both of these papers. The co-authoring experience in both cases was very enjoyable and rewarding. The outcomes were superior to anything I might have written on my own.

There are many lessons in the Lean paper, but perhaps the most important is this message...

Value first, then flow, then waste reduction/elimination

Too often I see Lean being taught as "the elimination of waste" when in fact waste reduction is a tertiary concern. While waste elimination is important, waste should not be reduced in detriment to flow, and smooth flow can be sacrificed to improve value delivery.

So for example, a queue in a kanban system can be considered as waste (probably necessary waste). As queues are a type of waste, it makes sense to reduce or eliminate queues. I see this advice coming from others who talk about Lean in software development.

However, it is important to understand why the queue is there. It is there to absorb variation in size and complexity of work items or in the availability of someone to process those work items. If you reduce the size of the queue or eliminate it altogether, it may impeded the smooth flow of the system, causing a stop-go effect, lowering the overall throughput of the process.

For example, (and I talk about this when I present kanban at conferences) at Corbis we had a non-instant availability bottleneck in build engineering, due to the time-slicing (multi-tasking) required of the build engineers. As a result, we increased the size of the queue in front of build engineering in order to smooth the flow through the whole system. In this example, the variability comes from the availability (or lack thereof) of the resource, not from the sizing of the work items. So we increased the amount of "waste" in the system to smooth flow and increase throughput.

It is also known that expediting is bad. Expediting impedes flow and causes WIP to increase and lead times to lengthen. We have demonstrated this empirically with the kanban implementations we've done so far. If we are to focus on smooth flow we would never expedite.

However, this general rule would be wrong. Occasionally there will be times where an expedite request carries a very high monetary value. The impact on flow and WIP and lead times to other items in progress is outweighed by the monetary benefit of accepting the expedite request. Hence, it makes sense to pursue the value in the expedite request despite its impact on flow and its introduction of waste in the system.

Hence, value trumps flow and flow trumps waste elimination in all process operation and process improvement decisions. 

Comments: