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.