In part one of this two-part interview with Paul McMahon, author of Integrating CMMI and Agile Development, McMahon revealed some best practices of bringing more agile development methods to CMMI-mature organizations. But does it work the other way? Are agile organizations open or resistant to documenting their processes and working towards CMMI maturity? In this second part of the interview, McMahon talks about his experience working with agile teams and how the CMMI model can be integrated into an agile organization, continuing to enhance agility rather than detract from it with unnecessary documentation.
You write about bringing process maturity through CMMI to agile organizations. I would guess there would be a lot of resistance from agile teams who feel the key to their success is their emphasis on the “left-sided” values, while CMMI imposes much more discipline on the “right-sided” values. Do you find acceptance of CMMI from purely agile organizations?
McMahon: I do provide in my book multiple examples of the kind of resistance we faced in bringing CMMI process maturity to agile organizations, but I also explain some very specific techniques that I employ to counter this resistance.
The first technique I describe is how to develop processes that focus on maintaining the agility of the organization and not changing behavior where that behavior has proven successful. This is critical to get the buy-in of the agile developers. The second technique that I use and describe in detail in the book is how I go about gaining the buy-in of agile teams in the areas where they feel they may be being asked to do things that don’t add value.
When I train people in agile organizations in the new CMMI processes we develop I focus on what we call the “stretch” areas which are the areas we are asking them to change their behavior. In the training I provide the rationale for the requested “stretch” behavior. My rule, as described in my book, is that we never add anything to the process beyond the current “agile” behavior unless we can provide solid rationale on how it will help the organization given its business goals. Making people do something because the CMMI requires it is NEVER an acceptable reason. If we can’t figure out a good reason to do it, we don’t do it. This has never caused any problem in a CMMI appraisal.
Is CMMI used in smaller agile organizations or is it only seen in enterprise or regulatory situations?
McMahon: Interestingly, the majority of my business growth over the past five years has been in helping small agile organizations (between 25 and 150 people) who have decided they want to increase their CMMI process maturity. I also find it interesting that small agile organizations can actually move faster to achieve higher CMMI maturity than many traditional development organizations. This is because it is much easier to document existing behavior than change behavior. In small successful agile organizations we do not have to change a great deal of behavior, but rather we need to document what people do, train new people in the process expectations, and share lessons across the organization.
With trends showing more and more adoption of agile methodologies, do you see a change in the adoption or use of CMMI?
McMahon: I see both CMMI and agile methodologies still growing. Once organizations understand how these two process approaches can actually work well together they understand the need for both in their organization. The CMMI helps organizations ask key questions that they would not think to ask when using agile approaches alone. On the other hand, agile methods provide valuable “how to” techniques that can help an organization achieve process maturity faster. Stated a little differently, the CMMI helps us understand “what” we must do, and agile methods provide proven “how to” techniques to help us do it. Once an organization understands how each can help the other it is natural to gravitate to both regardless of the size of your organization or your business domain.
Who do you think would most benefit from your book and why?
McMahon: Both large traditional CMMI mature organizations seeking to improve their performance, and small growing agile organizations that are recognizing that agile approaches alone don’t solve all the challenges they face.
From the large traditional CMMI mature perspective, we have learned a great deal about how to apply the CMMI model more effectively over the past few years. Agile approaches can help large organizations increase their performance and competitiveness. The large CMMI mature organizations should not fear change, but rather they should embrace it to help maintain their competitive edge. My book explains how they can do this without jeopardizing their CMMI compliancy.
On the other hand, small agile organizations that are growing quickly determine that agile approaches alone are insufficient to address all the needs of their organization. This is specifically addressed in Chapter 5 of my book as I provide a number of examples where the CMMI can help an organization even if it is implementing an agile approach successfully.
A third group who can also benefit from my book are organizations of any size who want to become more agile, but are experiencing difficulty because they are misapplying agile concepts. Sometimes we can learn the most from our mistakes. My NANO, GEAR and DART Case Studies can help any organization avoid the pitfalls others have made in trying to be agile, but misunderstanding what true agility is about.
Any final thoughts?
McMahon: I think the greatest benefit of my book is that it provides a balanced perspective that can help any organization use these two process aids effectively together to increase their organization’s performance. I would also mention in closing that in answering these questions I never mentioned my favorite part of the book, which is Chapter 9. This is a Case Study of a personal process improvement effort that I undertook where I demonstrate how you could use the CMMI and an agile approach together to help solve a personal challenge. The point of this chapter is to help the reader see these two process aids from a very different perspective which may help you gain insight not readily available through more traditional perspectives.