CMMI: Less Hyped Than Agile but Equally Popular?

A recent Methods & Tools poll examined at what stage is the CMMI approach adoption in software development organizations.

Not aware	13%
Not using	29%
Investigating	8%
Analysed and rejected	4%
Trying to reach Level 2	12%
CMMI Level 2, 3 or 4	20%
CMMI Level 5	14%

Participants: 392

Ending date: January 2009

Many software development concept of the 80s and 90s have left the spotlights of the professional press and the blogging world, either because they are soooooo obvious, as in “of course everybody is doing object oriented programming today…”, or because they didn’t meet the expected success, as the object oriented database that were supposed to replace this old relational SQL technology of the 70s….

CMMI is the successor of the Capability Maturity Model (CMM) or Software CMM. The CMM was developed from November 1986 until 1997 as part of the software process maturity framework project. Then the CMMI, where “I” stands for Integration, replaced the CMM. This is certainly not currently a hyped concept. You will find no CMMI category on dzone.com or infoq.com and the CMMI channel on reddit.com has two subscribers. I was therefore surprised to see that the adoption, ignorance or rejection rates for the CMMI were very close to the results achieved by a similar survey on Agile approaches ended at the beginning of 2008.

I didn’t find any former statistics about the CMMI adoption, so it is difficult to compare the results of this survey with other numbers. These survey results are telling us that formal process adoption is growing in software development organization. The importance of CMMI numbers can be explained by the geographical diversity of Methods & Tools readership: an important percentage is coming from Asia where the CMMI label is important to sell outsourcing services.

Knowing that CMMI adoption rate is close to the Agile rates, I wonder also if there were some overlap, thinking that there are many companies without a formal process. I found a survey on Dr Dobb’s with some numbers on companies doing both CMMI and Agile. According to this survey, the rates of success of Agile and CMMI projects are very close, just above 50%. You could interpret the results as whatever the process, as long as you have one, you improve your success rate, which would mean that some discipline bring rewards. These numbers also tell that you have still close to 50% chances of failure, which could mean that discipline is not easy to achieve in the software development world. Please note that the Version One Agile survey seems to indicate a higher rate of success for projects, even if the type of questions makes direct comparison difficult.

Although there are some evidences that CMMI and Agile can coexist, the overall impression of people dealing with process improvement is that there are still important cultural differences between the two communities. Even if the non-prescriptive nature of the CMMI is recognized by agile developers, the overall impression is that this approach are still leaning heavily on plan-oriented and documentation processes, thus conflicting with the lightweight aspects of Agile. To contradict this culture incompatibility, there is the example Systematic, where a CMM level 5 company has added Scrum on top of their process, gaining a 50% cost reduction. This maybe not so astonishing if you realize that CMMI and Agile both try to achieve process improvement and both require discipline. Managing one week Scrum iteration with daily meetings should provide a strict control of project progress. Therefore organizations that followed the CMMI way for a good reason, that is not just for having a label to sell their services, should be naturally attracted by the process improvement tools contained in Agile. Other organizations than Systematic have also added agile practices above CMMI, but the opposite doesn’t seem obvious.

Maybe the software development world would be better if people could see approaches like the CMMI or Agile as toolboxes and not cult-like concepts that should be embraced with a blind faith… and a tendency to see other movements as “heresies” that can only be condemned. As Chris O’Brien (Software Capabilities Manager at Gen-i) says “So CMMI and Agile are complementary, but the use of either should to be based on business needs. I believe both have an immense amount to offer and co-existence will make sense for many organizations – particularly those that are capable of applying learnings from their industry with intelligence and care, to achieve results.”

References

CMMI Main page at SEI

Software and systems firms embrace CMMI - India Trends - Express Computer India

CMMI or Agile: Why Not Embrace Both!

Dr Dobb’s article: Agile CMMI?

Mature Agile with a twist of CMMI

Scrum and CMMI Level 5: The Magic Potion for Code Warriors

Systematic Gains Chart

Methods & Tools Agile Survey

CMMI articles list in SoftDevArticles.com

(r) Capability Maturity Model, CMM, and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
(sm) CMM Integration is a service mark of Carnegie Mellon University.

What's Right with Agile Methods

In the recent years, the agile development approaches have been gaining more and more interest and acceptance in software development organisations. This has been a rapid adoption for ideas that were formalised in 2001 with the signature of the Agile Manifesto by a group of software development thinkers.

The basic value of agile approaches is to put back some emphasis on the importance of people collaboration, both developers and customers, in software development projects. This position was taken at a time where the software development world was under the influence of "process-centred" visions that could be exemplified by approaches like the Capability Maturity Model (CMM) or the Rational Unified Process (RUP). These visions provide an enormous amount of valuable material on how to develop software in a well-structured framework. Even if the goal of these approaches was to provide a global framework that has to be adapted to the specific situation of each project, the natural tendency of people was to perform every activity proposed, often for fear of missing something important. The basis of the agile movement is what I would call a "bottom-up" approach. You have to do just the minimal set of activities to produce quality software that satisfies the customer needs. They are also appealing for people who are ready to trade the sometimes false security of planning for the added flexibility of an always changing context.

Agile approaches are not the silver bullet of software development. One could argue for instance that "constant customer collaboration" is not so easy to realise in the real life. Tom Gilb also argues that agile approaches are soft on requirements quantification and many thinks that "you cannot manage what you cannot measure". Although agile approaches are strong on project status (especially with Scrum), their overall reluctance to spend initial time in analysis and design make them use a "soft" approach to requirements definition and prioritization. Agile ideas could not be considered as new. Prioritising requirements for short iterations could be seen as rebirth of evolutionary development or of the "time boxing" principle of RAD. We will have to see how applications developed using an agile method will evolve during their maintenance phase, even if we cannot say that applications developed using other approaches are necessarily easy to maintain. Finally, agile approaches will have also to face the "mass adoption barrier". Early adopters of new approaches are often motivated and intelligent people trying to improve their current situation. With this kind of people, it is easier for projects to succeed. It is when the "average" developer starts to use a new approach in the "average" organisation that its value can be fully acknowledged.

It should be recognised that agile approaches have brought a balancing influence to the "process is the king" attitude and that many projects could benefits from this "good enough" software development processes that need a strong customer-developer collaboration. You should also consider that agile development is not a weak approach. Individuals have a strong individual responsibility to produce quality code with a strong emphasis on unit testing and short iterations provide improved visibility on the project status and achievements. You cannot hide failure very long if you deliver every two weeks.

Finally, the conclusion is that there is nothing right or wrong with agile approaches. Each project has its own context: development teams, customer requirements and organisational environment. You have to adopt the process that gives your project the most chances to succeed under the current circumstances, taking valuable tools from every approach.

Spring 2007 Issue of Methods & Tools

In this issue you will find an interesting experience report on software process improvement, a detailed how-to article on modelling by one of the father of Information Engineering, an insightful reflection on how to build trust in a hierarchy relationship and finally a approach to improve the release of software products.

Spring 2007 issue's content:
* Process Improvement – Is it a Lottery?
* Strategic Modeling for Rapid Delivery of Enterprise Architecture
* Fear of Intervention - How Subordinates Grow to be Entrepreneurs
* A Methodology to Support Software Release Decisions

40 pages of software development knowledge.

Download page for the PDF issue