Mary Poppendieck

In the last couple of years, I have heard many times about lean manufacturing (and in particular the Toyota way of manufacturing). I have also read a couple of articles by Mary Popendieck on the web, so I thought I would get this book and find out more.

I am glad I did. It is exactly the kind of book I like to read about software engineering - it is written by somebody with lots of hands on experience, it describes new and interesting techniques for producing high quality software, and it has plenty of references for further reading.

It is written by Mary and Tom Poppendieck, but I get the feeling that most of the input comes from Mary. She has solid experience with software development in many roles and places. In addition, she also has extensive experience with manufacturing, and one of the biggest pluses with this book is how she shows how to transfer principles and practises from lean manufacturing to software development. The type of development they advocate is squarely in the agile camp (obvious from the subtitle as well).

There are seven chapters on seven lean principles, with 22 "thinking tools" with specific practices or principles. If you are familiar with Extreme Programming (for example through Kent Beck's first XP book), you will recognize a lot of the ideas in the thinking tools. Examples are: Feedback (tool 3), Iterations (tool 4), Options Thinking (tool 7), Refactoring (tool 19) and Testing (tool 20).

However, the value for me was the many ideas from manufacturing that I had not previously read about in the agile literature. Examples are: Value Stream Mapping (tool 2), Set-Based Development (tool 6), Pull Systems (tool 10) and Cost of Delay (tool 12)

There is actually so much good material in this book that I will have to concentrate on just a few examples. The first lean principal is Eliminate Waste. "Waste is anything that does not add value to a product, value as perceived by the customer". This is a great starting point, and one that has many implications. Examples of waste in software development are: extra features (that are not needed now), task switching, waiting, motion (for example document hand-offs), and of course defects. With this definition of waste, a value stream map helps you to see waste by mapping where value is added, and where there is waiting etc as a product is developed.

Another interesting part is tool 10 in chapter 4 (Deliver as Fast as Possible). Here the authors describe how pull systems work (you set things up so workers can figure out for themselves what needs to be done, instead of telling them what to do). They continue with an example of a pull system, the simple and ingenious Kanban card system used in Japan, and show how a similar system can be used for software development.

The use of pull systems goes hand in hand with the theme in chapter 5 - Empower the Team. The idea here is that the front-line workers are the ones that know best how things should be done, and they should be empowered to act on this knowledge. Most of this material is covered in regular books on business improvement, and there wasn't much new material here for me. So for me, this was the least interesting chapter, together with the parts on contract negotiation in chapter 7 (simply because I am not involved in any contract negotiations).

Another theme in the book is to not sub-optimize. There is a good example from the manufacturing world, where a video tape machine was run at full capacity. The utilization of the machine was maximized, but that did not maximize company profit. It is tempting to break up a task in smaller tasks, and then optimize each task individually. But as the authors show, that is very often a bad strategy. A good analogy from the book is when they point out that Lance Armstrong, winner of Tour de France for many years, only won 4 out of 21 daily stages, even though he was the eventual winner. Had he tried to win each daily stage, he probably would not have won the whole race.

There are also many good examples in the book. I particularly liked the one about HP printers. By waiting to do the final electrical configuration of the printer until after it was ordered, it was much easier to match the supply of printers in a certain configuration with the demand. It cost a bit more to do the configuration so late, but that was more than off-set by the savings of not having to forecast exactly how many printers in a certain configuration that were needed at different locations.

I also found many interesting nuggets of information about software development sprinkled through the book. The diagram on page 18 for example shows how experienced designers work out a solution to an ill-defined design problem by repeatedly moving between high level and low level design activities. I had never seen this described before, but immediately recognized that that is how I work too (as opposed to a straight top-down approach). This too explains why I think you should also keep coding even if you are an architect - because to find the best solution you must alternate between high and low levels of design.

Another good part was their diagnosis of the problems with CMM and ISO9000. They write that both programs have a bias towards documenting and thus standardizing existing process, rather than improving the process, even though it is not the intent of either. I agree completely.

This is a practical book, and there are lots of good (and well described) ideas that can be used in software development. It is well worth getting, both for developers, managers and project leaders. Recommended.… (more)

This is very much a management book rather than a programming book. It is not so much focussed on techniques as on war stories, many of them first hand, and much of it is dominated by the making of analogies to engineering projects in other domains (building construction, automobile manufacturing, airlines).

In my experience the case model which drives this sort of writing (The Harvard Business Review being the ultimate template) tend to be biased towards disasters one can learn from - many HBR "case studies" are along these lines - or of paradigmatic successes: this takes the latter route.

It feels rather like a competent collection of summaries. It includes a not-bad potted history of stages in programming history (structured programming, OOP, waterfall vs. iterative development, Agile) for non-programmers, and some management theory (Deming and Drucker, principally) for non-MBAs. It provides a clean summary of the differences in emphasis between lean and agile development models.

Overall, not bad but not exciting.… (more)

There is a lot to the book. I think it will take me multiple readings to get my head around all of their ideas. I read the book over the course of about a month. I wish that I had been able to read the whole thing in one big chunk, but that wasn't feasible.

The book begins with a chapter on the history of Lean production and its origins at Toyota. I was familiar with the broad outlines of Lean production, but there was a lot of interesting detail I didn't know.

The second chapter describes the adaptation of Lean to software development and lays out the seven principals of Lean development.

* Eliminate Waste
* Build Quality In
* Create Knowledge
* Defer Commitment
* Deliver Fast
* Respect People
* Optimize the Whole

The next five chapters go into detail on Value, Waste, Speed, People, Knowledge, and Quality. As you may have noticed, those mostly but not completely correspond to the Seven Principals. Value and Waste both seem to correspond to "Eliminate Waste." Deferring commitment is address in the speed and knowledge chapters. Optimize the Whole is addressed in various places, including People, and Quality.

The last two chapters are entitled Partners, and Journey. Partners has some really interesting ideas on how to structure incentives so that everyone--individuals, teams, contractors, even partner companies, are all aligned to create synergies and increase value for all parties involved.

The Journey offers ideas on how to begin using Lean methods in your environment. It builds on the "Try This" sections that end each chapter.

There are a lot of really interesting ideas in this book. I've been thinking a lot about how I want to apply them.

One thing that I've realized is that I'm not as clear as I need to be on how my team provides value. And that really matters, because that should be driving decisions about what we do. My team builds automated testing tools that are used internally at a company that makes "Application Delivery Networking" hardware. We also operate the test systems. We used to write automated tests, but now that is mostly done by another group. So what is our primary contribution of value? Is it the capabilities that we deliver to the team that writes the tests? Is it the results that come out of the test systems that we operate? When I have to make trade-offs between those two tasks, which one should be more important?

Another point that Lean has driven home for me is that my team has too much work in progress. We have lots of ideas that we'd like to implement. We also get lots of requests from people. If we meet our goals for the current Sprint (which is far from certain at this point), we will complete about 150 story points worth of work for this release. I already have 145 story points queued up for the next release--and that's with only half of the backlog items estimated. My "high priority" list of work to do after the stuff in the queue is equally large, with equally incomplete estimates.

One of the ideas that I liked and am going to be thinking about is using automation to remove low-skilled, repetitive tasks, especially if they are mistake-prone. There was a list of examples of automation:

* One Click Build
* Scheduled Builds
* Build Result Notification
* One-Step Release
* Bullet-Proof Installation

Things that I would add to this include:

* Build Acceptance Test
* Automated Unit Tests
* Scheduled Regression Test Runs

Ironically, for a team that is all about automation of other people's tasks, we haven't automated a lot of our own work. We have an automated build script, but not everyone understands how to use it, we don't do scheduled builds, we don't have a notification system or automated build acceptance tests, we don't have a one-step release process, and we don't do scheduled regression test runs. We do have automated unit tests, and we do have a fairly good installation script, but only for part of the system.

When we did our last release, we had trouble getting a build out and getting everyone notified. At the review of our last sprint, people had trouble demoing some of the work because not all the boxes were set up the same way. We need some automation here.

Moving forward, I'm going to start devoting some time out of our weekly team meeting to discussing the Lean principals and figuring out how we can apply them.… (more)