Is CMMI Dead Yet? If Not, Can It Be?

In the early days of software, the US federal government funded software projects using many different contractors. The results varied wildly. Many projects overran their budgets and schedules. Even more concerning, the overruns were unpredictable. The government then funded a study to determine why. The result of that study was the Capability Maturity Model, or the CMM. The CMM was used to objectively evaluate software subcontractors' process capability maturity. It then evolved into the CMMI (Capability Maturity Model Integration) and was later applied to other disciplines beyond software. The CMMI is, and has always been, a placebo used to pacify buyers. The primary motivation for a firm to attain the CMMI status is to win contracts. CMMI has had decades to prove itself, yet has had no meaningful impact in the broader technology space. The market clearly has not chosen it over other methodologies. Its time has passed, and it needs a proper burial.

CMMI was essentially a signal from the government that it could not stomach such extreme variance. Why do different shops in different locations behave so differently from one another? Further, why do individual software firms change their behavior from year to year? The answer should be obvious: because the people are different, and companies are just collections of people. A-ha! If we could only institutionalize the process, then we would not be so reliant on the individual constituents of a team. In a nutshell, CMMI says that process should be institutionalized and codified. That way, even if the entire team turns over, the train keeps on moving forward. We don’t have to worry about things like “bus count” in a CMMI shop; our process doesn’t live in the heads of individual team members. It is thoroughly documented and understood throughout the organization. Except all of that is patently false. Any business that could put its process in writing and replace teams wholesale has already been offshored to low-cost countries.

CMMI sounds good when you first learn about it. Putting process rigor around an activity that is inherently erratic. Everyone has been through a series of chaotic events and just barely managed to string them together successfully to reach the finish line. Whew! You did it! You fell down the stairs and landed on your feet. But could you do it again? Proponents of the CMMI are making the claim that if you adopt the practices, or hire a CMMI shop, then you're entering the land of the "mature." Leave the little boys behind; welcome to big boy land, where we don't miss deadlines and you can set your clock to our cadence. It's easy to see how this could be a salesperson's favorite bludgeon.

A major problem with CMMI is that it downplays the uniqueness of every software project. It presents the illusion that producing software that meets specification is a matter of inserting the requirements into the mouth of the machine, then turning the crank. Out of the other end pops working software! A nice idea, but not how things work in reality.

The notion of the team as an autonomous unit has exploded in popularity, and for good reason. Letting teams decide what works for them really plays into the people side of the equation.  Individuals will come and go, changing the team chemistry over time. As the team makeup changes, it should be empowered to adjust its processes accordingly. A business with ten scrum teams may be highly successful despite the fact that those ten teams do not all file the same paperwork. This business would be described as a CMMI level 2. In CMMI level 1, the process is characterized for projects (project teams). If you want to reach level 3, then the process needs to be characterized for the entire organization, which means you can no longer let teams determine their own ways of working. All teams need to do things the same way and produce the same results.

What’s wrong with desiring consistency? Nothing, if you like mediocrity at scale. Imposing process consistency across an organization of any size is basically a race to the middle. It’s like an audio compression algorithm that chops off the peaks. Those rich lows and highs are gone. The high-functioning teams that far outperform the others will be told to fall in line with the C students. If you have a high-performing team with high-caliber talent, that team will see right through you. They'll know that you are trying to manage skill and talent out of the equation in favor of process. And they will be somewhat repulsed.

Which brings us to another valid question: is a workplace that embraces CMMI a job smell? For a developer who has worked hard to elevate his game, it's off-putting to be handed a paint-by-numbers coloring book. Especially if you believe that it won't result in a better outcome. High-caliber developers want to work with other high-caliber developers. A company that has a modus operandi of “document all the things and follow the script” may have a hard time attracting talented people. And why would a company like that expect to attract talent when its stated goal is to manage talent out of the equation?

Bless their hearts: all investors want is certainty. That’s all any of us want, especially when we are writing checks. But when you venture into the world of custom-built software, there is no certainty. An enormous amount of papers have been written and talks have been given that say the same thing: stop looking for certainty, because you won’t find it. Better to manage the uncertainty. Endeavors that require skill and talent live outside of prescriptive process. Consider a position like the CEO. Everyone recognizes that the CEO of a company is a key player and that changing the CEO can directly impact a company's stock price. What are the intangibles that he or she brings to the table? Why does no one talk about just codifying the process of CEO-ing? "Just write it down! Then we can hire a new CEO on the cheap and tell him to RTFM." Software development is a skill game, and intangible skills are a huge differentiator. The idea that developers are fungible laborers is nonsense. The CMMI reeks of devaluing individual people. Management simply does not want to hear that they are beholden to skilled individuals, so they latch onto the false promise of transforming skilled labor into unskilled labor.  But the fact remains that you win by having better players, not a better playbook.

If CMMI were a clear winner, the market would have chosen it. But even though it's been around for thirty years, it certainly hasn’t emerged as a winner. In fact, the last thirty years have mostly been dominated by frameworks and processes that run counter to CMMI’s core tenets. The 2000–2020 era clearly has been dominated by Agile. But Agile has sat on the throne for long enough that many in the software space are looking back and asking if we should go back to where we came from. It appears that profiteers may be poised to cash in on Agile fatigue, and they expect the world to run back toward CMMI. In March 2018, CMMI 2.0 was introduced. And for the first time in CMMI history, it wasn't offered for free; the cheapest option was one-week access to the online version at $150 USD. CMMI has no place in a post-Agile world. Let it die peacefully, and stop trying to resurrect it.