Today the lean meme is in every business newspaper. It has been a long time coming. Some companies like Toyota have lived these principles since the 1950s when their lack of capital forced them to improve their production processes radically. In the West it appeared on the radar with the books by Womack & Jones published from 1990 and onwards. Now, the ideas have gained mainstream mindshare and are being applied in many fields. Applied to software development “lean” provides a great toolbox of agile methods to help radically improve development efficiency.
Deliver High Customer Value Quickly at Low Cost
The lean starting point is to optimize the production from a customer-centric perspective. The goal is to provide the customer with maximum value quickly and at a low cost. Therefore the first step is to define the value of the product (or features) from the customer’s perspective. Translated to Scrum this is the job of the Product Owner.
The central point of lean is to eliminate "muda", or waste. Muda is defined as all the activities and steps in a production process that add no value to the customer. In software, examples are work-in-progress, defects, features that are not necessary, the bureaucratic hindrances in traditional software development organizations and all the stuff and over-generalizations that developers love to do (“we might need it later”) even when a much simpler solution will suffice.
Since there is so much waste a typical lean transition begins by mapping the value stream for the complete production process from the customer's perspective. Then we reduce it to only the steps that add value to the customer. This is usually a very small subset.
Introduce Single-Piece Flow
Once we know the steps we organize the remaining steps into the best sequence and introducing “single-piece flow”: completing the production of a whole but small product in one continuous sequence with no delays.
Use Pull Scheduling
At the integration points between the single-piece flow “cells” the lean method of scheduling is using “pull”. When a downstream consumer is ready for processing a new part it requests it from its upstream supplier. This makes scheduling very simple. There is no inventory to keep or partially made items to track. The synchronization mechanism is simply to keep everyone working in the same “takt time”, producing new stuff at just the rate it is needed. Therefore no waiting occurs. This is a simple way to optimize the throughput without complex planning systems.
Improve The Process Continuously
After the initial radical reengineering of the production process we continuously focus on improving the process as we learn and innovate, so that the effort and time do the work keeps falling. This produces a virtuous cycle. In the words of Womack & Jones lean is a method to do more and more with less and less.
Stop-the-Line Root Cause Problem Fixing
A lean process stops when there is a problem and it does not restart until the root cause of the problem has been fixed.
One of the legendary lean examples of this is when Toyota took control of the NUMMI car factory in the USA. The US tradition was to let defects slip and fix them in QA later. Instead, Toyota simply it told the workers to do good work and stop the assembly line when they could do their work properly.
It took about month to produce the first vehicle.
Since then, however their quality and productivity has been outstanding and they have earned an impressive number of awards.
To teach people the stop-the-line culture Taiichi Ohno of Toyota used the principle of “five whys”. When we encounter a problem we ask why five times to unveil the true root cause of the problem rather than just treating the symptoms. In software you see that very good operations people have a natural tendency to do this, while most developers faced with the same problem tend to just advice to “restart the server” or some other fix that does not unveil the nature of the problem or prevent it from reoccurring. The stop-the-line practice improves quality - while the other just accepts low quality without fixing it. One of the central lessons of lean is that you have to improve quality to go faster so by continuously removing the root causes of problems we also improve the efficiency of the entire production system. In fact, from a customer perspective testing to find defects is a “muda” whereas testing to prevent defects from occurring is not. In software terms this makes the case for test-driven development and identifies test-later as an expensive, wasteful practice.
In the coming months we will explore lean and its applications to software development in this blog. Until then - Happy New Year and keep the comments coming. We really appreciate your participation.
- Taiichi Ohno - one of the greatest industrial innovators of the 20th century, the father of the Toyota Production System. After spending his career relentlessly optimizing manufacturing at Toyota he wrote the book Toyota Production System: Beyond Large-scale Production that describes his work.
- Womack & Jones - Their books are great and it is well worth to read them all to see a lot of the principles and case studies for lean thinking. Also, it is quite interesting to see that software development is now rediscovering some of the things that manufacturing learned much earlier - in the case of Toyota as early as in the 1950s and 1960s. Begin your studies with The Machine That Changed the World, a five-year study of the global auto industry from MIT and go on with the Lean Thinking and Lean Solutions. They give a fascinating perspective on manufacturing and plenty of examples of the lean principles and they applications.
- Mary and Tom Poppendieck - with a background in manufacturing and software they have translated the concepts of lean to software development. They have written two great books and Implementing Lean Software Development and Lean Software Development - an Agile Toolkit. Both books are well worth reading a present a both the principles and lot of cases in a friendly, colloquial manner. Mary Poppendieck is a frequent conference speaker. We saw her giving some very impressive lectures at Agile 2006 (www.agile2006.org) and there is plenty of opportunity to see her on the conference circuit. Highly recommended!
Updated January 11, 2007: fixed grammar and typos.