Many people ask themselves "Do regulations such as CMMI and agile principles go together?". The statement that Scrum and CMMI go together has been discussed countless times. The answer is a clear "yes". But many ask: "How?" There are also many different experiences: "In my organization, CMMI was implemented with a command-and-control culture. So how can CMMI fit in with agile principles?" This article provides clear answers to these questions.
How can I use CMMI with agile principles?
It all boils down to the interpretation of CMMI. While many people have experienced CMMI with a command-and-control culture, nowhere in CMMI is that written. Quite the opposite. When you apply agile principles, you arrive at a very different interpretation than with a command-and-control culture. If someone gives you a command-and-control interpretation of CMMI, that's their business. Make your own interpretation. Can CMMI be interpreted so differently? Not only can you, CMMI actually demands it.
"Where is that written in CMMI?" you might ask. Everywhere. It is one of the most important principles of CMMI that you interpret it in the light of your organization and principles. If these are agile principles, then use them. In the introduction, CMMI clearly states that every statement in CMMI should be interpreted based on "your organizational context and business environment". With this, CMMI wants to express that every statement in CMMI should be supplemented with the words "according to your organizational principles". If you live an agile culture, then add this. For example, CMMI asks: "How do you go about having a project plan?" Read this as: "How do you go about having a project plan - according to your agile principles?".
Because this is so important to CMMI, many practices explicitly include the words "as needed", "appropriate" or "sufficient". They all mean the same thing, namely: "Please, please really find a solution that fits the principles of your organization". You can also quickly see how wrong consultants are who come up with predefined process descriptions that you then have to implement "in order to work CMMI-compliantly" (whatever "compliant" means). How is this supposed to fit with your company's internal principles? This cannot be right.
Doesn't CMMI prescribe what needs to be done?
Many consultants like to say "you have to do this or that", but this is simply wrong. Your organization doesn't have to do anything. And under no circumstances do you deal with adults in this way.
CMMI is a grid that lists "what" an effective and efficient organization does. CMMI does not tell you "how" to do something. The "how" is what you design - according to your organizational principles. Use CMMI like a nice experienced coach asking you questions about your work, e.g. "How do you go about planning your project - according to your agile principles?" Well, with Scrum you have a pretty good answer to that. This is how Scrum and CMMI fit together.
What is the benefit of the "How do you proceed ..." questions?
The "How do you proceed?" questions from CMMI help you (and many others) to scrutinize the solutions you live by. So you can
- Identify useful but missing activities. For example, CMMI asks: "How do you go about identifying and addressing risks according to your agile principles?" Maybe you don't do this in your project, and so you come up with the idea that it might be a good idea to include risks in the Impediment Backlog.
- Identify gaps in the implementation of your organizational principles. You may realize that you are doing something, but that it does not correspond to your agile principles.
- Break big improvements down into small parts. For example, if you find that an organizational improvement cycle would be helpful, you might ask yourself the question "What are the "parts" of such a cycle? CMMI gives you guidance by listing a series of practices that make up such an improvement cycle. You can then implement this with agile methods, e.g. Organizational Scrum.
- Prioritize improvements. The CMMI maturity levels - often misunderstood as certification levels - are simply a prioritization of improvements, as we know from any backlog. If you have an impediment that you prioritize as maturity level 2, the improvement of this impediment will probably have a higher ROI than an impediment that you prioritize as maturity level 3. If you would prioritize differently, then do so. It is an aid, no more and no less.
Conclusion: With the "How do you proceed?" questions, CMMI is like a coach.
What are the benefits of combining Scrum and CMMI?
CMMI lists "what" an effective and efficient organization usually does. Scrum offers good solutions for the "how" of planning and executing projects. However, there is much more to an agile organization. What is the role of management? What about development? CMMI offers you the "How do you proceed?" questions for these topics too. This gives you an orientation that you can use to develop your organization far beyond Scrum - always using your agile principles as a guide for designing agile solutions for the "what" that CMMI lists. Yes, CMMI is much more than Scrum. But an organization is also much more than Scrum.
Isn't CMMI primarily about processes? Isn't that "command and control"?
This is probably one of the biggest misunderstandings of CMMI because the word "process" is used in many different ways. In CMMI, the word "process" simply means "work". When you read CMMI this way, many statements become self-evident.
In this article, I have suggested some word changes that will help you understand CMMI properly. Here's my tip to make CMMI much easier to read: Download CMMI as a Word file and search-and-replace some words. Replace "process" with "work". Replace "as needed", "adequate" and "appropriate" with "according to our agile principles". Voilá. There you have your agile CMMI. Save it. Use it for your agile organization.
This text is a repost of the article from November 2010.
Write a comment