OK, there is a sense in which CMMI is compatible with Agile. It just doesn’t work as a model for maturing an Agile organisation.
CMMI is a really interesting and, in principle, powerful idea. In particular, its maturity levels present a sequence of increasingly sophisticated models of management and performance, and in that respect it’s good. I have myself developed maturity models that differed markedly from CMMI (including what each maturity level meant), but they all shared the idea of maturity levels. And there is certainly a sense in which such an approach is valid and can even claim a certain amount of both scientific and historical support (e.g., for child development, historical phasing of major social systems, economic development, and so on).
But that was some time back. A couple of decades in fact. Since then Agile has emerged, and quite a lot of effort around CMMI has been devoted to matching CMMI to Agile. Unfortunately at its most fundamental level – its maturity levels – CMMI continues to fail. Why?
What’s wrong with CMMI?
Well, the key difference is that Agile is always mature, right from the start. Assuming that you have implemented a basic model of Agile (e.g., Scrum, Al Shalloway’s Scrum/APM, etc.), you have all the elements in place right from the start. Not instantly, of course- all change takes time – but all the necessary ingredients are present in the most basic models.
On of the odd effects of this difference is that, perhaps paradoxically, the goal of Agile is to arrive at the state described by CMMI as the most primitive level of maturity – Level 0:
It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events.
CMMI interprets this as follows: ‘This provides a chaotic or unstable environment for the processes’. Agile, however, would say that this represents a state of maximum adaptability, flexibility and dynamism, in which the team is not constrained by formal processes and other controls, but rather, because of the nature of the individuals who make up an Agile team, creates the ideal conditions for high-performance delivery. That processes are ‘driven in an ad hoc, uncontrolled and reactive manner by users or events’ is not only not a problem for Agile, it’s its ideal end-state.
Yes, what CMMI means by Level 1 is plainly a mess – not at all the kind of situation Agile describes. But that’s exactly the point. Because of how Agile works and the assumptions it makes (see below), that ‘mess’ is simply the field of maximum opportunity. Indeed, from the start Agile is designed to operate at all levels of CMMI, all at once. So when CMMI distinguished its five stages –
- Level 1 – Initial
- Level 2 – Repeatable
- Level 3 – Defined
- Level 4 – Managed
- Level 5 – Optimizing
– this pretty much describes a basic Agile team and its delivery cycle! Its ‘processes’ are already repeatable (to the extent that the team wants to repeat them, that is), and also defined (to the extent that – as in cases such as the Definition of Done – the team believes that they need to be). Likewise, through retrospectives, they are self-improving.
It’s tempting to argue that this difference – and CMMI’s fundamental inability to address Agile – follows from CMMI’s commitment to processes, and to interpret that term as meaning a documented prescription for development and delivery to which the team must adhere. And I think that this is at least one legitimate interpretation, not least because Level 3 goes out of its way to describe itself thus:
It is characteristic of processes at this level that there are sets of defined and documented standard processes established …
Defined and documented? Sounds pretty prescriptive to me. And if this interpretation is correct (though I have no evidence of how CMMI assessors actually interpret these words these days), then plainly the documented processes take precedence over and drive the team in its development efforts. The antithesis of Agile, in fact.
But even if this reference to ‘defined and documented’ processes is actually only incidental, and that the ‘processes’ CMMI is talking about can be defined by and reside solely in the heads of the development team, it’s still difficult to square CMMI’s maturity levels with Agile.
This is because, again, the Agile team is mature from Day 1. The problems it has with delivery – which still amount to a problem of maturity – are really quite different from the ones CMMI levels describe. Here are a few of the problems Agilists worry about (usually under the rubric of ‘scaling Agile’):
- The initial creation of individual Agile teams.
- Creating multiple Agile teams across a single organise – as Al Shalloway has observed, not simply a matter of adding new teams.
- Re-engineering other parts of the organisation – HR, finance, the delivery pipeline, operations, and so on – first to align and integrate with Agile development teams, and then to ‘Agilise’ their internal workings too.
- Creating large-scale Agile programmes involving far more individuals, stakeholders and corporate functions than a basic Agile team normally confronts.
And so on. Plainly, although also an issue of maturity, this is a completely different trajectory from that described in CMMI. In fact, Agile and CMMI’s overall maturity strategies and trajectories are fundamentally different, if not opposed.
- The CMMI model is rather like the way an infant develops into an adult: in the earliest stage, the organisation is barely capable of coherent action.
- Without caretakers who are hugely tolerant of its manifest limitations (typically senior executives who can think of no better solution to the problem of IT delivery), it would be abandoned shortly after birth.
- The Agile version of maturity, by contrast, is more like evolution from a single-celled organism to a fully rational intelligence: always fully mature at its current level.
- In fact Agile goes beyond any Darwinian model, as it does not rely on random variation and natural selection to get to the next level; rather, through mechanisms such as retrospectives, it can raise itself by its bootstraps.
So, perhaps one day there will be a model of Agile that describes such a sequence of maturity levels. But if there is, it won’t look anything like CMMI. And anyway, I think the scaling guys have started to crack this one already!
What does this tell us about Agile?
This situation also reflects one of the most important but seldom-recognised limitations on Agile. Agile only really works with a team (or teams) of expert, self-disciplined professionals. If, by default, Agile prefers – as the Agile Manifesto rightly insists –
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
– this is only attainable if the team is made up of individuals who do not need the support of formal practices and standards by which CMMI defines maturity, and on which every one of the items on the right-hand side of the Agile Manifesto’s list rely.
If, on the other hand, the team is not made up of such ‘mature’ individuals, it is unlikely to be able to operate in a truly Agile manner. Maybe such a team needs CMMI or bureaucratic controls or even a waterfall methodology, but it really won’t be able to ‘do Agile’.
That’s not to say that a mixed strategy could not be effective. Embedding individuals with no experience of Agile in an existing team of experienced Agilists would certainly bring them up to speed quickly. Such an ‘incubator’ approach could even be a systematic method of moving individuals from non-Agile to Agile teams. But it would be slow, it should probably never be more than one or two inexperienced individuals per team, and it might well hamper the Agile team’s basic performance. So the decision to work this way is a serious one. And in any case, it does not undermine the present argument in any material way.
In conclusion, Agile and CMMI really aren’t compatible. CMMI made a lot of sense in a waterfall-based world and it suits organisations that really can’t let go of command-and-control, but it would kill Agile stone dead.
Footnote: Come into the age of the web, CMMI!
A last thought. I just logged into the CMMI website, specifically to look at the new CMMI Model Viewer – the tool that replaces the old CMMI Blue Book, which was the assessors’ Bible. It’s supposed to let you see the new CMMI model from different perspectives – Development, Services, People etc. A good idea, although I doubt that throwing out the old Blue Book will be very popular, as you now have to be online to the CMMI Institute to be able to look up anything about CMMI. This could be tricky in mid-assessment.
But the real problem I have with the Viewer is that, whereas the old Blue Book was only expensive, the Viewer is truly exorbitant. $400 for the annual license? $150 for a week’s access?
That really isn’t how access works in the days of web products. You give stuff away – often quite fundamental stuff. In the CMMI Institute’s case, the core model of CMMI plus access to the Viewer would have been the obvious starting place. Then I would have had something to work with, and they could have enticed me with (paid-for) ‘Pro’ products like training and coaching, access to the assessment models, consultancy, and so on. But now I just think, no, I really can’t be bothered. And so what might have been a fruitful and mutually profitable relationship – because I really am very interested in the concept of maturity as a consulting tool – has been nipped in the bud.
Like everything else about CMMI, it’s like the Eighties never went away. Now if you’re going to live in the past, at least make it the Sixties.
Bye bye, CMMI.