Lean Software Development

A book review

I've just finished reading Lean Software Development, a book written by Mary and Tom Poppendieck that introduced the lean practices used in the manufacturing world to software development as an evolution of Agile methodologies.

Lean software development in general is still a new process, but the theories are solidly anchored by the manufacturers that have made it work for them. Toyota has introduced the kanban system and the "decide as late as possible" technique. 3M and the way they empower their teams. The Theory of Constraints which is used, incidentally, at the company I work for.

What Mary and Tom did was to translate every good practice to the software world. But because of the novelty of the approach, there are very few examples in the book of the lean techniques as applied to software development. Some time has passed, however, since the book has been written and today the reader can find a plethora of examples dispersed on the Internet, via developer blogs everywhere. Alt.Net in particular is a group whose members adhere to agile and lean practices and would be a good place to start searching.

I consider this book an excellent introduction to lean software development and highly recommend it to anyone looking into this methodology wanting to know more about it, or wanting to implement it in their workplace. The language of the book provides an easy read and most real life examples are taken from Mary and Tom's personal experiences at the various companies they have worked for and are always very insightful.

What is lean?

Lean development is the elimination of waste.

That's it... Really! You can stop reading now.

Seriously, however, lean development is about using tools and techniques in accordance to seven basic principles in order to eliminate waste in the value creation process.

The value creation process is simply how your company (or department) creates value. In our case, how we develop software is the process we are talking about here. Software is the value we create for our customers.

One way we can visualize this process is by using a value-stream map, which depicts all the steps taken when designing, developing and deploying software, along with the time taken to go through each step and the time that has been lost just waiting for something (feedback, testers, DBAs, etc.)

Then we apply lean methodologies to try to shorten the value-stream map as much as possible without sacrificing on quality. All and all, it means having shorter software creation cycles.

Let's talk a bit about each of the seven lean principles, as discussed in the book.

Eliminate waste

Well I've rambled a little about this already. The main thing is to learn to see waste, however. One way to do this is to search for anything that isn't coding and analysis and see if it adds value to the product. If it doesn't, then it is waste.

The following is considered waste:

• Partially done work
• Extra processes
• Extra features
• Task switching
• Waiting
• Motion (how far do you need to walk to for an answer to a question, for example?)
• Defects

Another way is to map a value stream and try to reduce as much as possible the time spend on steps that don't provide a lot of value.

Amplify learning

Knowledge is key: knowledge about what the customer wants, knowledge about the system, knowledge about the constraints. We need to generate that kind of knowledge as fast as possible in order to make the best decisions we can.

Having short release iterations will generate customer feedback faster. Also, constraints might become more obvious sooner. Your code needs to speak volumes about intent and design without the need to spend time trying to decode it (a major waste!)

Try to do some set-based development also to generate as many ideas at the same time as you can.

Decide as late as possible

This is one of the things that Toyota does that makes them stand apart from the competition (and why they still make a profit and don't need their government to bail them out!)

Delay the critical, hard to undo, decisions until the last possible moment when delaying any further would reduce the value of the product or would eliminate important alternatives.

Decouple your modules, anticipate, code multiple options knowing that one might be chosen and the others discarded later. The price of losing the options in this case would be lower than not doing them at all. Use parameters, interfaces, abstractions. Encapsulate variation and do not repeat yourself.

Deliver as fast as possible

Use a Kanban system and code in short iterations. Enough said!

The key element in this principle is throughput: the rate at which value is created. The book mentions the theory of constraints, which deals with this in a manufacturing context where the entire shop cannot go faster than the slowest machine. The same can be said about software, which can't be written faster than the slowest process in the value-stream map. Everything must then be subordinated to the constraint since any extra effort by a non-constraint is waste. I suggest you read The Goal if you haven't already. It is an excellent book.

Empower the team

Teams are more efficient when managers give them free reins over their processes. Most successful companies have seen change happen within their walls from shop employees, not managers.

At 3M, for example, new inventions come from such employees, who are then expected to lead the effort to manufacture them!

Allow leaders within teams to emerge and influence others. Allow master developers to take charge. And make sure your team members keep improving on their skills. Set them free!

Build integrity in

Integrity is how the software behaves. Is is consistent? Are all the parts acting in synergy with one another? How is the user experience? This principle helps you answer those questions.

Use refactoring and testing to maintain a solid architecture and make sure you spend time designing a good user experience. The happier the user is, the less effort you'll spend down the road.

See the whole

Finally, focus on the whole. Do not spend time doing local optimizations like making the testing department faster when it is not the constraint of the system. Be weary of local measurements like lines of code per coder because you'll be tempted to improve on them (local optimization) in isolation of the big picture.

Instead, focus on you value-stream map! Work on reducing the amount of time it takes for an equal amount of value to be created. When you change a process, go back to this map and make sure you didn't make it worse, even though a local area might have improved.

Has throughput increased? Have operating expenses been reduced? Has the amount of work in process decreased? All three must be true.

Conclusion

Of course, there is much, much more being discussed in the book. But what I have written in this post should get anyone started with lean or should be a good reminder of the key points of the book if you have already read it. I know I will refer to this often in the future in my own quest to implement lean techniques with the rest of my team!