I am not an eager supporter of CMM/CMMI, since I believe that they were initially created for waterfall methods with big plans upfront and not being very lean. However CMMI Level 5 is somewhat interesting from an agile point of view: (Level 5 – Certaintity. Continuous process improvement via metrics feedback).

Jeff Sutherland and co-authors are writing a paper on the subject and find that Scrum could provide CMMI Level 5 with unique benefits as well as the cost of going to Level 5 is dramatically reduced if starting with Scrum. Some process experts even claim that a good implementation of Scrum throughout the organisation automatically gets you to CMMI level 3.

However the question still lingers “What benefits does CMMI provide?“. The cost of implementing CMMI Level 5 is still high and I doubt most companies will ever justify the return on investment for doing it.

Read Jeff’s interesting articles on the subject:
Scrum Supports CMMI Level 5 – Intro and abstract of the paper
Is CMMI worth doing - A following discussion on the subject by Jeff Sutherland
Agile CMMI Open Space – Another interesting discussion around CMMI and Agile.

One Response to “CMMI and Scrum”

Hi,

this is an interesting post. Another way to look at CMMI is as a set of related best practices or a checklist of development project risks.

So as you say just working for a level 5 label may be not worth the hassle. But using the knowledge to avoid problems seems a good idea to me.

Asa matter of fact CMMI offer lots of flexibility and the level 1,2,3,4,5 is only one of the ways to use CMMI and not always the best way to do so. It is more often the leadership of a company that dreams of the level 5 label, but as I said CMMI is meant to list the risks for those in the tranches and help them survive.

No how I see Scrum work with CMMI well when you run a company you Scrum will give you way to manage projects. CMMI will give you clues to identify the roots of your problems and perhaps some guidance how to work around the problems.

Now the bureaucratic part of CMMI building and sustaining tons of “process assets” – well once you uncover a good way to do things, why not document it and share it with the rest.

I hope this all does not sound too weird, but CMMI is what you make of it. It is neither agile nor waterfall, nor cyclic or anything like this. It is a tool, a checklist, a set of practices that one can use for his benefit or demise as one chooses.

To say it in another way CMMI does not limit you to doing things in particular way it only tells you when you miss critical activities. You are free to use this info to set up an improvement program to solve or your problems or to obstruct your work in needless paperwork – that is the choice of the organization.

As a matter of fact I believe some of the practices in the latest editions of CMMI were borrowed heavily from Agile, XP and so on. Like for example peer reviews – done for example by peer programming.

Bloggtoppen.se