Agile Maturity Model Adherence - Be Careful What You Wish For!
Climbing the Ranks of Your Agile Maturity Model Can Be a Futile Exercise
Climbing the ranks in an Agile Maturity Model looks fabulous on a spreadsheet. It feels like you're leveling up and making a difference. Yay team, we now have more green boxes ticked!
You’re like Mario in the picture below, trying to jump higher and higher until you reach the top of the flagpole.
But is reaching the top of the Agile Maturity Model what we should aim for?
The flagpole provided by the Agile Maturity Checkbox helps to make visible how much you accomplished, but did you really accomplish anything? And how do you know that?
The big assumption is that improving in the Agile Maturity Model will help you get the desired results. The higher we reach on the flagpole, the better our results.
But is this assumption really valid? Let’s dig in and explore further to answer this tricky question.
The Promise and Appeal of Agile Maturity Models
Let’s start by stating the obvious. It’s not climbing the Agile Maturity Model that we want, but the results it promises to help us obtain what we want.
We could visualize the situation as follows:
We want to do things that improve our way of working.
So that we get better at delivering results
To actually have better results.
Easy peasy lemon squeezy, right?
But faced with an endless sea of possibilities, what are those pesky things we should do to improve our ability to deliver better results? We end up in a pickle when we try to answer this question. That’s a much more difficult question to to figure out that we could depict as follows:
How do we know what things we should improve in order to deliver better results? Let’s enter the magnificent world of Agile Maturity Models to answer that question.
The Promise and Appeal of Agile Maturity Models
Agile Maturity Models allow you to gauge your current Agile maturity. What are the areas where you’re doing well, and what are your areas where there is room for improvement? By climbing the ladder of the Agile Maturity Model, the promise is that you’ll deliver better results.
The Agile Maturity Model provides a proxy for what you should do to deliver better results. Climbing the ladder of the Agility Model means you get better at delivering the results you want, which ultimately means you will deliver better results.
We could visualize it as follows:
The big assumption baked in here is that by improving in the realm of the Agile Maturity Model, you will also improve at getting the results you want.
But is this really true? Does climbing the ladder of your Agile Maturity Model make you better at delivering the results you want? And how do you know that?
The Agile Maturity model makes it easy to make visible how much you accomplished, but that doesn’t mean you’ve accomplished the ultimate goal of delivering the better results you want.
This probably all sounds pretty abstract, but let’s walk through a concrete example.
Example: CMMI Agile Maturity Model
Before we walk through this concrete example of an Agile Maturity Model, I want to underline I’m not criticizing the model itself. It seems like a great model. I picked this model because it looks strong on paper. The model makes explicit what it can help you to achieve (and implicitly tells you what it will not help you achieve).
ThoughtWorks, together with Jez Humble and Rolf Russell, has developed the Capability Maturity Model Integrated (CMMI) Agile Maturity Model.
I want to stress this is not the ‘generic’ Agile Maturity Model of ThoughtWorks, which has a broader scope of applicability. This is a specific model that was created with the following objective in mind:
“The Capability Maturity Model Integrated (CMMI®) is intended to institutionalize a collection of pre-defined delivery practices and ensure their consistent execution so as to increase the probability that a team or organization can successfully complete projects. The definition of “successful” includes completing the project on time and in budget.”
- The Agile Maturity Model Applied To Building and Releasing Software
If you were to use this model in your organization, you’d basically be doing the following:
You’re trying to follow a collection of pre-defined delivery practices and ensure their consistent execution.
By doing so, you will increase the probability that your teams or organization are better able to complete projects successfully.
Better results are promised: you will have a higher proportion of projects that are on time and within budget.
We could visualize this as follows:
When you walk through this diagram, it becomes immediately obvious that instead of worrying about what things we could do to improve our way of working, the things we should worry about are:
What are the results we want to achieve?
How good of a proxy is climbing our Agile Maturity Model in helping us to obtain the results we want to achieve?
Let’s explain this more clearly by walking through an example. Imagine you’re running a highly efficient and smooth Feature Factory. Your biggest challenge is figuring out the right thing to build that will help make a difference in your customers' lives and help you deliver more business value. Does it make sense to implement the CMMI model as a first choice?
You can have a perfect score on this model, while:
Never talking to customers
Never doing any discovery
I want to stress, this is not a critique of the model, as it never promises that will help you improve at building the right thing. However, you do have to know what it's good for when you use it, so you know what you're optimizing for.
If you’re running a smooth Feature Factory, it’s not frequent and consistent delivery that’s the problem. You should probably look in the direction of improving your discovery practices and how good you are at validating the value of what you’ve delivered for your customers and the business.
Unless you tie the Agile Maturity Model back to the results you want to achieve, and the kind of practices that will help you to do that, you're busy chasing windmills. The results you want should be leading, not the adherence to a model that might very well might be suboptimal and an imperfect fit for your situation or what you’re trying to achieve.
There are many Agile Maturity Models out there that:
Don’t make clear what you can achieve by implementing the model.
When they make clear what the model can help you achieve, they’re not being truthful. It’s more marketing and selling you the model rather than being honest about the limitations of the model.
Even if they’re clear on what they intend to help you achieve by implementing the model, it doesn’t mean climbing the levels will help you do that.
And that’s why you have to watch out when implementing an Agile Maturity Model. Climbing the levels doesn’t necessarily mean getting the desired results.
What should we do to increase our success chances when implementing an Agile Maturity Model?
Evaluating Agile Maturity Models - Don’t Blindly Trust the Ladder
When evaluating an Agile Maturity Model, like with the CMMI, you should keep the following in mind:
What do you want to achieve? What is the objective you have in mind before deciding to evaluate any Agile Maturity Model.
The Agile Maturity Model you’re trying to implement should be very clear on what it helps you to achieve and what it does not help you to achieve. If the model doesn’t provide such an explicit explanation or promises you a pot of gold at the end of the rainbow, then you should be highly skeptical.
When implementing an Agile Maturity Model, you should always be skeptical. Your situation or context might be very different than what the Agile Maturity Model was intended for.
Remember, adherence to the Agile Maturity Model is not our ultimate goal. Our adherence to the Agile Maturity Model only matters to the extent it helps us deliver the results we’re looking for.
Don’t blindly trust climbing the ladder. Trust the results you get from climbing the ladder.
When you’re like Mario trying to reach the top of the flagpole, make sure the top of the flagpole is a decent and reliable proxy for what you’re looking to achieve.
Great stuff, Maarten. I've been there and witnessed that. Especially the anti-pattern of wanting to get higher numbers in the maturity model without understanding what it really means for the team: "In the column 23 of the spreadsheet, we moved from 60 to 75%" - "OK, great and what does it mean? What changed? What improvements did you make?" - Getting a blind look in response...