Agile and CMMI: Better Together

9 July 2008

Organizations follow many paths in their pursuit of excellence, applying various principles, methods, and techniques along the way. It stands to reason, then, that an organization interested in adopting agile practices might also be interested in PMI’s OPM3, ISO or Capability Maturity Model® Integration (CMMI) as a means to achieve that excellence. While I have seen some organizations that are trying to implement agile and a PMI model at the same time, none are doing it successfully. Last year, in fact, I observed two very large companies that had simultaneous internal initiatives to utilize agile and CMMI. At both companies, each group saw the other as competition. I left both organizations frustrated. It doesn’t have to be that way. CMMI and agile frameworks can, and should, at least coexist peacefully and may, and I know this is a stretch for many of you, be able to work together.

Many believe that agile and CMMI are polar opposites and sub-optimize each other’s efforts. In the ongoing battle between traditional and agile frameworks, proponents of each side exhibit a general intolerance to the other's ideas. However, this adversarial attitude is not just unreasonable; it's counterproductive to the task at hand: developing the highest-quality software in the shortest possible time. Creating an effective mix of models and methods, with selected techniques to troubleshoot specific challenges, appears to have the highest return on investment

CMMI Refresher

Capability Maturity Model® Integration (CMMI)1 is a process improvement approach that provides organizations with the essential elements of effective processes. It can be used to guide process improvement across a project, a division, or an entire organization. CMMI helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.

Interestingly, CMMI was created to address some of the same concerns about software development that agile practices were created to resolve. In the early 1980s, the United States Air Force funded a study by SEI to determine why many software contracts were over time and over budget. Their conclusion: poor processes. The contractors, on the other hand, determined that the inability to come in on time and on budget was a result of continually changing requirements.  While the first group marched off to develop more process, the other group looked to develop methods to allow those changes later in the software development life cycle without increasing rework. This continued in 1998, when TSP was built to complement CMMI and accelerate adoption by providing the "how to" for the "what to do" found in CMMI. What many fail to see is that agile practices can also provide the “how to.”

To the new generation of agile practitioners, CMMI may seem bloated, dull and unimaginative. Critics of CMMI complain that it is overly bureaucratic and promotes process of over substanceiii thus impeding the time-to-market requirements needed today. By the same token, critics of agile state that is doesn’t have enough control and results in undocumented changes and chaos.

Critics also state the CMMI represents a classical engineering approach that does not take under consideration numerous human cognitive, organizational, and cultural factors essential for the success of every project. To those critics, agile practices, which focus on human interaction and are removed from the assembly-line process models, are an improvement. Paulk (2001)2 takes a closer look at how the two approaches are not entirely at odds and illustrates how a development group following extreme programming might simultaneously embrace CMM level 3. At level 3, the approaches diverge. Boehm and Turner3 emphasize not only balance but also how applying both initiatives can improve an organization significantly.

CMMi can provide process where none existed, peer reviews to improve quality, and much needed version control.  I am sure I am not the only person who has been shocked and dismayed to find multi-national companies today who still do not have these rudimentary “common sense” controls in place. By choosing the right mix of principles, methods, and techniques we eliminate the dilemma. However, there are challenges with implementing CMMI and agile at certain maturity levels as well as a sweet-spot maturity level for an agile implementation.

Agile Sweet Spot

An agile implementation should be tailored to match an organization’s actual maturity level; however, implementing agile when an organization is at CMMI level three can result in less rework and improve the overall CMMI initiative while providing the significant benefits of agile. Implementing a CMMI compliant software development process that is also agile will bring the repeatability and predictability offered by CMMI.  Agile, by design, is highly adaptable and therefore can be molded into a CMMI-compliant software development process without altering the primary objectives set forth by the Agile Manifesto.

When an organization is at CMMI level three, processes are adaptive to the team and environment with a focus on delivering working software. In addition, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project. Therefore, the effort needed to implement agile resides only in the modification of the standard processes to incorporate agile practices. The agile implementation risks are centered around overhead, as organizational controls can limit team decision making and flexibility. 

Challenges with Implementing Agile into CMMI Level 3

When an organization is below CMMi level three, it lacks stable processes for project, requirements, and configuration management. Because of an overall lack of discipline within the enterprise, the agile implementation must expand to provide the missing software development processes. In an organization with CMMI maturity level zero or one, processes usually change based on the user or event. Agile projects can be successful in these circumstances but may not be repeatable. The organization does not have a stable environment and may not know or understand all of the components that make up its environment. As a result, success in these organizations depends on the institutional knowledge, competence, and heroics of the people in the organization, as well as the level of effort expended by the team.

At CMMI level two some processes are repeatable although they may not repeat for all the projects in the organization.  Implementing agile practices and measures provides the structure and discipline needed to raise the organization to CMMI level three. At maturity level two, agile implementations will cost more; however, they can really highlight the benefits of agile alone. Agile schedule tracking through burndown charts and task boards easily allow the organization to see the impact of this discipline, thereby increasing the acceleration of the adoption. The overall philosophy, methods, and practices of agile frameworks inherently address the CMMI level two’s organizational risk of exceeding cost and time estimates and can make the time living at level two significantly shorter. I have successfully used agile as a means to raise the capability level from a zero to a level two, while increasing customer satisfaction and ultimately feeding our bottom line.

At maturity levels greater than three, processes are expected to be the same across an organization. Without significant modification to the documented processes that must support CMMI level four, the flexibility that agile can bring is limited.  Since an agile project’s progress is visible, such projects dovetail beautifully into the intent to allow management to quickly identify adaptive measures needed to keep cost, schedule, and scope in control. A critical distinction between maturity level three and maturity level four is the predictability of process performance. At maturity level four, the performance of processes is controlled using statistical and other quantitative techniques and may be quantitatively predictable. I have not had the pleasure of actually applying agile to a CMMI level four organization yet.

Conclusion

Much has been written to map the Capability Maturity Model (CMM) to agile practices that clearly indicate the synergy between the two.  Educating ourselves on CMMI process areas, maturity levels and being able to help transition between agile and CMMI is clearly in our best interest.

1. Most of the material related to CMMi is taken verbatim from the Software Engineering Institute web site http://www.sei.cmu.edu/cmmi/ with the intent to keep the information as accurate as possible. Where other sources are used, they are individually cited.

2. Paulk, 2001. M. Paulk, Extreme programming from a CMM perspective. IEEE Software 18 6 (2001), pp. 1–8.

3. Boehm, B. and R. Turner (2003). Using Risk to Balance agile and Plan Driven Methods. Computer, IEEE Computer Society.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (1 ratings)

Comments

Bas Vodde, CST,CSP,CSM,CSPO,REP, 7/11/2008 9:19:49 PM
http://www.softpanorama.org/SE/CMM/index.shtml
Harry Long, CSP,CSM, 7/23/2008 9:32:42 AM
In an interesting observation, Agile processes seem to be more effective when the organization is coming from a more structured past into Agile than when an undisciplined approach tries to use Agile to firm it's processes. On the first scenario, the overarching structure serves as a "safety net" to prop up performance during transition. It seems like without a "safety net" an organization that did not have a defined process may find itself in the original chaos state it started in, frustrating team members and stakeholders alike.
Geir Amsjo, CST,CSP,CSM,CSPO, 8/7/2008 3:40:09 AM
Thank you for a great article on a highly interesting topic, Cindy!

It strikes me over and over what huge differences there are in the software industry, and I must say that I prefer the (young) small companies with almost no structure or discipline at all before the (old) rigorous CMMI Level 3 organizations when it cones to introducing Scrum.

At CMMI level 3, organizations tend to develop detailed, rigorous process descriptions and control routines. CMMI doesn't say that these things must be rigorous, but they tend to be. The strive for completeness and to build "water-proof" systems that holds the certification is probably the drivers. In CMMI level 4 and 5 these things tend to be lighter again; only the things that really matter are kept detailed.

In my experience it can be exhaustive to work with Scrum in an L3 organizations. It is much harder to take things out of rigorous systems than to make sound lightweight structures from scratch. Not to mention the endless discussions with the "quality people++" that will object to the notion of trusting people...

It can be extremely time-consuming and expensive to climb the CMMI ladder. But agile can change this! Working in short iterations makes the cycle times much shorter and the learning opportunities are 10 to 100 times more frequent! As far as I understand the SEI now acknowledge that CMMI compliant processes and routines may be lightweight.

Conclusion: Scrum and CMMI fit very well together and by using Scrum (in addition to the Lean Software Development principles) as a vehicle for CMMI one may reach excellence much faster and cheaper!
Christophe Le Coent, CSM, 1/25/2009 3:16:58 PM
Having worked in a CMMI 3 level organisation, I think the issue with CMMI is not CMMI itself but the culture of the people implementing it being too rigid: they lack of business awarness and they write processes without common sense and understanding on how people work. So I believe the challenge of a CMMI organisation to move from Waterfall to Agile is to change the culture of the Company and its people. CMMI and Agile do fit well together, once you have removed the people who just can't fit in.
Dick Carlson, CSP,CSM,CSPO, 8/5/2009 11:37:01 AM
Being CMMI compliant also means that defined processes for developing and maintaining software requires objective evidence. Much of such evidence is in the form of documentation (e.g. plans, specs, etc.), and without these artifacts, CMMI compliance is essentially impossible. I have been very active in my organization during the past several years in establishing agile methods and practices, but we continue to hit walls when it comes to true agile implementations. The company's culture, like many large companies, is used to document and process laden methods (i.e. waterfall) and are reminded by the process police that tailoring out documentation because you want to follow agile practices goes against the CMMI's criteria for objective evidence. I have been able to map about 16 of the CMMI's process areas to agile practices, but that does not mean executing "true" agile practices is possible without detaching from the CMMI's objective evidence requirement (e.g. appraisal materials, qualitative and quantitative information, records, or statements of fact). The majority of articles that compare Agile and CMMI avoid this aspect like the plague, mainly because most of the authors have not been in the trenches enough (or at all) to see this effect. Another problem lies with customers who are not yet ΓÇ£Agile savvyΓÇ¥ and are reluctant to change, but thatΓÇÖs another story.

You must Login or Signup to comment.