Book Log: "Lean Software Development, An Agile Toolkit"

Our reading group at work recently finished Lean Software Development, An Agile Toolkit by Mary and Tom Poppendieck.

There are several things I really like about this book:

1. Its thinking is clearer than most. The Poppendiecks make sharp distinctions between principles, tools, and practices. (More on this will follow.)
2. It presents an Agile approach without demanding that one follow all tenets of Extreme Programming (such as pair programming).
3. It recognizes that in the past it has been a mistake to think of software development as being roughly analogous to manufacturing. Creating custom software is not very much like assembling cars within a factory.. Software development is much closer to product development, much more like the work that goes into designing the car in the first place. Principles (not necessarily techniques!) that work well in product design can have a much more straightforward application in software design.
4. They specifically address the needs of safety-critical software, talking about how to apply these principles in environments that are heavily regulated or where a software failure may endanger lives.

The book does suffer at times from and affliction common to this genre: over-enthusiasm. There can be a sense that all we need to do is follow what they say and all will be well. But, for the most part, the authors provide reasonable, realistic guidance for those looking to improve the way they go about creating software.

Now that we have the overview, let's look at the meat of the book: Agile principles. There are seven Agile principles which should govern a group's software development process:

1. Eliminate Waste
2. Amplify Learning
3. Decide as Late as Possible
4. Deliver as Fast as Possible
5. Empower the Team
6. Build Integrity In
7. See the Whole

A chapter is devoted to each principle. In each, the principle is described, examples are given from both product and software development, and a number of "tools" are suggested as ways to apply the principle in software development.

The principles are valid within any development effort, software or otherwise. For example, a good process will always seek reasonable ways to eliminate waste. In product development and manufacturing, waste may include scrap material that does not end up in a product. In software, the definition of "waste" will include things like partially done work, extra processes, extra features, waiting,
etc.

It is very important to keep the distinction between principles, tools, and techniques in mind. Principles must be reasonably applied to a given environment. The authors put it quite well: (pp. 179-180)

• Eliminate waste does not mean throw away all documentation.
• Amplify learning does not mean keep on changing your mind.
• Decide as late as possible does not mean procrastinate.
• Deliver as fast as possible does not mean rush and do sloppy work.
• Empower the team does not mean abandon leadership
• Build integrity in does not mean big, upfront design.
• See the whole does not mean ignore the details.

One team's prescription is another team's poison. Do not arbitrarily adopt practices that work in other organizations; use the thinking tools in this book to translate lean principles into agile practices that match your environment.

I strongly recommend this book.