Proper and Improper Use of CMMI

Just a few thoughts on some questions to pose as a sort of “guide” for whether or not you might expect benefits and value from using CMMI.  These also have the benefit of helping CMMI be implemented in a more lean/agile approach.

When implementing CMMI, Are you seeking . . .

• Improvement or Compliance?
• Empowerment or Definition?
• Clarity & Awareness or Constraints & Rigidity?
• Bottom-up input or Top-down direction?
• To understand whether what you’re doing is working?  or Whether you’re doing what the process says?

In this case, we also value the things on the left more.

:-)

The things on the right are a longer road, with questionable benefits and many risks.  The things on the left get you to benefits and value sooner with less carnage and baggage.

Take your pick.

Picking a Lead Appraiser: "Dammit, Jim! I'm a doctor not a bricklayer."

In this quote, CAPT Kirk wants Dr. Bones McCoy to do something he feels he's not-qualified to do because he doesn't know how to treat the species.

  

I'm using it to explain that organizations looking for a lead appraiser to work with them towards an appraisal and/or to perform an appraisal ought to think of what we do as they would think of a doctor, not a laborer or vendor. 

Do you really want the lowest price doctor?

For that matter, is the highest price doctor necessarily the best in town?

When reaching out and interviewing for a lead appraiser or CMMI consultant, you:

• Want the person who is the right person for the job.

• Want someone who is qualified (definitely not under-, but preferably not over- either).

• Not the lowest bid.

Seriously, whoever you hire for this effort has in their power the ability to make or break your future.  They literally have the health and well-being of your organization in their hands.  They can put you in the dump just as easily as they can take you to the next level.

They should see themselves that way as well. 

Unfortunately I've got too many sad stories of appraisers/consultants who definitely see that they can make or break you, but they don't feel like they personally own the responsibility for what happens to you when they're done. 

If it costs too much?  So what?  
If you get no value?  Not their problem.  
Didn't see any benefit?  Didn't learn anything?  Things take longer and cost more and you're not seeing internal efficiencies improve?
YOU must be doing something wrong, not them.

In an AgileCMMI approach, your CMMI consultant and/or lead appraiser would see themselves as and act like a coach, and would put lean processes and business value ahead of anything else.  And, an AgileCMMI approach would know that when the processes work, they add value; when they add value people like them and use them; when people like and use them, the next “level” is a big no-brainer-nothing.  You get it in your sleep.

Let me know if you want help finding the right lead appraiser or consultant.

Worse than Worthless . . .

Your people with prior CMM/CMMI experience are probably worse than worthless, they'll probably cause you to fail.

Why?

Because what they (or you) think they (or you) know is probably wrong and the advice you’re getting, the expectations being generated are entirely off base.

It all goes back to the many ways in which CMMI can be done poorly and the few, simple, but hard work ways in which it can be done correctly.

Every time I meet with a new prospect I’m confronted with reams of inaccurate assumptions and assertions about what it will take to implement CMMI and how am I expected to “do all that” and still claim to be “agile”.

My simple answer: I’m not going to do all that.  And, you shouldn’t be doing it either.

Seriously, you’ve got to wonder about executives who will force their company into doing stupid things for the sake of a rating instead of doing their homework to learn about CMMI before they head out on an implementation journey.

A recent client didn’t know any better.  They hired a consultant and an appraiser to evaluate their work against CMMI and to help them prepare for a SCAMPI appraisal.  Unfortunately, they got as far as the appraisal only to realize they weren’t going to get the target Maturity Level.  (I won’t get into some of the inappropriate behavior of the firm they hired.)

However, when this client was confronted with:

1. Do something stupid, or
2. Find a better way to do something smart.

They took option B and found a consultant and an appraiser who understood their context and found how to both be on a disciplined improvement path while also remaining true to their own business.

Fortunately for them, this client had a strong engineering backbone and knew what they did worked and were confident in their processes.  Many companies have a while before they can claim that much.

Next week:

Picking a Lead Appraiser:  "Dammit, Jim!  I'm a doctor not a bricklayer."

CMMI is overrated and unnecessary...

This entry over at OpenSource Connections got me thinking.

They're absolutely right.

I've even said as much myself at NDIA's 6th CMMI Technology Conference in 2006 in response to a question.

The question was something like, Are you saying that CMMI isn't necessary if our company believes we are fine the way we are, and we don't see any need to improve?

My answer was pretty much, "yes".  I added, if a company is OK with the status quo and competition isn't a concern, and their leadership doesn't believe in the business rule-of-thumb about not moving forward is the same as falling behind... then yes, CMMI is overrated and unnecessary...

... for companies who don't worry about lottery-sensitive individuals, or rapid growth, or shifting products, or who are quite content with the strength of their client relationships that they need not worry anyone will step in and oust them or bring in competition.

I'm always thrilled when I come upon a software company that has its act together like OpenSource Connections seems to have.  However, as regular readers know, I'm not as thrilled that the folks over there have an entirely inaccurate perception of CMMI as the ability "to check certain boxes about whether or not we have a laundry list of processes documented and implemented."

CMMI's language certainly makes one believe the assumption in the model is that people aren't doing the right things.  However, the exact wrong way to view or use CMMI is as a list of check-boxes.  Anyone found performing an appraisal in that way ought to be reported to the SEI.

But that's not the point of this post.  The point here is that you should read the OpenSource Connections post.  Even with their misunderstandings they make good points.

One point about the reality of level-rated organizations (even high-maturity ones) can still deliver junk is right on the money.  Not having done an in-depth study myself -- not sure anyone has -- I'd venture that most level-rated organizations delivering junk took the check-box approach to CMMI, whereas the ones who took a business-value approach to CMMI actually deliver customer delight and high profits.

Another point about process having a place in agility was also crucial to giving their entry credibility.  Recognizing that even small, agile organizations do have processes and rely on them for success is a think of beauty.  More organizations would be successful if they understood this much about themselves.

Their shortcomings in understanding CMMI are excusable, the points I wish to surface have to do with a few aspects they didn't address.

One thing CMMI helps avoid (but, by no means is the only solution for) are issues with know-how that's locked in individuals' heads.  Or for dealing with a customer-base that expects specific people to be doing the work.  Even with this CMMI isn't required, and certainly not an entire maturity-level rating, but if an organization is facing these issues and doesn't have any idea what to do about it, parts of CMMI can help.

Which brings me to my second point for the moment.  Maturity Levels aren't the only way to use CMMI.  In fact, even with capable organizations, many find that being able to borrow practices and goals from particular process areas may help them fine-tune an already working operation.

Whether an organization bothers to pursue even a Capability Level for any process area(s) isn't even where I'm going.  Being "rated" has nothing to do with being capable or mature at development.  CMMI has value whether or not organizations choose to get rated; whether or not they choose to use entire maturity levels, entire capability levels, entire process areas, or even entire goals.  CMMI can add value one practice at a time.

Organizations that have their act together could probably do very well with an appraisal and learn a lot about themselves.  Limiting the value of CMMI to whether or not the organization has had an appraisal limits more than CMMI; it limits the business value of creating the efficiencies, knowledge longevity, and ROI for looking into their own processes at all.

Expand the scope of "value".

I get common resistance from agile proponents that part of the agile philosophy is to only perform activities that add value to the product, and thereby (the assumption is) to the client. This is often a stumbling block for the "lean" folks too.

The argument goes along the lines of: much of the CMMI practices to "maintain" and even many of the practices to "establish" certain work items don't add value. If not, why do them?

It's a strong case. But strong cases for not doing practices don't make for organizations that can get through a SCAMPI (CMMI appraisal) and end with a maturity level rating.^*

So what is there for an organization to do?

There are two ways (non-exhaustive and not mutually exclusive) to re-factor this thinking, both of which involve adding long-term value in addition to immediate value:

1) Adding value to the organization, and
2) Adding value to the future product (or, to the product in the future).

In the first approach, process activities are seen as adding value beyond the immediate project. Process activities are seen as an investment in the efficiency and productivity of future projects. And, on sufficiently long projects, these activities can provide feedback in time to make a difference to the projects underway and from which the process data is being collected. This approach adds value to the business in terms of know-how, intellectual property and competitive edge.

The second approach, while similar to the first is product-focused. In this view, the value in doing the process activities is in being able to reduce maintenance costs, make updates/upgrades less cumbersome or expensive and make the product more extensible. This often goes handily with allowing the developer to be different from the operator, the maintainer, or the help desk.

Many paradigms of process improvement use the metaphor of "throwing the product over the wall" as a means to describe what happens when products are developed in a serial, production-line fashion and not as an integrated, high-trust, highly communicative team (sound familiar?). The very antithesis of agile development.

Well, here's a wake-up call for some people, including self-proclaimed agile developers: the "wall" eliminated by integrated and agile development teams is not only between steps in the development life cycle. Sometimes the wall that needs eliminating is temporal. That is, stop throwing your well-tested, peer-reviewed, non-wasteful code over the wall for someone in the future to have to deal with. Most of us have had to make sense of someone else's spaghetti code at one point or another and we shouldn't be the ones to create it even if we did so by being lean and agile today while sacrificing the value of the product in the future.

So, the value we're trying to eek out of our process activities ought to take this sort of long-term view of "value" Some also refer to this as "Total Cost of Ownership" or TCO. Process activities ought to be calculated on the basis of TCO for the organization and the product.

In both approaches, the value being added to the organization as well as to the product is a reduction in waste. Companies don't become lean over night and they don't become great at agile practices with 2 days of stand-up meetings or one 30 day sprint. Often taking the time to identify, record, be methodical about, and update the organization's approaches can help find what works and eliminate what doesn't.

Really.... CMMI isn't what complicates this, it's not understanding CMMI that owns that job.

^* Let's be clear about something... Achieving a maturity level (or capability level) rating should not be any organization's goal. Improvement should be. PLENTY of benefit, value and improvement can be had without *ever* being appraised and/or without ever attaining a "level" rating. However, for obvious reasons, achieving ratings has other value, such as being able to compete for certain customers and in certain markets.