My Position on the CMMI

As someone engaged in software development process improvement, I often get challenged, directly or indirectly, to state my position on the Capability Maturity Model® Integration, otherwise known as the CMMI®. While this is a complex subject, and an emotional one for many, I think it is worth addressing. So here goes.

Advantages of the CMMI

1. The CMMI offers a very comprehensive model for thinking about, planning, and pursuing software development process improvement activities.

2. The CMMI is a body of knowledge that offers a proven approach for improvement of development processes.

Reservations about the CMMI

1. Its bulk. The CMMI for Development, Version 1.2 weighs in at a total of 676 pages. The sheer size of the thing makes it relatively inaccessible.

2. Its form of publication. The CMMI is a book with a cover price of $69.99 US. And the book consists of mostly text, with very few pictures. Sure, you can download it from the SEI Web site for free, but only as a massive PDF file or MS-Word document. Steve Jobs, Apple CEO (who is actually quoted in the latest edition), when recently asked about Apple developing an e-book reader, said it wasn’t worth the company’s effort, because “people don’t read anymore.” Now, while this might be an overstatement, it does reflect an underlying reality that people today are used to getting information in smaller chunks, and in multiple media (audio/video, as well as straight text). Again, the form of the work makes the CMMI relatively inaccessible.

3. Its ownership. At the front of the CMMI-DEV, V1.2 you will find the following text.

   This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a federally funded research and development center sponsored by the U. S. Department of Defense.

   Copyright 2006 by Carnegie Mellon University.

   Because the CMMI is tightly held intellectual property tied to several large institutions, including the US Government, the ability to use the thing, including the ability to train people on it, and the ability to adapt it for use in varying situations, suffers from many legal restrictions and financial burdens.

4. Its rate of change. Partially due, no doubt, to the institutional ownership issues identified above, as well as to its form of publication, revisions to the CMMI take years and years to produce.

5. Its level of abstraction. Most software developers spend a great deal of their time dealing with very technical details of languages, compilers, operating systems and databases, and/or with very specific details of the problem domain in which they are working. And yet the CMMI:

   • Avoids most of these topics that are of interest to software developers;
   • Does not even talk about software development specifically, but instead about product and service development in general;
   • Focuses only on processes;
   • Offers no guidance as to specific processes;
   • Offers a model for improvement of development processes.

   It is not much of a stretch to say that handing a working software developer a copy of the CMMI is like giving someone in need of car repair a copy of Isaac Newton’s Philosophiæ Naturalis Principia Mathematica: in both cases the problem is not that the tome is irrelevant, but rather that the level of abstraction is so far away from the problem at hand as to render the document relatively useless.

6. Its wealth of detail. Considering its level of abstraction, it seems somewhat perverse that the model is only available as a single volume of over 600 pages. If it were constructed as a graphic model, with the ability to see the whole high-level model at a glance, and drill down to lower levels of detail only as needed, then this detail would be much more valuable. As it is, it’s like including Thomas Jefferson’s grocery list and family tree in the middle of the Bill of Rights — yes, there is a relationship and yes, the additional details are of interest, but mixing them together in this way can only have the effect of obscuring the very high-level structure you are most interested in communicating.

7. Its relationship to the SCAMPI appraisal method. In theory, and occasionally in practice, the Standard CMMI Appraisal Method for Process Improvement can actually be used in a constructive way to help facilitate continuing process improvement. All too often, though, such an appraisal seems to consume a large number of resources, and produces results that are more focused on the mechanics of passing an appraisal and pleasing an appraiser, rather than on lasting improvements.

8. Its usage model. Given all of the above, the only practical way to make use of the CMMI in the field is to acquire a special cadre of process improvement specialists to study, explain, interpret and apply the CMMI within the context of a specific organization. The intrinsic problem with the introduction of such a helper class is that it seems to inevitably lead to some sort of reformation movement that sidesteps this group to appeal more directly to the actual practitioners (see the Agile discussion below).

9. Its common deployment practices. Many implementations seem to create the impression that the CMMI favors heavyweight development methodologies based on a traditional waterfall lifecycle, and the creation of lengthy documentation rather than actual working software. While these interpretations are not strictly true, they are very commonly encountered in the field.

10. Its image. One could try to sell the CMMI as a work that is really relevant to some hip young Internet startup firm, but then… see items 1 - 9. From a marketing perspective alone, these items present an almost insurmountable barrier to adoption. And it is important to note that these are much more than cosmetic issues: these are very fundamental, “the medium is the message” type issues. In our modern Web 2.0, egalitarian, empowered world, the CMMI is about as viral as the hula hoop.

11. Its relationship to Agile. The Agile movement was started in many ways as a reaction to the perceived excesses of the CMMI. Since its inception in the late nineties, Agile has seen a great deal of success and a great deal of adoption. And while the Agile movement is certainly vulnerable to criticism, there are three aspects of the Agile movement that should be particularly troubling for the CMMI:

    • Agile, either by good fortune or good planning, has managed to avoid issues 1 - 10 on my list above.
    • Whatever one thinks of the movement as a whole or particular Agile evangelists, it is hard to deny that many of the practices advocated by Agile are actually helpful to developers.
    • …and yet, there seems to be absolutely no correlation between the usage of the CMMI and the development of these specific practices found to be helpful.

    Many CMMI advocates seem to miss the significance of this last point. In the last year or two, some CMMI authors and consultants have begun to argue that the CMMI and Agile can be reconciled. This is certainly true, but it misses the point. If you have something like the CMMI that you are marketing as a framework to use for process improvement, and then you find that the most popular and useful new practices adopted by developers in recent years were mostly created by people trying to run away from your process improvement framework as quickly as possible, then resorting to lengthy proofs that such improvements could well have been developed by people working within your framework does not really alter the fact that they weren’t.

12. Its fundamental business model. The Software Engineering Institute seems to find itself today in a position very similar to that of the major record labels. The labels have traditionally justified their existence based on exclusive access to highly desirable content providers and to an efficient distribution system. In both cases, though, the variety of high-quality content providers, the appearance of alternate distribution systems, and the slowness to respond to changing circumstances have resulted in the gradual erosion of the fundamental value propositions offered by the more established business models.

My Bottom Line

So where does this leave me?

As someone who is already familiar with the CMMI, I find it a valuable reference work, and one that offers much practical advice for anyone interested in ongoing efforts to improve the results of software development activities.

On the other hand, due to the accumulated weight of the reservations listed above, I find it difficult to make use of the CMMI either as the centerpiece of a modern software development improvement effort or as the primary organizing model for such an effort.

I look forward to your comments.