Templates towards CMMI

The antithesis of agile CMMI

A recent prospect of mine chose to hire a "competitor" whose value proposition is that they sell templates for performing practices of CMMI. Then, the firm comes in from time to time and audits how well the templates were completed.

That's all well & good from a CMMI appraisal perspective, as far as "the letter of the law" is concerned, but on many planes of existence, it not only runs entirely opposite of an agile approach (which I'll get into shortly), but it hardly demonstrates process improvement!

What this sets-up is the following scenario:

Before Templates: Unknown management practices, and unknown development practices. Status quo.

After Templates: Unknown management practices, unknown development practices, PLUS a new set of (likely ill-fitting) unfamiliar process improvement practices -- completely unconnected to, disassociated from and lacking interface controls to operate with their existing practices -- OH WAIT! They never bothered to figure these out!

At lower maturity levels (ML 2, specifically), it's not hard to skate by the appraisal using nothing more than very basic (even garden-variety) templates that channel enough data onto 'paper' to be used as evidence that there is a process and that it was followed. Notice I didn't say that there's process improvement going on, I just said that according to the rules of the appraisal, one could have enough template coverage -- strictly speaking -- to make it through the appraisal.

However, when venturing into ML 3 territory and above, this approach simply fails to produce the kind of indicators that tell an appraiser that a process improvement system is in place. Why? Because at ML 3 and beyond, the evidence needed isn't that there's any ol' process in place, the evidence needed is that there's an actual process improvement system in place. Doing that through *someone else's* templates is just simply too painful to be practical.

But let's not get into a discussion on the viability of getting a Maturity Level 2 rating via store-bought templates. The subject here is whether or not such an approach is even a smart thing to do. It's not and here's why:

Most templates written by other organizations and used by software developers to "comply" with CMMI do not naturally reflect the work being done by the developers. Sometimes there are some lucky shots, but usually, the templates do business one way, and the company does business in another. This sets up a situation where developers and project managers need to take a break from being productive and work on the production of artifacts. As often, the templates may require the production of some additional piece of documentation otherwise useless to the organization's way of getting things done (requirements traceability matrices come to mind).

For these reasons alone -- though simple to describe, they're quite significant -- using off-the-shelf templates towards CMMI ratings is strongly discouraged for true process improvement. However, allow me to shed some light on a fact that few companies lax enough to take this route will know (until it's too late):

During the appraisal the lead appraiser might ask you for additional evidence than what was presented. During interviews, the appraisal team might ask questions that don't come from the templates and don't sound like CMMI. This isn't being "tricky" or trying to "trip up" the company, it's just being thorough in investigating the actual maturity of the organization's capability. You see, the appraisal is about hearing, reading, and in some respects telling the tale of the company's process story. If the story doesn't hold together, it brings into question the comany's true ability to affect process improvement. Of course, if the people who sold you the templates are the ones doing the appraisal, that's a whole 'nuther ball of rubberbands.

And really, exactly how "mature" is an organization's process capability anyway if all it did was fill out templates that have nothing to do with how they actually do work, let alone improve their processes?

As for agile, I'm pretty sure readers of this blog don't need me to point out just how non-agile this approach is -- whether for development, or CMMI.