Book Notes: Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck

I do not think a software book has so radically affected my thinking in the last several years as Lean Software Development: An Agile Toolkit has. I have been mentally flirting with agile development ideas for a while now. This book has finally convinced me that the part of the software development world that ignores agile is in ignorance its own enemy. Going "agile" does not solve all problems, but it can help solve a good number of them.

I give this book very high marks in everything but its binding, and there it is average. The discussion is clear, the examples are great, everything is organized well, and most importantly, the ideas are compelling.

The authors enumerate the principles of lean software develoment in seven points:

1. Eliminate Waste - remove everything that does not directly add value.
2. Amplify Learning - development is a process of discovery, and we should try to learn and discover as best we can.
3. Decide as Late as Possible - when there is uncertainty (and there almost always is), be flexible enough to decide on significant issues as late as possible. The later the decision is made, the greater chance that enough information will be available to make that decision informed.
4. Deliver as Fast as Possible - without speed you cannot delay decisions, or get good feedback.
5. Empower the Team - no one understands the details of a project than those who are actually doing the work, so they need to be equipped to make decisions.
6. Build Integrity In - software needs to be cohesive and have conceptual integrity, and it needs to maintain its usefulness over time.
7. See the whole - know the whole well enough to strive for the common good/overall system quality and not just make parts of the product great.

The point that struck me as the most significant was the third, "Decide as Late as Possible". On the one hand it ran counter to virtually everything that I thought. It was my assumption that it would be more helpful to decide up front, and base everything on that. The fact is, though, that there is usually a great deal of uncertainty in software development. And the general principle of waiting for more information to make decisions only makes sense. But there is a rub. I have yet to be in a software development shop that can perform well enough and consistently enough to actually write software good enough that it is flexible enough and tested enough to allow for this kind of freedom. Enough enoughs? This is not a principle that you can just accept and run with. Other practices have to be brought in to support this way of development. If it can be done, then this is definitely the way to go. But it would take skill and discipline, something that is harder to find in our industry than many of us would like.

In conclusion, this is an incredible book. I highly recommend it to software developers everywhere. You may not end up agreeing with everything, but there is too much good thinking here to ignore it all.