CMMI, Improvement, Software Development

CMMI Take 2

I received a fair amount of feedback on my last post about the CMMI® – all of which I very much appreciated – and I thought I would take another run at this subject in order to clarify some of my thoughts in this area.

Let me break this down a little differently than I did last time, and talk about five different areas.

1. The Content of the CMMI

As I said in my last post, I find the content of the CMMI to be very valuable. It is a very useful work on process improvement, especially for development environments.

2. The Times in which We Live

A lot has changed in the last 20 years or so since the original CMM was conceived. The Internet and the Web were born. We have grown less comfortable with hierarchical control structures and have moved towards a more egalitarian society. Web 2.0 has come along. Search engines, wikis, blogs, and social networking sites are changing the ways in which people create, locate and access information and connect with other people.

3. The Form of the CMMI

Most of the reservations I expressed last time were about the form in which the CMMI is made available. I did not mean these to be taken as general objections – I was an English major, I like long books, and I resented Steve Jobs’ comment that people don’t read anymore – but rather as observations that the form of the work limits its accessibility.

In particular, I find that the form of the CMMI is not a good fit for the times in which we live. Again, this is not a personal issue for me – I’ve got a copy on my bookshelf at home, another one on the bookshelf in my office, and I actually open it and read pieces of it on a pretty regular basis – but I find it hard to convince other people that they should make similar use of it.

The implication here – which I left implicit in my last post, but which I will now make explicit – is that I believe the CMMI would be much more useful if it were actually published in a different form. In my more fanciful moments, I picture something like cmmiwiki.org, that would allow users to update and comment on the text, with a companion social networking site where people could exchange stories about how they have found the model to be useful.

4. The Ways in which the CMMI is Used

I believe there are roughly three ways to make use of the CMMI as part of a process improvement effort.

a. The Developer Direct Access Approach

One could give every developer a copy of the CMMI, tell them to read it, send them to training, and ask if they have any questions before putting it to use.

Most people agree that the CMMI is not intended to be used in this way, and I even took some heat over my last post because I seemed to imply that the CMMI should be something directly accessible to the average developer. So I think we can pretty quickly dispense with this option.

b. The Back Room Approach

The organizational process improvement experts could keep a copy of the CMMI hidden in a back room somewhere, and consult it whenever they feel the need of its inspiration and guidance.

I don’t have any problem with this sort of usage, and this is actually a close approximation of how I am attempting to use the CMMI in my current assignment.

c. The Centerpiece Approach

Here is the way the third option usually goes, at least based on my experience.

• Someone convinces the highest-ranking executive they can find to make a public pronouncement that organization xxx is beginning its journey to CMMI level y, to be completed in zz months.

• Anyone who questions the wisdom of this approach or the feasibility of achieving the goal in the announced timeframe is cheerily asked to report to the cafeteria at 9:00 AM on Friday to find out more about their new career options.

• Maturity progress indicators are embedded in leadership’s balanced scorecards as part of their annual goal-setting exercises, because what gets measured gets done, right?

• A cadre of process improvement focals is recruited and sent out to the developers to help them increase their maturity.

• When developers show any lack of fortitude or conviction about becoming more mature, they are promptly told that the CMMI requires that they perform practice xyz, and they are reminded that the CMMI’s authority is backed by executive decree and reinforced by annual goals that they are already behind on.

• Even though much of the CMMI is suggestive rather than prescriptive, developers are strongly guided to conform as closely as possible to the language and examples used in the CMMI so as to minimize the risk that the appraiser will get confused about their maturity level during the upcoming, very expensive, highly visible and eagerly anticipated SCAMPI appraisal.

This option is the one I was expressing reservations about in my last post, when I said that I would hesitate to make the CMMI the “centerpiece” (i.e., the highly visible focal point) of a modern process improvement effort.

There are a couple of important points to be made about this approach.

First, the very form of the CMMI encourages this approach: the daunting book form, the high-risk, high-cost nature of the appraisal, etc.

Second, this approach is an extremely hierarchical one, and so is not a particularly good fit for the times in which we live.

5. Comparisons with Agile

I also took some heat from some respondents to my last post for making what they viewed as an apples-and-oranges comparison between CMMI and the Agile movement.

From a purely conceptual point-of-view, I agree that the CMMI and Agile are not in competition and, as the SEI has suggested, we can indeed embrace both, especially if one chooses my option b above (the back room approach) in terms of a CMMI deployment strategy.

From a marketing perspective, however, it seems inescapable that Agile and CMMI are in competition for mindshare within the software development community. Embracing both is difficult, not only because so many people view them as antithetical, but for the very practical reason that, as hard as it is to become a credible expert on either one of these approaches, it is that much more difficult to become an expert on both.

And, in contrast to the CMMI, the Agile movement is an extremely good fit for the times in which we live. Take a look at the table below.

If you look at the table above, it should be readily apparent that the CMMI column represents an almost classic definition of a hierarchical approach in which authority flows down from the top of the hierarchy (SEI -> Appraisers and Trainers -> Organizational sponsors -> organizational process group -> practitioners), while the Agile column represents an equally representative definition of an egalitarian approach in which peers freely connect and learn from each other. And, although I wouldn’t argue that either approach is right or wrong, I would argue that the more egalitarian approach is a much better fit for the times in which we live.

Which is probably why, when I observe developers talking about the CMMI, the most common comment I hear is that “I had to create this document because someone told me I needed it to pass my CMMI appraisal… but no one ever uses it.” When I observe developers talking about agile, though, I most commonly hear them eagerly sharing the latest blogs, white papers, videos or podcasts they have come across on the Web.

Summary

Again, I do not argue that any of the above renders the contents of the CMMI obsolete. I do contend, though, that these issues make it very difficult to use the CMMI as the centerpiece of a modern software development improvement effort.

April 15, 2008

Next: The Documentation Dilemma