Mapping Agile practices to CMMI

I was in London today doing some CMMI mapping with a chap who is familiar with the model, as well as our implementation of Atern. It was a pretty productive day, I think. I find it so much easier to think when I have someone to bounce thoughts and ideas off of.

I am trying not to take the model too literally, focussing on the objectives. What we are doing, therefore, is looking at the CMMI-DEV v1.3 goals and practices at Maturity Level 2 and trying to work out what practices we already have in place that would meet them. For example, when it comes to Project Planning (PP), standard practice 1.1 says:

“Establish a top-level work breakdown structure (WBS) to estimate the scope of the project.”

So do I need to define a WBS for all the activities I plan for my Agile project? No! What I am suggesting is that a set of user stories (at varying levels of granularity) that covers the breadth of the project scope along with something that defines the architecture and hardware needs will cover it. And we already do that.

Another example – standard practice 2.4 states :

“Plan for resources to perform the project.”

Well, Atern has a number of standard roles and specific responsibilities. So I have created a simple Excel template that lists the Atern roles (allowing for multiple people to fill applicable roles) and provides a column for the name of the person fulfilling each role and a note on whether they are suitably skilled or need any training. Each project is then required to demonstrate by the end of the Foundations stage that they have all required roles filled with suitably skilled people. Simple.

These ones are easy. But some are proving a little more difficult to interpret, or find suitable equivalents. Take Configuration Management (CM) for example. As applied to software, CM is probably more important on an agile project that a waterfall one because of the numerous, frequent integrations of code. But as applied to other ‘artefacts’, it is less so. We have fewer documents to start with, and we are not so obsessed with “change avoidance.” So what do we do to satisfy practice 2.4 : “Track change requests for configuration items.”?

The entire concept of change requests is born from a waterfall mindset – that we plan and specify in detail and then carry out the plan. Agile doesn’t do that. Agile embraces change. Change requesting, impact analysis and approval can all happen in a few minutes in a workshop environment. So we are still working on that one. What we absolutely do not want to do is create a change request and approval mechanism that adds no value to the way we work – that would be counter-productive.

As I have stated before, we are looking at CMMI only because it seems to hold some value as a model for improving the quality of what we deliver and the control and predictability with which we deliver it. The objective is not a rubber stamp. We are getting there.

Advertisements

About aterny

Agile enthusiast and evangelist, DSDM practitioner, trainer and coach. Specialist in Agile project and programme management, governance and organisational transformation
This entry was posted in Agile and tagged . Bookmark the permalink.

One Response to Mapping Agile practices to CMMI

  1. ken says:

    Chris, I really look forward to having the chance to assess agile practices against other models and frameworks… not to put either down or build either up, but just to look for the ways they compare and contrast philosophically and in practice.

    I have thought about the “top-level WBS” several times as well, and come to similar conclusions… what we had should suffice. It is the thinking about why such a requirement would exist in the first place that is valuable… why would CMMI care about having a top-level WBS in place? What would it do for me to have one?

    If I can write out my interpretation of the purposes for requirements such as those, then I can make assessments of whether my practices are weak, missing, flawed or incomplete. Using that kind of an approach, what would be the purposes (fundamental, specific, strategy, tactical and ultimate) for tracking change requests? How do we also satisfy those same purposes in agile, your way or mine?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s