Last month I wrote some harsh words regarding the Capability Maturity Model (CMM) and its latest incarnation CMM Integrated (CMMI). The CMM/CMMI effectively defines the requirements a system development process should exhibit, and does a good job of it.
My issue isn’t with the requirements,
it’s with the rather poor implementations of CMM/CMMI-compliant processes I’ve seen over the years. My specialty is software process improvement (SPI), so it behooves me to keep abreast of a wide range of process options. I’m the thought leader behind a few methodologies, including the Object-oriented Software Process (OOSP) in the mid-1990s, which when implemented fully is CMM-level five compliant. I’ve worked with a wide range of organizations — from Internet start-ups to retailers to financial institutions — on three continents helping them to adopt and/or improve their processes.
In Agile Software Development (Pearson Education 2002) Alistair Cockburn writes about the three levels of methodologies: Level 1 methodologies describe processes and techniques in great detail; Level 2 methodologies overview several ways of working, providing examples and advice for when to apply each technique; Level 3 methodologies describe issues for consideration and suggest techniques without giving details.
Level 1 methods are targeted at those who are novices at delivering working software. Level 2 methods are geared towards organizations with people who can successfully adjust the techniques as required. Level 3 methods are for organizations with a large percentage of true IT experts. My observation is CMM/CMMI is attractive to bureaucrats in Level 1 organizations, people who don’t have the skills to do the work, but want to manage the novices that try to do it.
Some will disagree, arguing the CMM/CMMI helps organizations improve their IT processes. That’s true, but we never see comparisons of CMMI-certified organizations, which I contend are usually Cockburn Level 1 organizations, with Cockburn Level 2 or 3 firms at a similar CMMI certification level (if they were willing to be audited). I suspect the results wouldn’t favour the CMMI shops and I invite the research community to look into this.
There is a simple way to determine if the pro-CMM/CMMI contingency in your organization is worth listening to: Have them form a team and ask them to build a working system. One of three things will happen: The team won’t be able to deliver because, being bureaucrats, they don’t have the skills to get the job done. If they don’t know how to build software, why would you take advice from them on it? Second, they will deliver, but won’t follow the same inane procedures they want you to adopt. If they don’t have the integrity to follow their own procedures, why should you? Third, they deliver by actually following their own processes. I suspect that this will happen in less than five per cent of all cases, but if it does, you should likely listen to what they have to say.
E-mail me with your experiences.
