In this first part of a two-part interview with Paul McMahon, author of Integrating CMMI and Agile Development,...
we learn more about how CMMI, a traditional process improvement model, and Agile, a category of software development methodologies that emphasize less rigor in process and documentation, can be combined for performance improvement of your software development efforts. Read part two to learn more about achieving a higher level of CMMI maturity.
As you state in your book, the four values of the Agile Manifesto are:
• We value individuals over processes and tools.
• We value working software over documentation.
• We value customer collaboration over contract negotiation.
• We value responding to change over following a plan.
The Manifesto clarifies that “while there is value in the items on the right, we value the items on the left more.”
CMMI is a rather rigid, traditional model that is all about process improvement. My understanding and experience has been that there is a tremendous effort put on defining and thoroughly documenting repeatable, measurable processes that then can be evaluated for improvement. This all seems very “right-sided.” Isn’t this emphasis on heavy process documentation almost the opposite of what is thought of as agile?
McMahon: It is true that the CMMI is viewed by many as “rigid,” but this is a fallacy that has resulted from how many organizations have incorrectly applied the model. The model does provide a comprehensive set of “best practices” that are intended to be used to help an organization ask the right questions to determine what the right processes are for their organization given their business domain. But the model does not dictate how an organization must package its processes, or how “heavy” or “light” they decide those processes should be.
Throughout my book I provide numerous examples demonstrating this. In the BOND Case Study I explain how we handled the Decision and Analysis (DAR) Process Area of the CMMI model without even developing a DAR process. I also provide guidelines that we used in the BOND organization that helped us keep all processes as short as two pages. “Light” process documentation caused us no problem during the formal CMMI appraisal at BOND.
As another example, many organizations falsely believe they have to develop processes for every Process Area in the CMMI model. I provide an example in my book showing how you can achieve all the goals of the CMMI Level 2 and 3 Process Areas using far fewer processes than many believe are necessary. Specifically, I demonstrate one way an organization could develop 11 processes that achieve all the requirements of the full 18 Level 2 and 3 Process Areas. How “heavy” or “light” your documentation should be is up to each organization to decide. Used correctly, the CMMI model helps each organization ask the right questions leading to the right decisions for its situation.
In your book you write about how to increase agility in CMMI mature organizations. Can you give us some examples of what practices can be done to make processes more agile, yet still maintain CMMI compliance?
McMahon: The LACM Case Study is probably the best example of this in my book. LACM is an organization that had previously achieved a CMMI Level 3, but afterwards initiated a process streamlining effort. We referred to this effort as “leaning” and “pruning” the processes. Through the “pruning” process we developed process flows of what people actually did to get their job done.
These were not theoretical diagrams, but rather were developed by people who told us what they actually do every day on the job. Anything that didn’t end up on a diagram, but was in the released process documentation, was a candidate for elimination.
We then asked a series of questions: If no one used something, why was it there? Were we wasting time training people on the use of certain process assets? Did we believe people should be using certain process assets that weren’t being employed? Did we believe that if they did use them, it would help get their job done more effectively?
In the LACM Case Study I describe how we were able to simplify the processes substantially through this effort. I also provide examples demonstrating how people had placed work tasks in the processes thinking the CMMI required it, but how, in fact, this was false. The requirement to collect excessive peer review data is one example I describe in detail in the book.
What is most interesting about the LACM Case is that not only were we able to make the processes more agile while still maintaining CMMI compliance, we actually found out that it was far easier to ensure CMMI compliance was actually being achieved after the processes were simplified. This was because the streamlined processes helped people understand the real expectations of the organization with respect to their job and the CMMI requirements.
Dig Deeper on Software Quality Management