CMM & Agile

I’ve finally, about 6 months after everyone else, got around to reading the Software Engineering Institutes report on CMMI and Agile. Entitled “CMMI or Agile: Why Not Embrace Both!” the report argues that CMMI and Agile are not only compatible but complement one another. Actually, you can guess at what the report says from the fact that the title ends in a exclamation mark (“!”) rather than the question mark (“?”) you might expect.

The report argues that the two are compatible and complementary. They make a strong case and I for one am glad. CMM initiatives have too often made the words “process improvement” dirty words. They shouldn’t be, it is what we should be doing.

The report argues that CMMI, and its predecessor CMM, have been misunderstood and misused by the industry. Firstly CMM(I) was taken to be a methodology when it was a model. CMM(I) doesn’t tell you what to do, it allows you to evaluate your capabilities.

The second mistake compounds the first by imposing CMM(I) on organizations. Rather that improving an existing process and organization CMM(I) initiatives have replaced what already exists with something else - and in the process destroyed the good that existed. This is the scenario I wrote about a few weeks ago in “A true story about CMM”.

There are a few points were I could take issue with the report.

My first issue is that the report does not define what it means by ”Agile.” I agree this is a problem, and one I’ve been thinking about addressing in this blog. But, CMM and CMMI are very well defined while Agile is not. How can one critique a method without defining what is mean by the term?

Second, the report seems determined to identify an “Agile Institute” to mirror the Software Engineering Institute. It seems to spend a lot of time talking about the authors of the Agile manifesto and founders of the Agile Project Leadership Network. Neither of these groups owns the term “Agile” or speaks for the whole Agile community. There is much under the Agile umbrella which, rightly or wrongly, falls outside these two groups.

Comparing Agile and CMMI is an asymmetrical comparison. One is clearly defined, with a well funded champion to issue standards, revisions and issue certificates. The other is the ill-defined product of an ill-defined community which owes as much to the punk ideal as anything else.

A bigger issue with the report concerns why you might want to bring CMM(I) and Agile together. The report spends several pages early on explaining that the CMM grew out of one type of environment with one set of problems. Namely large projects, often military in nature, often with life at risk, and with a low-trust relationship between supplier and client.

Conversely, Agile came from a different environment: mainly corporate IT groups, small projects (no more than a dozen or two people), with high-trust within the team. Failure to understand these origins and contexts has led to much misunderstanding between advocates of the two.

Given that these two environments still exist, and that Agile has demonstrated success in its native environment and CMM(I) has demonstrated success in its native environment, then why would people in either environment want to adopt elements of the other?

I don’t think this question is really answered. This is a shame because the authors have spent a lot of time setting up a story to explain why we got where we are today but don’t explain how that story ends.

To my mind the story only tells part of the truth. Both CMM(I) and Agile have been sold into many organizations outside their native environments. There are many people who want the respectability of CMMI, and there are others who want the fashion of Agile. Nor am I aware of anyone in the Agile or CMMI camps saying “Don’t do that sort of project with our model.”

I’ll defend Agile here because I believe Agile has, and is, a journey of exploration. The underlying principles are universally applicable but that doesn’t mean all the details are worked out in any given field yet. So if you ask me “Can I do Agile on an X type project?” my answer is “Yes but I may don’t know how immediately.”

However the SEI folks who wrote this report claim CMM(I) has been misapplied. So I ask: which of them was saying “Don’t use CMMI on an X type project” ?

My final niggle is one of clarity. The report has five authors. Several of those authors are quoted and referenced throughout the text to support the arguments made. Yet nowhere in the report, when one of the authors is quoted is there a disclaimer. That is, the report does not say “Smith, one the authors of this report showed the CMMI is effective (Smith 2003).”

The names of the authors aren’t hidden, there is no subterfuge but its not clear and I wish they had been.

On the more positive side there are several quotes in the report worth calling out. About Agile and CMMI:

• “In today’s increasingly dynamic world, CMMI-based organizational process improvement approaches cannot rely exclusively on traditional project management approaches, waterfall-based project lifecycles, and heavyweight analysis methods.”
• “CMMI and Agile can complement each other by creating synergies that benefit the organization using them. Agile methods provide software development how-to’s that are missing from CMMI best practices that work well”

And about CMM(I) and the approach companies have taken in the past:

• “Too often, CMMI has been applied rather than implemented”
• “SCAMPI appraisals are not audits or tests”
• “the complexities of large-scale projects require a more involved infrastructure, this fact is not a license to create unnecessary bureaucracies and unbalanced production at the expense of productivity”
• “Using process experts to create and deploy process improvement activities is not unusual, and often has the advantage of allowing these experts (and the project teams) to focus on their respective tasks. But what makes this approach risky is that project personnel are frequently left out of process design activities and are disinclined or openly skeptical toward the adoption of process improvement activities. This situation is typical of some Six Sigma style approaches to process improvement as well. Quality process teams are created and given the responsibility for quality. As a result, developers abdicate their responsibility for improvement (or worse, for quality).”

Interestingly I also noticed that the SEI’s own Team Software Process (TSP) is now listed as an Agile method. I’ll have to look into this some more.

I am also please that the report highlights the role of organizational learning in software development. Regular readers know this is something I’m very keen on (heck, I wrote a book on the subject!) so I’m pleased to see it explicitly considered.

Even with my reservations I welcome the report. I believe it is a roundabout endorsement of Agile (in its various forms) by the Software Engineering Institute. It is also a very big sign saying “Agile and CMM(I) are compatible.”