A review of “The Art of Lean Software Development”
Available on Amazon at: https://www.amazon.co.uk/Art-Lean-Software-Development-Incremental/dp/0596517319
By Hibbs, Jewett, Sullivan
In brief, I liked it.
Lean manufacturing, or more often simply referred to as Lean, is not a new concept. The key concept is to reduce waste in manufacturing. Applying Lean to software development is a more recent idea. In manufacturing it is easy to understand that waste could be damaged parts or defective products, but Lean also includes delays and unnecessary production as waste. Software development can easily suffer from delays and unnecessary production, so transferring Lean thinking to software development does not require a great leap of faith.
In presenting Lean it would be easy to start by discussing a range of principles and methodologies available to the Lean practitioner. However, the authors of “The Art of Lean Software Development” lightly skim through this material giving the reader a flavor of Lean and its terminology, without getting bogged down in details.
The majority of the book is taken up with a six step plan for making your software development Lean. With respect the authors admit that the first step (version control) isn’t so much of a step as a prerequisite for all software development (it is actually referred to as step zero). At this point you might feel that you are being taught to “suck eggs”, but none of the other steps stand up without version control. Besides in my experience it is surprising how much software development goes on without any real version control, so I was happy to concede this point.
The remaining five steps provide a logical progression of measures that can be introduced in sequence to make your software development Lean. The authors favor an incremental introduction of measures rather than a riskier big bang introduction, an approach that has much to commend it. Most of the suggestions, like continuous integration, software developers will have probably used or at least heard of before. However, the book puts them into a plausible sequence for introduction and places them in the context of Lean as opposed to Agile where these measures are usually discussed.
Initially the steps are practical, though the authors don’t pretend to give detailed practical implementation advice, preferring to direct the reader to other more detailed books and websites. Later steps become “softer” or more psychosocial, such as having a close customer participation. For a software developer the earlier steps are easier to implement. The later steps can be more of a challenge, since they are more to do with relationships and less to do with technology.
By introducing Lean as a six step plan for developers the book takes a practical approach and avoids dwelling on the concepts behind Lean. At just under 130 pages it is not a long book and despite having three authors (or perhaps because of it) it is clearly written and easy to read. I got through it in a couple of evenings.
The book makes no claim to be a complete and definitive guide to Lean. So if you were expecting detailed descriptions and guidance you will be disappointed. It does provide some positive and clear advice on how to start introducing Lean. It is probably not the only way to introduce Lean, but you could do a lot worse than follow the plan outlined.
If you already know about Lean and want more detailed information you might find this book a bit light. However, if you are a developer or team leader wanting an introduction to Lean this is a good place to start.