Organizations follow many paths in their pursuit of excellence, applying various principles, methods, and techniques along the way. 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.
Why CMMI & Agile Together?
Capability Maturity Model Integration (CMMI) 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.”
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 Turner3emphasize 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. 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.
Formal & More Adaptable Journey Towards Agile
In a nutshell, agile CMMI is an incremental and iterative methodology that helps you deploy processes that are “Just Enough-Not Too Much.” This approach allows organizations to build processes incrementally, pilot them, learn as they go, try them out, get feedback, determine what changes are needed, and deploy them all in a structured, iterative environment. Because agile CMMI calls for performing small incremental actions and building upon everything that has come before, work is done in short iterations and “Process Debt” is avoided. Your organization goes through incremental changes over time, until you have a complete sustainable engineering process.
Compare this method to the traditional way of developing an end-to-end engineering process. In the traditional manner, somebody writes a huge manual, drops it on the heads of all the engineers and says, “Here’s how you are supposed to do your work.” Not surprisingly, this approach is most common and in most organizations, has not been successful. Smart people will reject processes that they weren’t a part of creating.
Agile CMMI methodology is different in that it involves all practitioners in the organization in a structured way. Anyone who plays a role in the engineering process will have a role in defining it. It helps you work incrementally to get what you really need: Greater clarity, better results and a faster journey toward continuous process improvement.
Implementing Agile into CMMI – Challenges
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. Companies 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.
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.
CMMI and Agile support and strengthen each other, and CMMI V1.3 is a significant improvement for organizations that are using agile practices, and makes it much easier assess an agile organization. If you want to migrate to agile, the CMMI is valuable as an improvement model, but you will probably need other supporting models for the implementation of agile.
Drop Us A Note
[gravityform id=”2″ name=”Drop us a Note” title=”false” description=”false” ajax=”true”]
