I just finished reading a report by the Software Engineering Institute that accomplishes something that earlier literature, including “SCRUM Meets CMMi - Agility and discipline combined” didn’t accomplish: it takes a rational step back from both methods, shows where they’re from and why they’re different, how much of that difference is real and where the perceived differences come from, and how the two can come together. So, the short answer to my title is “yes”.

One thing I have often said about, and to, self-proclaimed agilists, is that diving into code head-first isn’t agile - it’s just plain stupid. It gives agile a bad name and it is bad for both the software and the clients that pay for the software. That doesn’t mean that everything should be documented and specified before you start coding: I agree with the Manifesto for Agile Software Development, and I’ll even quote it completely here:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

There is an importance to the contents of the last line: while there is value in the items on the right. I.e., processes and tools are still needed - just look at all the scrum tools that are cropping up everywhere to visualize burndown charts and if a daily stand-up meeting and a weekly sprint isn’t a process, I don’t know what it is.

Documentation is still needed, though some documentation is more needed than other documentation, and some can be generated straight from the source code rather than trying to document first and code afterwards. Requirements, however, need to be written down somewhere, as do user stories and other such documentation tools. Sometimes, you need to establish a clear standard because you need to communicate with sometimes yet-to-be-written third-party software, so you need to document your protocols first. Bref, there is value to documentation.

Contracts still need to be negotiated as well: no-one likes to work for free and many clients need non-disclosure agreements and other legalities in order to be able to do business. Perhaps the emphasis should no longer be on “what is the application going to do, exactly?” and should rather be on “under what conditions will the application be made?” but there is still a contract that needs to be negotiated, or there will simply not be a customer to collaborate with.

Plans should not be underestimated as assets either: a well thought-out plan will take care of the big picture while allowing many, many details to go less planned. For large projects, plans should be less detailed, not more, than for small projects. If both a small and a large project can be planned in five steps, the steps for the small project will be smaller, and therefore more detailed. The whole question is how to find a balance.

And that’s where CMMI comes in: while iterative and incremental design and development is a cornerstone for all agile methodologies I know of, it pre-dates all of them by decades. CMMI provides a number of models in which iterations have an important place (it’s not like either the authors of CMMI or the authors of the diverse agile methodologies re-invented the wheel). The explicit goal of CMMI, and of its predecessor CMM, is to increase software quality and decrease the risk of software failure, failure of software delivery and failure of software to be “up to spec”. Agile methods actually have the same goals, but may have a different approach to reaching them in that they make the approach explicitly iterative and incremental, focusing on the small increments that might (or very well might not) end up with the end goal. CMMI focuses on the end goal and CMMI users are usually less interested in the individual increments.

In order for a process to become more mature, it has to progressively add and follow-up on configuration management, process and product quality assurance, planning of all kinds, etc. etc. (actually, that’s mostly level 2):

Capability_Maturity_Model

So merging CMMI and Agile really comes down to one thing: doing all that, in small steps, for every iteration. That’s really all there is to it!