Despite the bold title of this book it has two main themes both of which never offer a single specific example of lean application on a software development effort. It is very surprising that this book received a Shingo award for application of lean technologies to software development because the best this book has to offer is recommendations and cheerleading for how lean ought to be applied - no practical examples are ever offered leading one to feel as if they have been cheated after such a bold assertion made by the title.

In general the book is a compilation (vice application) of two main concepts - 1.) lean approaches and recommendations on how to apply these to software and 2.) one of the author's experiences from the 382J and C27J programs. Notice that these two main themes never successfully integrate into a single tenet on application of lean processes to software.

The author's experiences from the previous two programs (382J and C27J) are in fact applications of techniques that have been around since at least the mid 80s - SCR (Software Cost Reduction - D. Parnas) and the use of Spark Ada (subset of Ada used in safety critical applications with formal "annotations").

The SCR approach is based on specifying the software behavior precisely and concisely through conditions, events, modes, and terms. During the 1980s and 1990s, a number of organizations in both industry and government used the SCR techniques to document the requirements of a wide range of systems. In 1994, a version of SCR called CoRE was used to document the requirements of Lockheed's C-130J aircraft. The C-130J requirements document contained over 1000 tables and the resultant code was about 250 K SLOC. The use of SCR is not a new technology, neither is it necessarily lean. However, it is important to understand that tools exist that can interrogate SCR tables and provide an indication of the quality of the specification in terms of completeness, consistency and a few can even generate test vectors that could be used to test the tables in a test environment.

Spark Ada is a subset of either the Ada 83 or Ada 95 language versions where annotations are used to specify assertions made about the software. These assertions are made about the data relationships (information flow), various properties that either need to hold when a subprogram is called (preconditions), or that will hold once execution of the subprogram has completed (postconditions). The Examiner is then run on the specification and corresponding body of a subprogram and will analyze the body of the subprogram to build up a model of the information flow. This model is then compared against that which has been specified by the annotations and any discrepancies reported to the user. This method places emphasis on the completeness of the software largely through the information flow as modeled above. The argument is that given a good enough series of pre-conditions, post-conditions and information flow arguments the software is then "proven" to be formally correct. Practitioners who do not hold these notions argue that the "proof" is only as good as the degree of effort employed in specifying these assertions.

It was widely understood among certain circles that the C130-J team that cut their teeth on these techniques (read as huge cost overrun and over one year late) was made available for the 382J development and the real software lean story was the use of the small now experienced team (as Brooks argued) on that effort more than any application of lean technologies.

This book addresses lean terms such as flow, value, pull, etc but fails to demonstrate any tangible use of them or even specific recommendation for how they might apply to software life cycle activities.

The book spends a chapter maligning the CMM practice in which nothing good about it is said. I agree with the author's concerns about the organizational inertia created by this initiative and the lack of focus that this approach tends to put on the bottom line - developing software productively. I also tend to disagree with the author in his assertion that nothing useful can come from the CMM. It would be very disappointing to see any CMM practitioner that uses quantitative management and does not address defect prevention and cost - making the necessary trade-offs between these two to achieve a cost balanced solution. I also tend to think that the CMM has addressed key areas that tend to bring needed areas of focus such as tracking of progress and creating the disciplined structure in bringing together a comprehensive software engineering management framework for development of software.

Overall, this book falls very short of its bold title and is in my opinion not worth reading. Again, disappointing performance for something selected as a Shingo award recipient.