Christiaan Verwijs — May 3, 2019 — May 3, 2019
I always assume that the people I work with are professionals – and not children. This is why I don’t like maturity models in whatever shape or form. And we’ve got a lot of those in our industry. We have maturity models about development practices, about Leadership, about Scrum Teams, Scrum Masters and Product Owners. And about skills in general (Shu-Ha-Ri, anyone?). Everyone has a maturity model these days.
Some of the maturity models for agile and scrum I found on the internet in under 5 minutes. I’m not picking out particular models in this post.
What maturity models assume
If you look at the various maturity models, they usually assume the following:
- Growth is a linear progression through a number of discrete phases, each marked by unique characteristics;
- Growth looks the same across organisations, teams, and individuals. The context may affect the path, but it doesn’t affect the phases, what characterizes them or in what order they occur;
- What is on the right of the maturity is generally assumed to be ‘good’, whereas the left is assumed to be ‘bad’. This makes maturity models highly normative;
Growth is not linear and it doesn’t happen in discrete phases marked by convenient external characteristics.
Reality is far messier than your maturity model
I can easily challenge all the assumptions behind these models. Growth is not linear and it doesn’t happen in discrete phases marked by convenient external characteristics. If you take a closer look at the models, you’ll find that you probably do things that appear in different stages of each model. For example, I don’t believe that there are teams that only exhibit the characteristics of ‘Level 1’ in the Agile Maturity Curve, but none of the others. How are we to interpret their maturity? What does this mean?
You’ll probably also do a lot of things that are not covered by the models but are very helpful in your context. But because the model doesn’t mention them, are we supposed to consider them ‘bad’ or ‘not relevant’? Should we stop doing them?
And then there’s the question of how to interpret the characteristics in the first place. If a maturity model says “Lack of unit test coverage”, does that mean there are no unit tests at all? That there are some, but not enough? Or does it mean that the coverage is 100% but that the unit tests never break (a very bad sign)? Or what about “Department leaders have ownership in, and support Agile”. What do we mean by “ownership”? Does it mean leaders talk about Agile? Does it mean they attend important events? Does it mean they are actively involved in resolving impediments? Does it mean they are so invested that they are constantly getting in the way? Again, a single checkbox in a maturity model doesn’t do justice to reality.
This also ties into the question of who is actually using and interpreting the maturity model. Is it an external consultant? Is it the person him or herself? Is it management? This is where the next issue I have with maturity models pops up.
Why are we using words in a professional context that reference children and childlike behaviors?
Employees are not children
The very name of maturity models, and the driving metaphor behind them, encourages labeling people, teams and organisations as “‘immature“ or “not mature”. Although you can argue that this is just a word, words do have power. Why are we using words in a professional context that reference children and childlike behaviors?
Imagine that you’re working in an organisation where most of the Scrum Teams are ranked on one of the lower levels of a maturity model. Considering them “immature”, isn’t it likely that we’ll encourage exactly the kind of micro-managing behavior that we’re trying to move away from with self-organizing teams? After all, if a team is not mature this may easily lead to the conclusion that they need “strong guidance of a parent”. But what a team may need instead is more freedom, especially if organisations aren’t used to this. And perhaps some help in dealing effectively with that freedom. But we don’t need to encourage organisational parenting?—?there’s plenty of that already.
We don’t need to encourage organisational parenting?—?there’s plenty of that already
The same goes for the use of words like “Level” in these models. How are we making people feel if we consider their growth as a game where they have to “Level” up? How do we feel about people that are ranked above or below our “Level” in this organisation?
Models: intended to simplify reality
Of course, maturity models are meant to simplify the complexities of reality. But what is gained by squeezing such a messy, non-linear thing as the professional growth of individuals, teams, and organisations into an easily digestible model that allows us to feel like we’re making decisions based on something tangible? Oh, wait ….
Maturity models are the best friend of consultants. They are easy to understand and may seem very profound at first. It’s an easy way to make a good impression. This makes them excellent snack food for consultants, and for the organisations that are looking for easy answers to their complex problems.
Maturity models are the best friend of consultants. They are easy to understand and may seem very profound at first.
But just like with snack food, what looks appealing at first glance and seems to hit the spot when you consume it, doesn’t actually offer anything of substance on closer inspection. And it’s bad for you.
So now what?
I understand the need for simplified models to create some order in the messiness of reality. I also understand that models can help start important conversations about what is important, why and how to make progress on that.
But do we really need to use maturity models for that? If we use Scrum, isn’t the only thing we should care about whether or not we are capable of releasing a done & valuable increment that addresses important needs from stakeholders at least at the end of every Sprint? Keeping a laser focus on this will illuminate all the impediments getting in the way and serve a perfect vehicle for continuous improvement.
And can’t we just have those courageous conversations without feeling the need to quantify and qualify the maturity of people, teams, and organisations according to some external consultant with a maturity model that doesn’t consider our context? And can we please re-frame those conversations in terms of “experience”? Some people are more experienced, others less. But we are all mature adults. And professionals.
Business & Finance Articles on Business 2 Community
(103)
