Learning Lean

I'm currently attending an online class on Lean development by Alan Shalloway of Net Objectives. In a previous blog entry, I reviewed an excellent book on Lean by Mary and Tom Poppendieck. After reading the book, I attended Alan's session on Lean at Agile 2008. I view this class as an opportunity to see how others are using Lean to get the most out of Agile.

In today's session we covered the basic tenets of Lean. Much of it involves thinking about the big picture. Don't optimize particular parts, optimize the whole. For example, creating a requirements document might be optimal for product management (they can focus on it and forget about it), but it isn't optimal for the system as a whole (much is lost and left to the developers to figure out). Instead do detailed requirements as you need them.

This goes to the concept of flow. Queues and other forms of delays are bad. Your goal is to eliminate / minimize them. Product requirements documents are an example of a queue. Flow maps very well to Agile techniques.

Respect people. When errors happen, fix the system (it is at fault), don't work around it. Short term, this will have additional cost. But longer term it will reduce costs. So for example, if you find a bug, figure out what caused the bug to occur and address that. One technique for root cause analysis is the five why's. Why did it occur? Because Jon didn't account for that case. Why didn't Jon account for it? Etc.

The process should support the team. The team should adjust the process to fit their needs (continuous improvement). Anything that isn't adding value (i.e., waste) should be reduced / eliminated. Management should facilitate. Continuous improvement maps well to retrospectives in Agile.

The last area we focused on was on value stream maps. In this, you map out all of the steps in a value stream (say from requesting a feature to being able to use it). For each step you identify the amount of time that step will take and the delay between steps. By adding these together for all the steps, you get the cycle time. By identifying which parts along the way are actually adding value, you can identify cycle efficiency. By minimizing cycle time and maximizing cycle efficiency, you're improving speed.

One really interesting point is that you should focus on improving quality and speed and not on cost. If you improve quality and speed, you will reduce cost (i.e., you get all three). If you focus on cost first, you'll end up reducing quality and speed. This is a very important point given today's economy.