Agile Zone is brought to you in partnership with:

Allan Kelly has held just about every job in the software world, from sys admin to development manager. Today he provides training and coaching to teams in the use of Agile and Lean techniques. He is the author of "Changing Software Development: Learning to become Agile" (2008) and "Business Patterns for Software Developers" (2012) and a frequent conference speaker. Allan is a DZone MVB and is not an employee of DZone and has posted 85 posts at DZone. You can read more from them at their website. View Full User Profile

How does Agile relate to CMM Level 5?

  • submit to reddit
A question in my mail box: “How does Agile relate to CMM Level 5?”

As I started to tap out the answer I thought: this might as well be a blog entry. So here it is.

Think of CMM, or rather CMMI which replaced CMM about 10 years ago, as a ruler. It is a way of measuring software development effectiveness. Is your development process 1cm good? 2cm good? or 5cm?

CMMI doesn't say how you should do development, only how you should judge effectiveness. Agile is a way of doing things - as opposed to "the state of Agile" which is a measure of effectiveness.

You can use Agile to be any CMMI level you like. CMMI doesn't care how you do it. Watts Humphrey (the father of CMM) used to say something along the lines of “Work on you quality and processes first, the levels will come by themselves.” That statement is very Agile. Unfortunately some organisations get it the wrong way around. I was at Reuters when they imposed CMM and destroyed a big chunk of their development capability.

The late Watts Humphrey did issue some process recommendations in the form of the Personal Software Process and Team Software Process.

That’s the easy bit.

"The state of being Agile" might, or might not, conflict with Level 5 CMMI simply because different things are considered important. You might be CMMI level 5 and decidedly unAgile.

Ironically CMMI level 5 might mean you have to investigate Agile. Because being level 5 means you are “self optimising”. If an organisation is level 5 and hasn’t looked at Agile it should because that may help them improve.

Paradoxically, being level 5 itself makes it becomes harder to improve. The risk of change is a lot greater because the organisation has more to loWaterfallse - and probably lots of procedures to update making any change expensive.

CMM(I) tends to be associated with a certain way of doing things. Partly this is historic: when CMM(I) appeared Waterfall was the dominant model, NASA was the first organization to reach level 5 and (at the time) it was very Waterfall based, and because CMM(I) tends to be more common in military work which are also big and paper work intensive.

So, some people believe that CMM(I) means following a very structured, heavy, WaterfallWaterfall process. It doesn’t have to mean this but historically the two do tend to coincide.

The Software Engineering Institute issued a report in 2008 which discussed how CMMI and Agile could work together: CMMI or Agile: Why not embrace both! I don’t agree with everything in the report but I do agree with the general tone. CMMI and Agile are not alternatives and can be complementary.
Published at DZone with permission of Allan Kelly, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jason Erickson replied on Thu, 2011/03/03 - 12:39pm

Are you trying some subliminal suggestion with the word "Waterfall" sprinkled through the post in odd places? :)

Petri Paajohtaja replied on Fri, 2011/03/04 - 8:15am

With all the respect, CMMI is obsolete. It is based on the assumption, that systems and software development can be assessed with a simple ascending number scale from 1 to 5. This just proves how unaware these people are of the complexity and nature of software development. I hope we all can focus our energy on solving real problems and inspecting and adapting around the evolutionary and empirical process of developing software. So, please, let's ignore these stupid models. They will go away sooner than later.

David Bland replied on Fri, 2011/03/04 - 11:57am

I heard Jeff Sutherland speak recently on CMMI & Scrum. I'm personally not a huge fan of CMMI, but he was very convincing speaking to his experiences melding the two. He even went as far as illustrating how you can revive a dead Scrum adoption with CMMI.

You can go back to 2007 (maybe even earlier) and find him writing about it:



Petri Paajohtaja replied on Sat, 2011/03/05 - 9:21am in response to: David Bland

No, it was vice versa: with the help of Scrum, a CMMI Level 5 shop was revived by doing Scrum:

  • Productivity doubled in less than six months reducing total project costs by 50%
  • Defects were reduced by 40% in all Scrum projects
  • Planning costs were reduced by about 80%
  • User satisfaction and developer satifaction were much higher than comparable waterfall implementations.
Anyways, please take Jeff's, or anyone else's productivity studies in software domain with a grain of salt, because the productivity cannot be measured.

Stephane Vaucher replied on Sat, 2011/03/05 - 5:22pm

@Petri - why do you state that CMMI is obselete? It checks the presence of certain practices. That's not intrinsically bad. Producing the information required for certification can be done intelligently (e.g., using highly automated reporting) or not. Unlike what most believe, it encourages the empowerment of teams to improve a development process which is in line with agile values. The problem that I've heard about is that adopting the CMMI is an organisation/division decision (e.g., for bidding on contracts). When practices for the CMMI are imposed on teams, it can turn ugly and inefficient, but that's an issue with the adoption of CMMI, not the CMMI itself.

David Bland replied on Sat, 2011/03/05 - 11:17pm in response to: Petri Paajohtaja

• Used CMMI principles to focus on the Common
Failures with Scrum.

See slide 18:

Petri Paajohtaja replied on Mon, 2011/03/07 - 3:07am


First, some facts about CMMI:

  • CMM was created for the DoD procurement and sourcing needs. And it doesn't work even there (check crosstalk article related to this, and the study by Prof. Abrahamsson where the finding was that only 0.2% of CMM Iprograms has succeeded)
  • CMMI measures only processes in place, not the results. I've seen CMMI Level 5 companies doing really bad, producing crappy products.
  • CMMI contains pre-defined solutions for only known problems.
  • CMMI is based on the theory of Scientific Management - Taylorism as it is also called.
  • None of the really successful companies never used CMMI, e.g. Google, Apple, Microsoft, Semco, Gore, Nucor, Svenska Handelsbanken, Spotify, Twitter, etc.

Some questions you might want to ask yourself (or the people in charge of CMMI program):

  • What are the values and principles in CMMI?
  • What is the underlying industrial paradigm in CMMI?
  • Who owns the process and the process improvement in CMMI?
  • What is the definition of a process in CMMI?
  • In which situations level 5 is better than level 4?

There are many books from e.g. Poppendieck, Larman & Vodde, Highsmith, Stacey, etc that you should read. Here are some of the quotes from these people:

  • "Adaptation is significantly more important than optimization"
  • "Emergence, characterized as /arrival/ of the fittest, is significantly more important than /survival/ of the fittest"
  • "Silver bullets are new mental models for which the exception conditions are not yet understood"
  • "Silver bullets, such as TQM, BPR, PMBOK or CMMI, create a vicious circle of problem definition and solution, also called the "optimization paradox".
  • "Most managers use silver bullets in the hope that they will provide prescriptive answers to complex situations. Most soon discover, however, that these prescriptive, optimizing answers get bogged down in metrics, procedures, forms, and slogans - and use of the chosen solution often lasts only until the next fad comes along. Silver bullets can be useful, but they're insufficient. They deal best with the stable parts of the environment, not the rapidly growing complex portion."
  • "To me there are two kinds of process - good process and bad process. Good process trains people in building-block disciplines so that when they get hit with the unexpected, they already have the training and discipline to make the right spontaneous response. Emergency response and military training usually fall into this category. Bad process is a process that attempts to replace the knowledge of workers with canned procedures. Workers are not trained to think, they are trained how to follow a script. You frequently find this in customer service call centers, for example. Bad process and Taylorism are the same thing; both start with the assumption that front line workers are not capable of thinking for themselves. CMMI tends to evoke bad process, despite the best efforts of people like Mark Paulk. I think this is because CMMI's underlying theory is Taylorist - as Watts Humphrey has proudly admitted. Thus it is very difficult to turn CMMI thinking into good process."

Some articles you should also read:

Hope this helps!

Shumona Kapil replied on Sun, 2012/02/19 - 9:54am

Sadly, CMMI does NOT tell folks how to judge effectiveness. It simply(?) offers a model comprising all those "good practices" that the worthy SEI folks believe are important in running a "mature" or "well-performing" (whatever those terms mean) software development organisation. CMMI level 5 organisations are, by-and-large, NOT exemplars of *effective* development organisations. Far from it. See e.g. the story of SSE (Denmark) for some insights into this.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.