agileproducts.com

I am currently working at a smallish company that is slowly and painfully trying to move on from doing things in a chaotic start-up fashion.  I am (of course) advocating the use of Agile, but the CTO has decided that he’d like to try using CMMI.  So,  What is CMMI, and how – if at all – does it fit in with Agile?

CMMI stands for Capability Maturity Model Integration. It is a management framework which helps a technology organisation to examine and improve their processes. It was developed by the Software Engineering Institute (SEI) at Carneige Mellon University in the US, an industry research body set up in the 1980s with federal government support. CMMI is not a process. It’s a way of measuring whether an organisation has an effective process.

It breaks IT development, acquistion or services down into a series of disciplines such as Requirements Management or Project Planning, and looks at to what extent you are successfully carrying out each one. An external assessor is brought in to carry out a SCAMPI, or Standard CMMI Appraisal Method for Process Improvement. Depending on the results the organisation is graded on a scale of one to five, a bit like a hotel. In this case the grades are called Maturity Levels – with one being your basic no-process garage setup, and five being an extremely well-managed organisation. The assessment identifies the areas where you are falling down, and the framework suggests things you need to be doing to improve.

That’s the theory. And first off, it’s quite difficult to find that out. The people at the SEI may be brilliant process engineers, but I doubt they shined in English classes. Everything about CMMI seems to be written in dense, obtuse language that defies a simple one-page explanation, you generally need a specialist trainer to demystify things. Perhaps this betrays the origins of the framework, which grew out of government, academia and large companies developing big-ticket items for the US Department of Defense.

For many agilstas that alone will be enough to set off alarm bells. As you  start reading the literature the bells probably sound even louder. The language problem continues, outlining scenarios and ‘typical work products’ which sound awfully like workflows and artifacts from a typical waterfall project. It seems the very antithesis of agile.

But wait. Remember that CMMI is not a process, it is about processes. It is explicitly designed to be method agnostic, and supposedly as friendly towards agile as to waterfall. After all, if you’re doing agile development properly you are using a highly-disciplined methodology which involves procedures for managing projects, writing requirements, developing and testing code. For example CMMI defines a ‘process area’ called Project Monitoring and Control, with a list of specific goals which an organisation must fulfil to be judged as being of maturity level 2. These include things like ‘Monitor Stakeholder Involvement’ and ‘Conduct Progress Reviews’ – balls which an agile process involving standups, planning meetings, showcases and soforth ought to knock out of the park. Agile and CMMI are not fundamenally incompatible.

Which isn’t to say they’re an obvious dream couple either. As the authors of this paper acknowledge, they are derived from opposite corners of the industry and the language gap in particular needs work to bridge. I’ll be honest, at this stage I’m still a bit skeptical, and CMMI probably isn’t a road I’d be venturing down if it were up to me. But it does have value – especially for large companies with a vast portfolio to manage, or outsourcers and government suppliers who need a CMMI rating to gain contracts – areas where agile methods can be at their most challenged. At the very least, it’s something that’s out there and which agile practioners are going to have to deal with, so we might as well try and make it work for us.