Lean Software Strategies: Proven Techniques for Managers and Developers [Hardcover]

Lean Software Strategies is a book about applying lean manufacturing ideas to software programming. I believe there is a lot to learn from manufacturing and I was pleased to get this book. After reading it, I am somewhat disappointed. There is nothing wrong with the advice in the book. But I don't feel the authors have really described a lean process. I'll go in the details below. In short, the main technique suggested is to make the whole process more integrated and more rigorous using, for example, formal methods. This reminded me of the book The Cleanroom Approach to Quality Software Development which makes the same claim and ends up with similar results. Lean is more than cleanroom. I expected data about work-in-progress reduction for example but I didn't see that in the book.

Here are more details.

PROS:

- Good introduction to the lean concepts (value, value stream, etc)

- Some interesting ideas to implement lean, especially if you are following a waterfall model. If you have already moved to a milestone model or XP, some ideas will be redundant.

CONS:

- Lack of data regarding the advantage of lean. The projects mentioned are vague and the data presented does not make the case for lean (versus, say, cleanroom as mentioned above).

- Focus on a specific class of applications (safety-critical) without a generalization to other classes of applications. In particular, the use of formal methods may not translate well to other domains.

- Focus on technologies (UML, QFD, TRIZ) without a word on team dynamics, employee training, etc. The soft aspect of lean is ignored.

All in all, I would recommend reading the book; but do not expect that it will change your world.

This is a well written book and has many good ideas in it given the caliber of the two authors, however:

1) Specific applications of the overall lean principles are not demonstrated other than using the Spark Examiner. Still not sure about the tie in between it and the overall lean principles presented. Is this a book about the use of lean principles or SPC/Spark Examiner? Never quite clear.

2) For this book to meet the claim that it is "...Strategies... for ... Developers" The lean steps should be more of a cookbook - you get the right ingredients, cook them how we tell you and then eat. Most of the "recipes" in this cookbook are from a methodology standpoint - there is not enough recipe to tell you what specific steps to do, if you are doing them right, when you are finished, or what results you should/could expect. Go get the flour, water, eggs, and yeast and make a cake.

3) "The CMM has frozen many of the best practices of the 1980s into its KPAs, and thereby frozen much of the industry there as well." Are you saying you have even better practices than even the SEI? From what basis can you make this claim - at least the SEI has data that they can show to make or refute such claims - where is your data?

It's a quick read and there's no rocket science here. If you are looking for a book to let you go off and launch a waste reduction exercise applying specific principles that should produce certain results - forget it. This is more of an overview book - not a practitioners guide.

It would be pure gold like this one! This book won the Shingo Award: [...] The selection committee clearly knew what it was doing. The author has created an excellent exposition of how lean manufacturing methods can be applied to create abstract intellectual assets such as software and, by implication, systems engineering plans and designs.

Overall the book is an excellent, well written discourse on lean methodology with numerous examples of its application. The authors explain in clear detail how best to apply several lean tools to plan and to perform major systems and software projects, e.g., TRIZ, Analytic Hierarchy Process, SCR, Blitz QFD, Theory of Constraints, Agile practices, high integrity UML, language selection to support lean production (SPARC Ada), load leveling, and Kano Modeling. The cases where this approach was used provide consistent evidence of success; software productivity was significantly improved over previous practice by roughly a factor of four even though the requirements churn in those same contracts was significantly higher than in other successful projects. It is critical to note that software production was stabilized against serious requirements instability by the lean practices being described. Further, that stabilization was a major contributor to successful completion of the contracts!

In the first few chapters, the author spends some time explaining the niche in which lean methods live and work most effectively. In chapter 5 the author analyzes the SEI's Software CMM model to determine the manufacturing paradigm for software. One should note that, since the publication of the book, the Software CMM has been replaced by a newer model, the Software/System/etc CMMI that addresses several of the lean concerns: [...]

After some thought it is clear that the fundamental criticism of the Software CMM is that the implementation of any business model by practitioners of the manufacturing paradigm is the principle problem. Such practitioners will likely take a relatively low risk, evolutionary, incremental approach to introduce change. They will therefore initially implement a set of organizational processes that promote and support the manufacturing paradigm in a way that minimizes necessary change, the nearest "as is" state. Such processes should not be expected to be particularly lean until after performance needs drive significant changes to support a leaner approach, the "to be" state. This incremental approach, while fairly smooth and stable can take a decade or more to reach a lean paradigm even if that is the intended end state.

If the authors choose to write a second edition it would be useful to discuss how the CMMI model that has come into use since the writing of this book provides potential synergy with the lean approach. To understand what is improved over the software CMM, one should note that the new CMMI model includes systems engineering process areas rather than being focused exclusively on software. Like its predecessor the CMMI is a process framework and is thus process and performance agnostic. The model is not quite paradigm agnostic; it clearly votes against the craft paradigm by labeling such practices "initial" or "capability level 1". One might speculate that a fully integrated lean approach would garner capability level 5 ratings for the relevant process areas. Further, there is no performance aspect to the CMMI SCAMPI appraisal as there would be with a company performance audit model such as the (Malcolm) Baldridge National Quality Award[...]. The CMMI SCAMPI asks if there are specific and generic practices (documented processes) in place to address a set of basic business capability questions (goals), but it does not ask how well those processes perform. It is left entirely up to company management to track and manage process performance. In that respect the CMMI model is independent of the lean manufacturing approach. Synergy with lean methods is both possible and desirable. If the authors choose to write a second addition, it would be valuable to devote a chapter or two on how to develop such a synergistic approach in building and maintaining a comprehensive set of organizational business process assets.