In his unique style, Hillel Glazer clears up confusion — while perhaps even standing on one leg — around CMMI in this video. He says it’s what to improve, not how, and that every CMMI practice avoids a risk so you can use the practices as guides to finding where you have issues.
Agile-and/versus-CMMI has been a topic of lots of debate recently here at Cutter. For example, Hillel wrote in “Agile vs. CMMI: The Debate Goes On“:
Jens Coldewey’s Advisor “Why ‘Agile vs. CMMI’ Leads Down the Wrong Track” rightly argues that “Agile vs. CMMI” is not the right direction to go. However, he assumed a particular (and common) perspective about CMMI and in doing so left out a few key points about both CMMI and agile that must be mentioned as well to complete his argument.
The common perspective on CMMI is a “ratings-centric” one. Jens’s argument is completely solid once it’s noted that taking a ratings-centric use of CMMI indeed makes all the mistakes he notes of prioritizing processes over business results. A ratings-centric use of CMMI is one where attaining “maturity level ratings” become goals in and of themselves, irrespective of the lack of business value these ratings are meant to imply.
A few of the key points about agile and CMMI would also strengthen and (in my view) complete Jens’s already strong argument, and arm CMMI and/or agile proponents with what they need to avoid many of the common missteps both of us have run across in our respective work.
The purpose of CMMI is not to achieve level ratings. The purpose of CMMI is to identify and address areas of a business’s operation where it is exposed and/or not performing as desired. Not all of CMMI’s practices necessarily make sense to address because many businesses don’t have any issues with many of the practices. And, in those cases where a business doesn’t have any issues, there should be ample evidence for an appraisal (if an appraisal is nonetheless desired).
Making the use of CMMI exclusively to achieve ratings is a stupid idea. Businesses that don’t use CMMI correctly deserve losing in the marketplace. Executives who allow (or make) this the purpose of using CMMI should be fired or abandoned.
CMMI can be used to help improve an organization’s performance in conjunction with disciplined agile practices. But even agile practices can be implemented just as stupidly. Consider, for example, pair programming. It is a great idea when it works and a great idea when it reduces errors, defects, and rework. It is a stupid idea when you don’t know your error/defect/rework rates and all you know is that every feature now costs twice as much. Don’t laugh. I’ve seen this, too.
While Jens and I might disagree with equating “agile” with “undisciplined” it would be incongruous to ignore the plentiful examples of dreadfully undisciplined “agile” adoptions resulting in “agile in name only.” There are a large number of CMMI “adoptions” and appraisal ratings where the “maturity level” is “mature” in name only. This problem is on both sides of the table and users of both should not be pointing fingers at the others as though they’re completely innocent of misbehaving.
From this, rounding out Jens’s argument, we could then point out that for both agile and CMMI, it’s not about the practices but about the behavior and discipline behind the practices. The ratings in CMMI don’t make organizations mature, any more than the agile practices make an organization agile. It’s the work, discipline, and leadership behavior, the incentives and rewards, the meaningful work, and the autonomy that agile and CMMI both facilitate — when done properly.
What’s your opinion? Want to chime in on the discussion (debate?)?