Pages: pp. 92-94
CMMI Distilled: A Practical Introduction to Integrated Process Improvement, 2nd edition by Dennis M. Ahern, Richard Turner, and Aaron Clouse, Addison-Wesley, 2003, ISBN 0-201-73500-8, 336 pp., US$29.99.
CMMI: Guidelines for Process Integration and Product Improvement by Mary Beth Chrissis, Mike Konrad, and Sandy Shrum, Addison-Wesley, 2003, ISBN 0-321-15496-7, 688 pp., US$64.99.
High-performance software development is now a key differentiator and competitive weapon in many industries. With software being found in and around practically all the products and services we use, competition has become global. Staying at the same productivity level for one year means de facto that other companies will take your business. Entry barriers to the software industry are marginal, and an ever-increasing amount of highly educated software engineers around the globe are waiting to take the lead with new ideas and products.
Software development outsourcing or subcontracting and off-the-shelf components reuse have created a new product-development hierarchy. This hierarchy comprises integration steps that move from basic software design up to the system level, and processes are the glue that brings together each step's various elements. Processes define how you do software or systems business, let you leverage available people and technology, and pinpoint areas for improvement.
Continuous process improvement is the answer to these competitive challenges. Historically, many models, standards, and methodologies have been developed to help improve engineering processes—most focusing on some specific part of the business (such as software engineering, acquisition, or system engineering). The Software Engineering Institute's (SEI) Capability Maturity Model Integrated, on the other hand, brings these flavors together (see www.sei.cmu.edu/cmmi/cmmi.html). The CMMI can capture a systems, acquisition, or software engineering view—with more to come down the road—thus removing barriers between business processes. This avoids an overly specific software-only language and provides guidance for overarching improvements with a clear business perspective.
Unfortunately, although CMMI documentation is comprehensive, it's difficult to use. The sheer amount of documents, pages, and perceived overlap overwhelms newcomers in particular. Two books on the CMMI offer guidance to help users navigate and find what they need.
CMMI Distilled: A Practical Introduction to Integrated Process Improvement, already in its second edition, guides users through CMMI usage patterns. It focuses on what's relevant for practical CMMI usage, avoiding many of the models' details. CMMI: Guidelines for Process Integration and Product Improvement offers a comprehensive introduction to the CMMI, attempting to include all relevant model structuring and informative aspects while avoiding the overlaps of the different CMMI flavors.
CMMI Distilled: A Practical Introduction to Integrated Process Improvement—the title alone is appealing, especially if you know about the CMMI's complexity. The book explains the CMMI without getting lost in the forest of process areas and model types. It looks specifically at the integrated approach's benefits, with its expectations and many proposals for multidisciplinary process improvement. It also characterizes the impacts and effects of implementing the CMMI's process areas from a user perspective.
The book includes a good selection of best practices for implementing the CMMI. Specifically, I liked Chapter 7, which translates the process areas into concrete implementation guidelines. Especially useful are the context diagrams for each process area (taken from the original model description), which indicate the flow and ownership of information and help users practically understand each process area's goals.
The book's eminent weakness is its size. I would expect a book with "distilled" in its title to have fewer attachments and folkloristic elements. If shortened to half its size, this book would be a real hit, especially for its claimed target audience—namely, middle management. Chapters 1, 3, 5, 8, and 11 in particular would benefit from a second distillation. What's good practice for some brandies would be good here too.
An interesting notion is the introduction to the "universal CMMI" in the forward-looking Chapter 11, which sounds very practical. Seemingly the early adopters already found improvement potential in the model. The CMMI still has a way to go before it matures, but isn't that normal in our industry?
CMMI: Guidelines for Process Integration and Product Improvement facilitates CMMI use. It compiles all CMMI model information—almost equivalent to the original CMMI framework. It describes what is common across the CMMI models and what differs. Its second part contains 25 sections, one for each CMMI process area. It sorts them alphabetically, making information retrieval easy for those who search but not for those already familiar with the CMMI staged structure, which builds on coherence and dependencies between process areas. Each of these chapters presents goals, best practices, and examples. However, for those just getting started with the CMMI, I recommend reading only Chapters 1 and 2. They offer an excellent and concise overview on the CMMI with many examples and concrete guidance.
A key strength is having the overlapping CMMI elements compiled into one readable book. Although the SEI puts the selection of the appropriate model type first—thus creating a chicken-and-egg problem for newcomers—this book first gives insight into the models and then guides users through the selection and tailoring process.
The index, for instance, is a gold nugget. Its 30 pages can answer any process improvement question—it answered all of my recent questions about assessments. The book even makes good use of its covers. Other publishers waste space, but this book's inner covers provide an overview of CMMI process areas, thus guiding the user.
One problem, however, is that although the CMMI targets different business processes, most of the book's examples are from the Software CMM. This is historically valid but doesn't help the systems or acquisition engineer. Some of the CMMI's key changes compared to the preceding and still overwhelmingly popular Software CMM aren't sufficiently explained. I missed an explanation on capability Levels 0 to 2 in the CMMI continuous model and how this relates to the staged approach starting with only Levels 1 and 2. General goals for Levels 4 and 5 remain as vague as they ever have been in the CMM literature. Concrete examples on usage and value would have helped.
Neither book helps users move from the Software CMM to the CMMI. They focus on the CMMI, acknowledging that it might not be sufficiently mature, and a newcomer or CMM aficionado might wonder why move at all, especially as the examples and guidance derive primarily from the classic Software CMM.
In addition, an overall weak point of existing CMMI literature is that it fails to address the CMMI's concrete business value, even though many stakeholders first ask about this when seeing the CMMI's complexity and cost. Although both books underline the relevance of tying the CMMI to business objectives (a major lesson learned from previous process improvement failures), they don't show how to tailor it to or use it in a small company.
The two books claim a potential value of using a continuous CMMI model, but they don't indicate how to identify which process areas to start with. What else, other than a comprehensive assessment across all process areas, would reveal the weaknesses and strengths related to business needs? They don't sufficiently explain the risks of using a continuous model or how to mitigate those risks. Nor do they clarify how to use integrated product and process development or how to deal with the vagueness of the CMMI, whose "informative parts" lead to superficial usage and incomparable assessment results. Even the extended case study in CMMI: Guidelines for Process Integration and Product Improvement is very vague, merely saying that the company selects CMMI elements "that suit the business." CMMI Distilled: A Practical Introduction to Integrated Process Improvement is somewhat clearer in mentioning the drawbacks of using the CMMI, explicitly stating that the CMMI was created with "unbalanced requirements" and doesn't cover cost requirements.
Don't try to read either book from beginning to end—they're not made for that. If you're new to the field but determined to go with the CMMI, Chapters 2,6, and 7 of CMMI Distilled will help you get started by providing an overview and useful examples.
For those who want to see what specific CMMI contents mean in detail, I recommend the CMMI overview in CMMI: Guidelines for Process Integration and Product Improvement. Its first part summarizes and structures the CMMI, while the second part provides 450 pages on CMMI process areas. This is close to the CMMI models ( www.sei.cmu.edu/cmmi/models/models.html) but still much easier to read and to carry with you than the extensive original model descriptions.
The CMMI practitioner should have both books on hand—the first for insight with practical examples and the second as a reference.
Agile Software Development Ecosystemsby Jim Highsmith, Addison-Wesley, 2002, ISBN 0-201-76043-6, 448 pp., US$44.99.
In some measure, the Extreme movement, and its slightly less out-there cousin, the Agile Alliance, are reactions to heavyweight, command-and-control, process-heavy methods. The thesis of planning, controlling, and predicting deliberate methods has been countered by a responsive, playful, and adaptive software development approach.
"We thrive on chaos!" say some. "Thinking is the enemy!" say others. The very name extreme is revolutionary in nature, as is the call-to-arms of Kent Beck's 40-hour week. Horrors!
The language is weird, too—for example chaordic, a made-up agglomeration of chaos and order, or ecosystem as applied to software development practices. Each invokes mystery and not a little fear. Whatever this agile stuff is, it's different, it's dangerous, and it has come to overthrow software development's established order.
Or so you might think. Jim Highsmith's book Agile Software Development Ecosystems admirably demystifies the entire affair and makes it approachable without body armor in an easy-to-read 400 or so pages.
Part I, "Problems and Solutions," describes the software development challenge and proposes a solution in the form of agile development processes. Part II, "Principles and People," features interviews with several agile processes proponents (including one with the author himself, conducted by Alistair Cockburn). These interviews are interspersed with chapters that describe the principles that animate the several luminaries. Part III, "Agile Software Development Ecosystems," abstracts up one layer to describe how methods respond to a team as it works on a project. Part IV describes how to develop an agile software development ecosystem for yourself in an appropriately recursive agile way.
The book's strength is that it is a chaordic ecosystem. One great difficulty in teaching a contrary concept is that the reader has an existing framework of knowledge that must be unlearned. Bald assertions such as "changing code is cheap," as Beck might say, have a certain adolescent shock value, but they can lead to the idea's rejection.
A milder, more effective approach is to chip away at the reader's assumptions until that reader comes out on the other end without knowing it. There's no direct, single, or simple path through this. Rather, you have to be gently immersed in the ideas, reading them from different angles, some of which stick. It's not predictable; it's chaotic. At the same time, it has an order to it all because the underlying ideas do conform to a framework that can be revealed only by a skillful writer at the reader's pace. Jim's writing is clear, respectful, and nonconfrontational. You can't help but be drawn in.
And what you're drawn into is an ecosystem. It's illuminating and fascinating to be faced with so many definitions of a software development process, some flatly contradictory. At the same time, the purpose—delivering value to the customer—links the luminaries together. This came through for me in Part IV, "Developing an Agile Software Development Ecosystem." Here, you can clearly see the interplay of the ideas, albeit at a high level of abstraction.
This book isn't a guide for a specific agile development method, but it does provide a view for what each one does. With that information, you can choose which guru to study more closely. Nor is it a developer's guide to a generalized agile process drawn from the author's experience. Rather, it's an intelligent effort to describe honestly how each approach works. Finally, this book is not a polemic. Highsmith recognizes the strengths of deliberate development processes, and he gives them fair play.
I approached Agile Software Development Ecosystems in a suspicious frame of mind—any software book with ecosystem in its title can't possibly be serious. I came away with a new appreciation for the idea and the ability to write chaordic without irony. Through its breadth, clarity, and honesty, this book might yet form the basis for a synthesis.