Monday, January 23, 2012

Is CMMI+Scrum for Agile Puritans?

I work with Leslie (from the last post) and, come on, where do you get off telling us to “be real”?  Our Scrum team is made up of true agile evangelists.  We have no use for process models or BPUF or any of that old school garbage from stuffed suits like you.  The CMMI certification is a necessary evil in our company, so we put up with it.  Now it looks like we’ll have to put up with you at SEPG NA.  ~ Arthur X.

Hey, Arthur,

Thanks for your sweet message!  It’s not often the CMMI Appraiser gets a love letter.  With Valentine’s Day coming up next month, I guess you were overcome with the urge to whisper sweet nothings in my ear.  I love it!

But seriously, Arthur, what I would really love is for us to get on the same page about CMMI+Scrum.  Yes, they really can and do coexist.  When you get to my class at the conference, you’ll see exactly how.  In the meantime, if you are willing to suspend your disbelief in my sincerity, I’d like to point out a few things about CMMI and Scrum that you may not be aware of:

  1. This CMMI Appraiser doesn’t wear suits.  The closest thing I came to wearing a suit was last month, when I put on a red Santa suit, and sang the "Twelve Days of CMMI."  The neighbors are still recovering from THAT adventure.

  1. You say, “We have no use for process models,” but did you realize that Scrum is a process model also?  When you look at all of the different techniques of a Scrum team, all the "Scrum Elements," every one of them is a process.  They are not the same processes that maybe you think people want to make you use, but they are still a process.  And they're pretty darn good ones too!  And every one of them is in the CMMI! For example, Planning Poker is represented in the CMMI's Project Planning Specific Goal One.  Refactoring is in Requirement Management,  Pair Programming is part of Verification, Velocity is part of Measurement and Analysis, and Test-Driven Development is part of Requirements Development.  And so on.
  1. “We have no use for BPUF (Big Plan Up Front).”  That’s OK!  I don’t either. To be clear, the CMMI is not a methodology.  It does not have to be BPUF. That’s a perception based on implementation, not a perception based on fact.  Are you saying that because the CMMI is most often used in BPUF types of organizations, therefore the CMMI is a BPUF process model?  Correlation is not causation Arty.  The real meaning behind CMMI is that it looks to make anything that you are doing better.  So why not use CMMI to make a Scrum better?
  1. You’re too cool for “old school”?  Guess what - me too (and it kind of creeps my kid's friends out)!  The beauty of Scrum teams is that they tend to be fiercely independent.  Unfortunately, that perception is one reason why most companies are using Scrum for only a small subset of their projects.  As I was explaining to your teammate, Leslie, part of the challenge with using Scrum is sometimes upper management doesn’t understand it.  It’s well suited for bottom-up implementation, but not so much for "top-down."  But because everything in Scrum is on-time and on-budget by definition, Scrum teams can boast to their management, “things worked really well.  We are on time and on budget with every release.”  But you don't hear so much is whether they met the full number of features they committed to delivering.  Their velocity may be lower than they expected.  If that happens to you, CMMI can help.
  1. The CMMI is a “necessary evil”?  Does that mean agile project are full of rainbows, unicorns, goodness and light?  Well, I don’t dispute that the agile community has got great ideas, but Purism is dangerous and damaging in any form.  Whether you are a Tea Partier or an anarchist, Puritanism is dangerous because it chokes off the flowering of new thought. It eliminates the possibility that new, better ideas are out there.  Isn't that kind of an agile "anti-pattern" in itself?
There has always been this sort of antagonistic relationship between the Agile and CMMI communities.  So much so that that I co-wrote a white paper called "CMMI or Agile? Why Not Embrace Both?" for the SEI along with several of my peers on why that perception is hurting the software community, and why the CMMI is an excellent fit for agile environments.  And no, they don’t wear suits either.  

Although whether or not they wear Santa suits, I can’t venture to say.

That’s the history and philosophy, Arthur.  Embrace CMMI+Scrum as a tool to make your organization a great company.  Every framework, including Scrum, has weaknesses, and you can use CMMI to make it even stronger.

Like this blog?  Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit for more information about running a successful CMMI program.


Shawn Rapjack said...

Hi Arthur – it sounds like you just really got off on the wrong foot with CMMI! There is nothing worse than a bad CMMI experience to color your future reactions to it. My training in CMMI was horrible – and made me skeptical of it, for example. Please don’t let your prior experiences and misconceptions about CMMI direct your process improvement journey – um, or your mood.

Let’s look at the (very hypothetical) bad experience you had with CMMI. Many things could have made your interactions with CMMI misleading and unfortunate!

Were you properly trained in CMMI? (… Because, to know CMMI is to love CMMI). But, no, really – understanding the model is the first step to appreciating how CMMI can help an organization.

This brings me to the next point – was CMMI used correctly? Perhaps your (very hypothetical) organization misapplied CMMI. CMMI should be used to help an organization become better. Period. Was your organization just ‘level-seeking’? Using CMMI to just get a Maturity Level is a grave misuse of the model. CMMI is a journey of project self discovery and improvement – if you are doing everything right, Maturity Levels and other accolades come naturally.

Was CMMI shoved down your throats? The tenets of proper organizational change management should have been used for your organization when adopting CMMI. If this is done too fast, process practitioners will be overwhelmed and (rightly) confused.

Yikes – it sounds like you might have been exposed to – gulp!— Inept Consultants at some point in your career! (They actually live in a tiny village surrounded by the severed heads of people they’ve bilked money from. Dire wolves stalk the village… never mind). These charlatans confuse countless honest folk about the CMMI model. Holy Cow – he probably sold you a ‘tool’, didn’t he? Your Inept Consultant should have mentored and guided your organization through their improvement journey. He should have adapted to your company’s unique business environment, tailoring engineering solutions as he went along.

Your hypothetical company might not have realized that CMMI and Agile work quite nicely together. They're friends, actually. Your company might have tried to separate the two. I work in a very small team – we are required to have quick turnarounds to our website implementations (within a matter of hours). Our CMMI processes were highly (outrageously!) tailored to incorporate our (agile) rapid application development environment. CMMI is a tool – and, with mentoring and guidance, we tailored it to improve our business environment.

Shawn Rapjack
Process Improvement Advocate

Anonymous said...

Couldn't have said it better myself Shawn! So I want even try!