"CMMI is full of big scary words."

A rather simple yet poignant comment by my dear wife, Jeanne, who was responding to a discussion we were having about my Hedgehog Concept.

It so happened that I had just returned from a meeting with a client at which I diffused a contentious exchange over the matter of Configuration Audits. 

For an example of why there’s confusion, and why there’s contention, visit the above link.  The answer provided to the question comes straight from the CMMI model text.  By contrast here’s my explanation of what CM SP 3.2 expects:

In plain-talk, CM SG 1 would have us figuring out what we want to control the configurations of and a way to finger a given configuration of one of those controlled things at various points in time (or space).  SG 2 has us making sure that the things we want controlled only change when we want them to change and that we know what those changes are.

With all this emphasis and energy directed at things changing under a watchful eye, what SG 3 is saying with SP 3.2 is simply this: you don’t want anything slipping through, so make sure SG 1 and SG 2 are working, OK?

Wasn’t that so much easier?

Most companies worthy of their products are probably doing something to that effect anyway; CMMI is pointing out that it’s probably a good idea to now be doing it regularly and on purpose.  After all, in development, a really bad day is when the customer calls and complains that the supposed "update" you sent to the product actually took out some nifty features they kinda liked when you sent them the previous update.

This episode of the AgileCMMI blog has been brought to you by the letter J and the number 3.2.

No, it’s not my rendition of Einstein’s definition of insanity…

So I’ve been saying the same thing over and over again lately… maybe because it’s so succinct and readily accessible to even the least process-oriented among us.

It goes something like this:

"CMMI is a model from which we build process improvement systems."

That’s it.

All you need to understand to internalize this is the notion of a model and the notion of a process improvement system.

If you can wrap your head around these two notions the CMMI and what it’s not simplifies a lot.

How?  Just consider the notion of a model: an idealized, often fictitious, representation of a particular instance of reality, that’s usually missing much of the detail that the real object represented by the model would include.  What that means is that models can’t be applied directly as a solution.  One must take a model, learn from it, then combine it with their own knowledge and context of how they plan to use it in order to create something in the real world. Mixed into this would be the details to make what started as a model into a usable system.

Think: model of an aircraft or home or building. Even human models used in magazines are two-dimensional — lacking in everything that makes them real humans except their appearance. Even life-sized enlargements of a photo are still just models. In fact, if we explore the fashion model idea further we could see many more appropriate parallels between the idea that a model is as incomplete as it is an idealistic version of reality.

I’m finding more and more that it’s this basic gap in people’s understanding of what a model is, and/or in their ability to take a model and build something from it that gives rise to so many failed CMMI implementations. And, it’s these (often spectacular) failures that provide the casual observer their negative impressions of what the CMMI is and how it’s meant to work or what it’s meant to do.

In a recent conversation with someone hired to speak on agile methods and to contrast them with CMMI, it was this misplaced impression that he began the conversation. As soon as we discussed the concept of "model", his (very authoritative) opinion on the matter was shifted.  In fact, the content of his lecture was altered. He could completely see how CMMI and agile methods are not intrinsically at odds. After all, how can a model be at odds with a development approach when one of the model’s elements says, in effect, "pick a development approach"?

So, what does it take to take a model and from it create a real-life system?
That’ll be my next topic.

(Hopefully sooner than in a month.)