Some Things Seem Odd Together at First Glance: Agile and CMMI

So Craig Brown, who used to link to my blog (?) happened to mention to me that Scott Ambler was working on a CMMI for Agile development shops. First I was jealous that he knew and I did not. Then, I was upset with Ambler. Then, it seemed to somehow make sense although at first glance, it was pretty awkward.

Agile with the capital A is not something I really believe in, since it is a Universal and we live in a world of particulars. I would not walk into any organization and mandate strict Scrum as documented by any authority on the subject. As you know, a large part of what determines the success of an endeavor is the circumstances that surround it. These variables include people, corporate culture, and a whole slew of other things that do not fit neatly into the PMI model, the MSF model, or the Agile model. I do believe in being agile, with a small “a”, because all it is saying in reality is that you will be building software in an informed manner. You will count on your talent, involve your Client, be flexible, all those things that I am sure you are more than familiar with. Do I *need* to do peer programming? 10 minute Scrums? Have a burndown chart? Of course not. None of these things are mandatory. You use them where it helps. You leave them where they cause undue pain.

Ambler’s attempt at writing a CMMI for Agile seems ostensibly silly. Seems like herding cats, and yes, I will give credit to everyone who thinks they invented that metephor. I do not want it. I do not particularly enjoy cats and would never want them in one large meowing mass. I’d rather shoo them. Shooing cats can be done. Herding cats… not so easy. Doesn’t make sense.

But how many times have you, as a PM, Agilist, or IT professional come to an organization that is interested in “doing that Agile thing” and has no real idea about what it entails? In some cases, with really dynamic, enthusiastic, bright-eyed teams, it is not so hard to introduce and get traction with some Agile tenets. However, I can think of at least a few organization where every developer had that endless stare into their CRT displays, lost in the miles of code ahead, hope long abandoned. They have cobwebs on the brain, and it isn’t their fault, but it is a different effort to get them on a new routine and thinking a new way. The motivation isnt always there.

I do not think it will be much like CMMI for MSF, since MSF is at this point all but proprietary. Ambler makes a quick buck or two with every book he pumps out, and the reviews lately have been more or less “he says the same thing 12 different ways and I already knew what he was going to say before he said it, typos and all”.

On closer inspection, even Cockburn is involved in this Agile CMMI effort. He wrote the book that I learned fully dressed Use Cases from. Interesting. This kind of apparent conflict of intent has been anticpated and you can check out this nifty slideshow on CMMI / Agile / Isnt That Odd if you are stuck oddly by the concept. It is pretty cool, albeit a bit salesy for me and I am wondering who will produce the first CMMI Agile certification program.

Still, mating CMMI with Agile is kind of just saying, “if you are going to practice agile development, be aware of the discipline and yeah, every case is going to be a bit different so as much as you need discipline, part of that needs to be a willingness to change and respect your team more than your process…”

Right?

From a nice pdf on Agile / CMMI written about 5 months ago:

When viewed holistically, CMMI’s ultimate goal (i.e., continuous process improvement) is to
cause an organization to become less wasteful, leaner, and more in touch with actual development
progress. Ultimately, both Agile and CMMI, especially in high-trust environments, expect organizations
to see gains in productivity by eliminating unnecessary effort. It’s true that implementing
Agile methods will often eliminate many unproductive efforts and behaviors at the project level.
However, even with Agile retrospectives, what CMMI offers beyond Agile is an infrastructure of
organizational learning and improvement that benefits the projects even before they begin.

Depends on the size of your team. Depends on what your “lessons learned” look like. I am a bit biased in my interpretation of this stuff, since I am not a fan of huge teams but would rather split them into multiple, smaller teams. I suppose there is truth in the above, but to say that you need CMMI to ensure that your organization learns is pretty silly, IMO.

In any case, it appears that CMMI (moreover, SCAMPI) is best viewed as a supplement to agile practice, to help ensure that you juice your agile environment for all that it is worth.

Funny. Kinda.

Thanks,

Josh Milane