Mary & Tom Poppendieck: Lean Development (part 1)

Back in January, I read the review copy of Mary and Tom Poppendieck’s Lean Development: An Agile Toolkit for Software Development Managers, to be published in June. I found it absolutely brilliant, as should be evident by the eight rather longish blog entries that I posted to Tesugen.com. Rather than editing and reposting them all, I will instead extract the parts that I think are interesting, edit them, and post them here. (This will probably be the approach that I’ll use from now on in this weblog.) For my original posts, please see these Google search results.

In their book, the Poppendiecks look at the car industry, where the lean approach was first invented by Japanese companies, such as Honda and Toyota, in the early 1980’s. I find the car industry to be very interesting as a source for inspiration for software development: making cars is a very costly and risky endeavor; there’s a long time to market and no-one knows really what cars people will want when a new one is ready for release; there are many people involved; there’s a pressure to invent new things with each car. The car design environment, they write, is as complex as in software, and as the lean approach has been tried and proven there, it should provide clues for software development as well.

The lean approach might seem counter-intuitive, especially in the context of the car industry, where so much money is at stake. One might think that the stakeholders would want a detailed plan, with distinct milestones, and a detailed design specification – all signed off and frozen, in order to minimize the room for errors. Instead, it’s a concurrent rather than a sequential process, where decisions are delayed for as long as possible – as it’s assumed that changes will have to be made at any stage, even late in the project. Critical decisions are, in fact, largely made by the engineers themselves, rather than pushed up the hierarchy. and that mistakes are natural in discovering the design for a new car.

The book introduces seven principles of lean thinking, and adapts them to software development. These are explained very thoroughly in the book, with a chapter for each of them, but they can perhaps be summarized as follows:

1. eliminate waste – do only what adds value to the end product;


2. amplify learning – when in trouble, increase feedback;


3. decide as late as possible – by keeping your options open, you are free to change;


4. deliver as fast as possible – because you want feedback as soon as possible;


5. empower the team – enable the team members to make the decisions themselves, locally;


6. build integrity in – integrity must be cared for from the start;


7. avoid sub-optimization – overall success is what’s important – not success or failure of individual tasks.

Waste is anything that doesn’t, indirectly or directly, add value to the end product, such as documentation that no-one reads (because it’s outdated or because it was written because the process says you have to – not because anybody needs it), extra features put in on speculation, defects. Delay is also waste: waiting for people to decide, for other programmers to complete code that you depend on, switching between tasks, et cetera.

Regarding delays: at another place in the book, Mary and Tom Poppendieck write about queue theory, which was interesting. For instance, at banks you often have one queue for all tellers, and in shopping centers there’s often an express lane for people with 10 items or less. At a bank you can’t anticipate which customers will take more time, which you can to a greater extent in a shopping center: people with fewer items will take less time to pass through the queue. In software projects, they write, queues form for example when features are handed over to testers, or when a customer is busy deciding which features should be implemented for the coming release.

To prevent congestion, the Poppendiecks write, you need to move things around at a steady rate, in small batches. This translates, I guess, to splitting features into smaller, more manageable portions. I also interpreted it as requiring fixed (and short) iteration lengths – implying that unfinished features should be deferred to the next iteration, rather than extending the current iteration with a few days. Slack is also important to prevent congestion, and (as I interpret this) the reason is that as a feature moves from one person to another – say, from a developer to a tester – the chance should be high that the person there is ready to take care of it.

Another related thing that was discussed in the book was pull systems – that is, systems that are pulled by demand rather than pushed by schedule or plans. For instance, in manufacturing, there’s a something called Kanban systems, where a Kanban card is left on the shelf as a part is taken from inventory. The cards identify the parts that were taken, and these are collected and replaced by newly manufactured parts. A part might consist of subparts, for which Kanban cards are left, thus causing demand for new parts to ripple across the system.

Software development projects are often managed as push systems, where plans and schedules drive the process. Extreme Programming projects, could perhaps be said to be more akin to pull systems, where features are represented by cards, preferably kept visible on a wall divided into three sections representing what’s currently worked on, what’s finished, and what still remains to be done. Testers, for instance, would pick cards from the section with completed features, and managers and customers could tell from looking at the wall how things are going – instead of calling to a meeting to update the schedule.