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.

I worked pretty darned hard on a process improvement proposal and submitted it the other day.

“The other day” — the day they happily granted to me after I mentioned needing a weekend to complete and return from a week’s travel. “The other day” — a business week before they actually wanted to get the project under way. “The other day” — a day which capped several days’ worth of email volleys discussing ambiguous aspects of the RFP. “The other day” — the day I felt very good about what I learned and who I became as a result of crafting the more involved parts of the proposal. And finally, “The other day” — the day I truly knew that it would be a good thing if I didn’t win the bid.

The contract had many benefits. OK… not too many. OK… Two:

(1) Name-brand client.

(2) Lots of revenue from this business unit, with hints of possible follow-through with other business units of the same company.

(2.5 — sorry, cheating) I would have had the smaller of the roles — being PM, Lead Appraiser and CMMI Instructor, with much of the leg-work being done by contractors I was bringing to the table. Meaning, 2-3 people working at any given time and I wasn’t one of them.

They rejected our bid on price alone. They claimed to like our proposal which described in detail with a full project schedule what we’d do. They reject us after I tried no less than three (3) times to get them to cut us loose before I put in the effort to write the proposal. And, after each time, they insisted that we bid nonetheless and reconsider our position so that we’d be able to bid with integrity.

The problem, as I see it now, was that they could have us bid with integrity, but I don’t believe they had the freedom to request for the bid with complete integrity.

>>>> What does this have to do with Agile or CMMI?

Probably everything.

This prospective client is easily the epitome of “traditional” companies. Probably the epitome of non-agility. And, for all I know, also emulates the epitome of an organization pursuing CMMI for all the wrong reasons.

One thing I know for sure. They are contractors to the Federal Government, which most certainly isn’t known for treating IT contractors with any consistent professional respect or courtesy.

In many ways, both the prospect and the Feds have their hands tied by pesky things like Federal Acquisition Regulations (FAR) and so forth.

Though, one of the attributes (value propositions) of my company’s approach to CMMI (the Agile CMMI approach) is exactly why they wanted so strongly for my company to bid. Yet, when it came down to it, they couldn’t keep from allowing the you-know-what from rolling down hill and treating the offerors in much the same way their clients treat them. FAR or no FAR, when they had the opportunity to do otherwise, they chose to not break the self-defeating cycle of no-trust relationships.

The style of no-trust relationships includes (but are not limited to) the following attributes:
- planting much of the risk on the contractor,
- burdening the contractor with time-based AND milestone based status reports (as opposed to actually being involved and knowing what’s going on), and
- placing a due date for something the contractor has no control over (like their ability to make progress).

Yet, they wanted *us* to take the Agile approach to doing our work.

Can everyone see why this might not have been the best contract to win?

So I made sure that we covered ourselves by describing serious assumptions and then making our prices based on market rates. No discounts.

Since they never even came back to ask about the price, I’m completely satisfied that they didn’t choose us. The contract was to be Time & Materials, so all they saw was our rates along side what we expected to be the “maximum” hours/week at each rate. (Don’t forget that the minimum could have also been ZERO.)

Their loss… and better now than later.

As you can guess, I never had a good feeling about them as a client. I had a suspicion that they’d be difficult ((hence, all my push-back)) and I was looking for anything to prove me wrong. A more mature (and sincere) organization might’ve asked whether there might have been some misunderstanding about the work that led us to price ourselves the way we did. Again, which they never did.

There’s a difference between honesty and sincerity. One can be both, and that’s usually what we all expect. Those of us who operate with integrity have no trouble being both. I also believe one can be entirely and authentically one and not the other. I think I sensed that the prospect was being entirely honest, but not entirely sincere. There was something in the way they behaved. I must’ve been picking up on that in our interview, in their RFP, and in our email discussions.

In the end, they didn’t prove me wrong and I believe we are all much better off for it. Both for not being picked as well as for going through the exercise of creating the proposal.

I’m quite busy these days as it is, and, there will be other work, so I’m in no way worried.

I guess what readers can take-away from this experience is that for agile concepts to work, you must be able to sniff out whether you will truly be able to implement agile, or whether the prospect likes the sound of it, but isn’t ready (or willing, or able) to actually let it flourish. AND — you must be ready to let it go. You must be willing to stand your ground. You must be able to see the silver lining.

The Entinex CMMI FAQ with the obnoxious name is now up!

It’s not done — there are questions that have not yet been answered, in addition to a likely world of questions we haven’t thought of.

So… Please browse and be sure to send me any follow-ups, corrections or additional questions you’d like to see answered.

On another topic: I’m at a week-long an annual event called "Consultants Camp" in a spectacular middle-of-nowhere called Mt. Crested Butte, CO.  .  I’ll blog a little more about it later in the week.  It’s quite extra-ordinary.