A conversation I’ve now had a number of times, including on the Agile v. CMMI panel at SEPG deserves special mention.

The appraisal process for CMMI which looks to see that an organization has a process improvement program in place (called “SCAMPI“) doesn’t explicitly require “documents” as artifacts. Neither does CMMI itself.

What is required is “evidence”.

Evidence is not always documentation.

One enabler of CMMI in Agile/agile environments is this distinction. I expect to write more about the SCAMPI process soon enough.

NOTE: The following message was graciously sent to me yesterday. I’ve received permission to post it to the blog and I’ll also post my reply.

Dear Mr. Glazer,

I’m an Agile supporter since before the word Agile had been chosen to identify this group of approaches. I served the Agile Alliance board of directors for two year and was previously (heavily)involved with the Rational Unifed Process and CMM. This is just to say that I’m supposed to have some real world, day to day experience, not to impress you in any way

I believe, like you, that at some level Agile and CMMI can cooperate
without problems but I think tradeoffs are needed mainly in principles and perspectives.

What I can see working is, as you write, wrapping agile practices with CMMI:

- agile practices for software development
- CMMI for software management

As you can see I’m using ‘agile practices’ instead of ‘Agile’ because I think this is the biggest tradeoff you need to do in order to integrate both. Otherwise I think they should really be kept separated.

I’ll try to explain myself: every organisation can improve its process adopting one or more agile practices without becoming Agile and I think this is fine as far as it serves its purpose and I see it fitting lots of realities. You know, at the end an approach needs to fit the organisation culture otherwise it will have hard times.

That is because I don’t agree in saying that Agile is just a bunch of (engineering) practices. As I’m sure you already know an Agile approach *requires* a mentality shift for the organisation as a whole.

XP is Agile but Agile is not XP and, for example, Scrum is 90% about
management, and it’s fully compatible with XP while in its fundamental principles it is not with CMMI.

I’m interested to know more about your phrase: “where XP ventures into management methods, they are not incompatible with CMMI” for two reasons:

1) because while I have practical experience with waterfall, RUP, CMM and Agile (above all) I’ve just read about CMMI and I don’t like to speak with theoretical knowledge only

2) because I like to know more

Even if I tried to keep this email short I failed even if I feel I would need pages and pages just to put some order into my thougths.

Thanks in advance for your time, regards

Marco Abis
http://www.agilemovement.it :: Italian Agile Movement
http://www.agilityspi.com – Agility Software Process Improvement
http://www.thoughtworks.com – The Art of heavy lifting

My Reply:

Marco,

Thank you so much for writing!

I agree that we should be careful about how we use “Agile” and “agile”.
I will try to be more careful and consistent in the terminology.

I also agree that agile is more than engineering, especially when we want to look at agile as a change in development practices at a very fundamental level, beginning with addressing the very paradigms of engineering practices.

On the matter of Scrum, however, I would have to disagree with your assertion that the approach is incompatible with CMMI. In fact, I love the impact Scrum has on an organization’s CMMI practices. Perhaps (you tell me) your position comes from experience with the strong implication in the SW-CMM (not CMMI) and in the assessment / evaluation method for SW-CMM on documentation which would be hard to satisfy w/Scrum. In that regard, CMMI is a marked improvement over SW-CMM.

The reason I see “management” aspects of XP to be compatible with those of CMMI is because the two “bodies” are actually addressing different (non-overlapping) aspects of management. More importantly, both have, at their core, strong influences of what “good management” is.

At today’s SEI SEPG Conference, David Anderson nicely presented a view of Agile’s Principles as they reflect Deming’s TQM principles. The coverage was complete. Neither set exluded the other.

Now, a question for you before we continue this thread: until I integrate a bulletin board onto the blog page, would you mind if I blogged your email & my reply and we continued our discussion there?

Cheers!!
–>> Hillel

All-in-all the event was a success for me and Entinex. Today’s panel discussion on Agile & CMMI went well, I thought… If a measure of success can be the fact that most of the audience stuck it out for the entire double-session w/out taking even a bio-break and then stayed on after the allotted time and into the afternoon refreshments break… I guess you could say it was pretty high-value.

The panel was excellent. Each person had a different perspective on the matter which did add depth — even though we all pretty much agreed that CMMI and agile methods are not incompatible. I’m sure a more lively panel would have been one that also included an agilist and a “big” process person who didn’t believe the two can play nicely, but I think it was important that a group of people with different perspectives came together to make an essentially unified front in moving this topic off the “no way” list and into the “let’s make it happen” list.

From the panel I shamelessly plugged this blog (with the moderator’s consent) as a place where those who agree (or are at least at a point where they can carry on a serious, productive discussion and investigation) can collaborate and discuss the topic. I’ve created a discussion group for it and will see about making a companion bulletin board or RSS/Atom feed to it here. (In my copious spare bandwidth.)

David Anderson’s impressive presentation near the very end of the day had some really killer information. What he’s working on over there in Redmond should take this business by storm. I’m looking forward to heading out there this summer to get an up-close and personal tour of their work.

I’m really quite feeling accomplished at all the great people I met there and anyone reading this whose name doesn’t explicitly appear in these posts, please don’t be offended. The discussions and serious issue-hashing were informative and productive. There are many of you with whom I hope to be in regular contact to move this matter forward and ultimately make it a non-issue. Technical Reports are already in the making, but they will need people to carry the message and this space is what I hope we can use to make that happen.