Happy Holidays!

Greetings All!

Although Hanukka has already come and gone this season, in many "Western" cultures this time of year is when many people take time off and nestle with their families in their homes or elsewhere, or jaunt off to their favorite vacation spots -- and generally take a well-needed and typically overdue break from the usual routine.

I'd like to take a moment to thank everyone for their readership and interest in the subject and to wish everyone a very safe, happy, healthy and Peace-filled December/January Holiday season.

OK, since you're here, I'll offer-up a thought or two about Agile + CMMI.
Looking back on the year, we (Mike Konrad, Jeff Dalton, Mike Phillips, and others) are working on a publication on the topic (official from the SEI and everything).

Between that effort and my other work and reading it's becoming painfully clear that the supposed rift between CMMI and Agile is really a matter of bad PR. CMMI is poorly understood even among too many seasoned process professionals. And, Agile is frequently abused by developers feigning use of defined development methods or management seeking new ways of cutting corners instead of actually reducing improving productivity and/or reducing waste.

I've also noted some other interesting observations along the way.

It seems to be easier to explain:
-) the correct concepts of CMMI to a true agile practitioner or
-) agile concepts to one of the few process professionals who understand CMMI correctly

than it is to educate:
-) a supposed process professional deficient in both CMMI and agile knowledge such that they can be proficient in either/both, and
-) I assume the same can be said of teaching agile concepts to the hard-line agile posers (let alone teaching them proper CMMI).

So... in this regard... let me make the following offer:

Please contact me if you're interested in working in Agile+CMMI consulting.
2008 is lining-up to be quite exciting here, and I'm always looking for folks who "get it".

All the best.

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.