Kevin Trethewey

Software Developer, Technologist, Connoisseur of things that go 'bing'.

The difference between Agile methods and CMMI

Published Monday, November 21, 2005 9:26 AM

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

by Kevin Trethewey

Comments

# Nuz said on Monday, November 21, 2005 12:22 PM

FYI

CMMI is a process improvement for the whole organization and not just for a development team.

# Jeff Dalton said on Friday, November 25, 2005 1:06 AM

Boy, I don't know where to start .... but I do have my own version of the CMM joke from one of the other posts. I'll share it at the end.

There has been much discussion about this topic - mostly people pointing out the incompatability of these two things but offering no real solutions or hard advice on how to solve the issue. I believe that the opposite is true - they are VERY compatible. As someone who has delved deeply into "agile" methods, and now also neck-deep in the CMMI, I am convinced that the original intent of the CMMI is indeed "agile", and that it is the perceived result of many huge government contractors in the Defense sector adopting the CMMI.

Indeed, the CMMI is based on Deming's Theory of Profound Knowledge, which if held next to the "Agile Manifesto" is almost a direct copy (in content anyway). Trust People, Iterative, Incremental, Customer Involvement - it's all there in Demmings work from the 50s. The impression of CMMI being "waterfall" is fed, in part, by the fact that the SEI used the Crosby model (Manufacturing Maturity Model) as a framework for NAMING their levels - and Crosby's model is indeed "waterfall" and not empirical like software.

It's true that some Lead Appraisers do not understand some of the basics of Agile - and that this is a problem that the SEI is trying to solve. As a Lead Appraiser, I specialize in appraising Agile organizations and can tell you that there is definitely a movement towards Agile by the SEI community.

I am speaking at the annual SEI conference this year (SEPG 2006) on this subject. The title is "AgileCMMI - Process Innovation at the Speed of Life."

Part of the problem is the ambiguous description of what "agile" is. Many of those fuzzy descriptions are in previous posts here on this board. "Trusting People," focusing on delivering software, not process ... ". All of these are true of all "well-run" projects are they not? What's so "Agile" about these things?

Agile is a shift in the way we think about development - especially in the way requirements and workplans are managed. In "traditional" development, scope is set (read "huge requirements spec") up front and the budget and dates change to meet the spec (hence "death marches" to try to meet unreasonable targets because managers don't want to ask for more money). In an Agile world, the model is flipped - date and buget for a Release or "iteration" are fixed, but scope is more negotiable. This is a negotiated agreement with your business customer based on the value of the features being implemented (Value Velocity).

In the end I am convinced that this results in better software - but there are many, many valid arguments on either side and, like software development, there is no "right way." (evangelists please refrain from sending hatemail - it's Thanksgiving).

Does the CMMI "require" that all the Requirements be defined up front? No. It is implied by the many appraisals conducted at many companies that DO require that - but I challenge anyone to show me, in any one of the 771 pages of the CMMI spec, where it says this - or any other reqirements that are in direct conflict with Agile. It does require you to "manage requirements." Companies that don't do this in anyway are not Agile - they're Lazy.

So, I don't think CMMI means "consultants make money" (although that is clever). It may mean "Companies Measure Malleable Innovation" and for Agile companies that do this - and there are some - the result is spectacular.

jeff@broadswordsoutions.com

# links for 2008-03-31 » SDLC Blog said on Monday, March 31, 2008 3:33 AM

Pingback from links for 2008-03-31 » SDLC Blog

Kevin Trethewey

The difference between Agile methods and CMMI

Comments

Tags

Navigation

Archives

Syndication