Lean Software Development: An Agile Toolkit

Posted by Rich Crowley in Agile, books, Lean, Project Management

This book was written by a husband and wife team who have extensive experience in software development as well as a host of other industries that have been touched by the lean movement. It is an excellent read. The authors are not shy about expressing their disappointment in how strong the Project Management Institute’s influence has grown over how software development projects are planned and managed.

The book outlines 7 principles derived from lean methods. Among these are eliminate waste, and deliver as fast as possible. Within these principles, the authors provide 22 thinking tools that support the 7 principles. Among these are amplify learning, iterations, queueing theory and self-determination. The authors make an interesting point that the reason they provide principles where many other experts provide practices is that they don’t believe practices necessarily transfer to different companies, cultures, locations, industries, etc. very well. I like their thinking here because I’ve long held that companies following best practices are giving their people the green light to quit thinking of how best to work in the unique context of their own organization.

The book explains early on that there is a significant distinction between development and production regardless of whether you are making drugs, cars or software. The former is much more ambiguous and and a voyage of discovery whereas the latter is really an exercise in finding the most efficient way to do something repeatedly. However, lean methods have been successfully applied to both in multiple industries so there is some confidence in the generic goodness of lean methods.

The authors contend that traditional software development approaches that are sequential in nature are perhaps this way because they were modeled after other disciplines (such as civil engineering) and yet history has proven that such sequential approaches really don’t work very well for many software development projects. They support their arguments with lots of evidence from their own experience as well as formal research and a host of opinions from other influential people in the software world who are proponents of non-sequential approaches.

The book contains a ton of ideas that I found really interesting and that directly challenge PMBOK-based best practices. Many of these ideas resonated with me because I have personally bumped into these as a PM. I’ll be writing several blog posts about these in the next little while but here’s a couple of examples of what you can expect:

– For complex requirements, experienced developers do not look at requirements, design a solution and the build it (or hand it off to be built). The process is much more iterative with a heavy emphasis on experimentation, making adjustments, testing and validation with any required documentation being done at the end of the process rather than as an up-front design.

– Are written requirements really necessary? Why not have developers work directly with users to hear what they want and then code it with documentation coming in the form of the test cases used to validate that the code works as the business stakeholder wanted