Saturday, July 9, 2011

Is CMMI compatible with Scrum? I don't see anything in Scrum about it.

Dear Appraiser,

I know CMMI can help us, but we're a Scrum shop. We need to know if CMMI is compatible with Scrum.  Specifically, what about CM (Configuration Management) and CM SP3.2 (perform configuration audits).  

We've written a lot about the subject of CMMI and Scrum (and other agile methods such as XP and Spiral) and the answer is "YES!"  Scrum is a methodology, and the CMMI is a model of a great company.  It is methodology agnostic, so can be used with any agile or other methodology.

Read the detail in "CMMI or Agile: Why not Embrace Both!" that was co-written by Glazer, Dalton (me!), Anderson, Konrad (SEI), and Shrum (SEI).  You can find it at in our free "Premium Resources" section.

The biggest problem is one of imagination.  For instance the CMMI guides you to have regular status and milestone meetings.  "MEETINGS?!!!!  We're agile, we don't do MEETINGS!" say many of my agile purista friends. don't do meetings?  How about the daily standup?  How about the Scrum demo?  How about almost EVERYTHING you do?  Scrum is about collaboration if it's about nothing else, and collaboration happens mostly in meetings.

So keep an open mind and think outside the box.

The CMMI talks a lot about estimating.  Planning poker, fibonacci cards, story points?  All good.
The CMMI talks a lot about configuration management.  What?  You don't manage your code with CVS, SourceSafe, Collabnet, or something else?  That's not Scrum.  That's just dumb.

All CM SP3.2 is about is making sure the code and important artifacts are in fact being managed properly.  It means someone is checking to make sure dumb stuff isn't happening.  But it's not in Scrum.

Sometimes Scrum (or anything else) has gaps.  This is where the CMMI can really help you.

Round out what you really like (Scrum, XP, etc) with the CMMI.  It will transform you from good to great!


GZ said...

Good post.

Sadly it seems the ones that are least interested in what CMMI can do for them are the so-called "agilistas." They see CMMI as prescriptive to a particular lifecycle.

Related tangent ... Recently worked with an organization that was actually using Kanban, they initially found some of the level 3 practices to be ... umm, challenging. In fact, they stated they saw little value in them (namely the "O" process areas).

Perhaps the greatest testament I heard in working with this organization regarding CMMI value for a Lean-Agile-Kanban practicing team was when they said, "the practices that had seemed to have the least amount of value, ended up having the most value for us down the line." (this says a lot about the learning nature of that group).

Jeff Dalton said...


Thanks, and great comment. I'm a fan of Kanban myself - but it's typical of any purist, and someone embracing "the latest," to miss the forest for the trees. The ironic part about the whole thing is that by choosing to adopt Kanban (or any other process model or method for that matter), and training people on it, and improving it over time, setting up boards..... they are performing most of the practices in the "O's!" Yet they too often continue to say they (and others) have "no value." What they are missing is imagination! It's sad in a way - but all too often our agile purist friends have just not learned enough yet to see that ALL of these models can compliment each other.

I had another question from a scrum team questioning the value of Configuration Management. Seriously? Managing code has no value?

I feel a whole post coming on!

GZ said...

Yeah ... CM is usually one of the areas that goes as a no brainer for most teams ... when talking code. And the tools take care of so much of that for them. I have been lucky in that regard - I have never met a team that does not have their source code in such a tool (although I have seen issues where change management is an issue, particularly when code is shared and impact to the dependent binaries is not well considered ... different story)

A bit more challenging when discussing work products that are not code ... landing on which are necessary to mange that way and then with a level of rigor that makes business sense.

Anyway, been lurking on the blog for a bit and I enjoy it. Thanks.