The difference between Agile methods and CMMI

One of the issues I am currently investigating is Agile vs CMMI. The context being that we run an XP team and management would like to be assessed at CMMI "Level 3". There is a thread currently running on the  extremeprogramming yahoo group around the integration of XP and CMMI. I have taken excerpts of the conversation and pasted them below.

I would highly recommend everyone who is involved in the development of software subscribes to this group - amongst the regular posters are the likes of Kent Beck, Sam Gentile, Ron Jeffries and many other brilliant people and it is that the knowledge that one can gain is absolutely invaluable.

NB: This is an edited version of the thread - I didn't include some posts that I thought were slightly off topic, and snipped or joined some of the ones I did include where necessary...

---

Q: I'm looking for input as to the main difference between Agile Methods and CMMI (or even any Software Process Improvement model). If I could get what the industry thinks the main difference between the two is, i'd appreciate it.
    - Ronsley S. Vaz

- - - - - - - - - - - - - - -

A: The main difference, as I see it, is that CMMI believes that a good process will constrain people to build good software. Agile methods
believe that only people can build good software, and that they'll do so by creating a process that helps them. The two are oil and water.
   
I believe that an XP team could assess at CMM L3, and probably some equivalent CMMI notion. But I suspect that the reasons behind asking
them to do so would be in conflict with the values of XP, as I understand them.
    - Ron Jeffries

- - - - - - - - - - - - - - -

A: CMMI is a certification mechanism for tasks that have to be done on a large scale, classically organized project. It comes from a lot of experiance about what's needed to take such a project to successful completion, and where lots of failures occur.

Agile is a completely different way of organizing a project. If you take the KPAs and the goals from CMMI, you'll find that most of them actually apply to agile projects, but most of them are automatically handled: they aren't an issue. And other things that are issues are completely invisible to the CMMI.

The notion that you need _lots_ of paperwork for the CMMI is, as far as I can tell, a myth. A very expensive myth. What you need is for each of the goals under each of the KPAs to be handled as a regular part of how you do your work, and in a way that can be audited.

Whether meeting those goals means you can repeatably deliver high quality software on time and within budget is doubtful. I suspect that CMMI ratings are more often gamed than actually met honestly.

In a sense, you're trying to compare apples and engine blocks. The comparison you need is between classical software engineering project management in the "single delivery at the end of the project" mode and Agile. In that mode, the final product doesn't begin to emerge until close to the end of the project, when the pieces are integrated.

In Agile, there is always a working product, which is incrementally improved in the direction of what the customer wants.

It's a completely different approach; trying to compare the parts isn't going to be enlightening.

"Process improvement" is a bit of a misnomer. You can improve a process a whole lot, and then someone with a completely different process is
going to come in and run you into the ground. It's a difference in kind, not a difference in degree.

Take manufacturing as an example. We've seen (at least) four different manufacturing paradigms in the last few hundred years, beginning with
individual craftsmen, the factories of the Industrial Revolution, the Henry Ford/Fredrick Taylor mass production assembly line and now Lean
Manufacturing/Toyota Production System.

You cannot get from one to the other by a process of "improvement." Each of them has fundamentally different assumptions and goals.

    - John Roth

- - - - - - - - - - - - - - -

Someone once said, CMM stands for Consultant Money Maker.

    - Sridhar Sherlock

- - - - - - - - - - - - - - -

IMHO it depends on the way the lead appraiser distinguishes the objectives of the CMMI processes and - on the other hand - the
recommended practices. XP may be compliant with the objectives, not with the full set of practices described in the CMMI.
    - Thierry Cros

- - - - - - - - - - - - - - -

There are many different reasons for asking for CMMI certification, just as there are many reasons people take up XP. I think that at a large scale CMMI asks development teams to provide transparency and accountability. I use XP to provide those same important features. I think that XP and CMMI can work together for companies that need that level of reassurance.

Businesses want transparency and accountability in software development. They will go get it however they can--CMMI, outsourcing, rigid processes. Emphasizing and demonstrating our ability to meet those needs using XP will ease acceptance of our way of working in large organizations.
- Kent Beck

- - - - - - - - - - - - - - -

 No process can guarantee the production of high quality software. CMMI certifies a process, not the results that the process produces, so it cannot
guarantee quality of the software either.

The presumption that following a process that complies with CMMI must produce high quality is incredibly naive. It is quite possible to pass a
CMMI certification and produce low quality software - it happens quite frequently.

I would say that CMMI certifies a process under the assumption that the process is prescriptive (i.e., repeatable). If you remove the
prescriptive/repeatable assumption, then you can only certify how a particular team is executing that process, since another team in the same
organization could be executing the same non-prescriptive process in a different manner.

XP is a non-prescriptive process. The conflicts between non-perscriptive, agile processes and CMMI can generally be worked around up to level 3. At higher levels, where process improvement is based on reducing the variation in key metrics, the reduction of variance is in direct conflict with the
concept of agility.

The feedback loops in XP, Scrum, and other agile software development processes provide a very effective way to reduce quality variation
appropriately for a given project in a particular context (team, domain, customer, management, etc.). This does not mean that what you did to improve quality on that project is what will work best for other projects you do in the future, or for other teams in the same organization. Each project has its own feedback loops for arriving at the best place for that team and project.

Under a non-prescriptive process, each instantiation of the process can (and should be) improved independently. While these improvement experiences should be shared to help practioners recognize useful patterns, the vast majority of these patterns should not be directly incorporated in the generic, non-prescriptive process. Changing a non-prescriptive process to include specific adaptations that worked in specific instances will tend to make the process more prescriptive and less adaptable.
    - Steven Gordon

-------------------------------------

That XP supports being self-aware and self-improving teams from the beginning is a message worth emphasizing. I emphasize this at every
opportunity. I am frequently surprised by people expressing a belief that if they could only follow "the instructions" with some "accuracy"
then they would not have to think.

This is really the same trap I've seen people fall into with CMMI as the way to get to "Level 3". Getting to "Level 5" typically is
conveyed as unachievable to most teams. No one knows anything about "Level 4". Many teams have reached "Level 3" and so this becomes the
default target. Again I have seen people (counter to the CMMI material itself) try to reach a level by skipping good advice defined at lower
levels, trying to do too much at once, and trying to defining everything so well that the instructions merely need to be followed
rather than practiced.

One thing I like about CMMI are the layers of definitions that Kent referred to several messages ago. Off the top of my head, there are
"process areas" then "goals" then "practices" then "subpractices" then "activities" and "work products". The goals are useful things to
consider. Those latter items are optional and are essentially suggestions for how to reach the goals. As Kent said, XP offers other
suggestions for meeting many of those goals. These suggestions in the CMMI are also useful things to consider.
    - Logan, Patrick D