Implementing Lean Software Development

I just finished reading Mary and Tom Poppendieck's second book on Lean Development: Implementing Lean Software Development: From Concept to Cash. It was a great book. Highly recommended. In this blog entry, I'll cover some of the major things that I got out of it. For more details (and lots of additional valuable insights), read the book.

One of things I enjoyed most about this book is how the authors related the issues in software development and their solutions to analogous situations in the auto industry (particularly at Toyota). One issue with being in an industry for years is that you become accustomed to the way things are done. This has many positives in that it gives you tools to solve solutions. On the negative side, it can make it harder to see the wisdom of non-standard approaches. By comparing it to a different industry, where this baggage doesn't exist, it makes it easier to see the value.

The concepts in this book complement agile development very well. It goes a little further than that though. It actually explains the origin of many of the agile practices. It also shows examples of why they work.

Lean development is about optimizing your most critical processes. Inventory adds complexity in manufacturing. The same is true for software. In the case of the latter, inventory is represented by requirements documents, functional specifications, design specifications, etc. Your goal is to minimize your inventory. Do just enough for your immediate needs (an iteration whose length is measured in weeks, not months). The value stream mapping presented by the authors is a useful technique for optimizing your processes.

The authors' advice to keep your requirements backlog to two releases was particularly insightful. If you can't get to it in that time frame, you're not likely to get to it. Be honest with your customer and keep things simple by leaving it out.

Features add complexity. Only add them if they are truly critical. Less code is better. Partially done work adds complexity. Stay releasable. Defects add complexity. Fix defects as soon as they're found. But, even go beyond that to figure out what caused the defect in the first place and address the cause.

The authors also cover teamwork and measuring the productivity of the team. Reward what you're trying to achieve: teamwork and business goals. Not individual behavior and things not adding value. For example, producing fewer defects is more valuable than finding more defects, so reward the development and QA team based on fewer customer found defects, not a QA individual for finding more.

Push decision making down as far as possible in the organization. Enable people to make a difference and they will. Focus on everyone (including external vendors) working together as a team. Create contracts that focus on how you will work together, not on the result.

Test automation is critical to staying releasable. One focus was on executable requirements. In other words, expressing requirements through tests. This is one area that it would have been nice to have a few more detailed examples.

There are even some good catch phrases in the book: Don't confuse planning for commitment and Make decisions at the last responsible moment.