Lean Software Strategies: Proven Techniques For Managers and Developers
Lean production, which has radically benefited traditional manufacturing, can greatly improve the software industry with similar methods and results. This transformation is possible because the same overarching principles that apply in other industries work equally well in software development.
The software industry follows the same industrial concepts of production as those applied in manufacturing; however, the software industry perceives itself as being fundamentally different and has largely ignored what other industries have gained through the application of lean techniques.
Lean Software Strategies: Proven Techniques for Managers and Developers, shows how the most advanced concepts of lean production can be applied to software development and how current software development practices are inadequate.
Written for software engineers, developers, and leaders who need help creating lean software processes and executing genuinely lean projects, this book draws on the personal experiences of the two authors as well as research on various software companies applying lean production to software development programs.
Review By: Lisa Crispin
11/17/2006
Having two authors--one writing as a practitioner (albeit highly educated and experienced), and the other from an academic and research angle--makes "Lean Software Strategies" unique to my experience. For someone like me, who likes to speed read and get the salient points, it slows things down. However, the academic view and hard data to back up the recommended practices gives more weight to the potential success of implementing these practices.
Although the book requires careful reading and thinking, it is extremely well-written with liberal use of real-world examples. The authors handle well the change in voice from practitioner to academician and back.
They raise an excellent question: If lean principles can be applied to software development in a way that makes us significantly more productive, why aren't more teams using them? We all know that big changes are needed in the software industry, and these authors make a succinct and persuasive case for why lean production is the way to go.
The book is well organized, beginning with an exploration of the software industry. The authors explain craft, mass and lean production, and whether each is suited to software. Part one explains five principles of lean production, which mostly relate to value--what really matters to the customer. The authors examine different software industrial paradigms, including CMM and XP, and assess how those align or conflict with lean. Parts two and three provide a detailed manual on building lean software, with a lot of emphasis on eliciting customer needs and understanding customer value. Part four gives several interesting case studies of actual software producers, including Microsoft, Timberline, and an XP project, ending with a roadmap for implementing lean in your own organization.
Lean puts more effort into gathering and analyzing customer values than even my successful agile team does. I can't help but agree with the wisdom of emphasizing the strategic goals of development, such as understanding the business and what the customers want, over the tactical parts of actual code production.
“Lean Software Strategies” includes many helpful examples and analogies, although most are from the aerospace industry and hard for me to wrap my brain around. It is a difficult but valuable read, though I think it would go easier for experienced programmers. As an agile practitioner I can't help being skeptical of some of the book's practices, such as using formal requirements as a basis for creating test cases. The authors clearly have used them successfully, so I intend to keep studying the book and trying the practices once I better understand them.
A lot of the material in the book is commonsense. For example, having a lot of specialization has always seemed intuitively counterproductive to me. The authors’ discussion on how CMM’s use of division of labor sets up an adversarial approach to accountability was enlightening. I also enjoyed their discussion of tools--how the right tools, especially custom tools, improve the flow of the project. But teams shouldn't emphasize tools over delivering customer value.
I appreciate that the book compares XP and lean, but I don't agree with the authors’ observation that XP doesn't scale. I've worked on successful, large XP projects and know of many more from other publications. XP can be scaled to large projects, and thus is more in alignment with lean than craft production.
I've previously read “Lean Software Development: An Agile Toolkit” by Mary and Tom Poppendieck. I found it to be easy to read and understand, more practical, and immediately applicable. “Lean Software Strategies” is a different book and probably aimed at a broader audience. Yet, it's worth investing the time to read both books.
I think my agile team does a great job of delivering business value, but after reading this book, I realize lean principles might help us accomplish much more. This book is a soup-to-nuts explanation of lean production, why it should be applied to software production, and how to apply it.
User Comments
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.