- Three-Letter Acronyms
- Maturity Model Mania
- Certifications and Education
- How to Smell a Rat
- One Final Thought
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Maturity Model Mania
How do you know how "good" your software development group is? How can they get "better"? Several groups have proposed maturity models, perhaps the most famous of which is the Capability Maturity Model (CMM), which proposes a five-level, one-dimensional scale. A software team is evaluated on how defined, stable, and measured their processes are, and assigned a score. It seems logical to conclude that this evaluation system makes improvement as simple as following a checklist, discernment as easy as "Who has the best score?"
Tom DeMarco and Tim Lister sum up this issue rather elegantly: [2]
The paradox of the CMM is that process improvement is good, but process improvement programs aren’t, or at least they often aren’t. Competent people are involved in process improvement all the time: They take pride in progress and growth, and these can only come from getting more proficient at what they do. This kind of low-level process refinement is the basic hygiene of knowledge work, but formal process improvement moves responsibility up from the individual to the organization. The individual may strive for, practice, and/or promote good skills, but the organization can only institutionalize them.
I once had the opportunity to work with a "CMM 5"-rated organization that couldn’t seem to ship software that met customer needs. Some of the software actually worked, in theory, if you could keep a database connection up for a day and were willing to wait 24 hours for a report. In several cases, we simply gave up on the software they shipped, and rewrote the module or interface. I know of a second "CMM 5" organization in which a developer complained that his four-person team had dwindled; one developer had eye surgery, another quit, a third took a six-month sabbatical. Yet the project plan stayed in place, along with all of the deliverable dates. My only possible conclusion was that someone took a checkbox approach to CMM and wrote a lot of process documents that were followed just enough on a few key projects to convince the auditor that the group deserved "level 5."
Let’s forget the CMM for a moment and talk about how work is actually done.
Ironically, the way to get an "organization" to have better process—the real goal—is to get the individual contributors to be better at the work they do, whether they’re software developers or project managers. That isn’t process improvement—it’s skills improvement, and it’s difficult. It can be done through leadership—if the leader can excel at the work and communicate that excellence to those who are led. Improvement can also occur through peer dialogue, as iron sharpens iron. [3] That means that individuals are learning and adopting new practices and processes experimentally, without top-down direction; this approach requires management to give up some control.
Both of those scenarios are complex, but, unlike maturity model mania, they might actually work. Even if the organization uses CMM, ultimately a human being has to use good judgment and skill to decide which key process areas to work on, and how to get there.
I should add that I’ve met several CMM consultants who took the job seriously and worked hard to improve organizations, with positive results. When I get down to talking to them about what they actually do, it turns out to be a lot of mentoring, coaching, and skill development.