Created: Thursday, 21 May 2015 06:29
The following artical is written by Cindy Shelton and can the found on scrumalliance.org
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 thebenefits 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.
Tags:
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. - See more at: https://www.scrumalliance.org/community/articles/2008/july/agile-and-cmmi-better-together#sthash.IWOebZAi.dpuf
