Maturity scales and capability models: what Accelerate gets right

Anyone who has read Accelerate by Nicole Forsgren, Jez Humble and Gene Kim will be wary of maturity models. The book makes the case directly: to drive change, focus on capabilities, not maturity. Yet many transformation teams still use maturity scales every day, and get real value from them.

Both can be true. The trouble with maturity models is rarely the levels themselves. It is how they get used. This article sets the critique beside the best defence of maturity models, then draws out the practices that keep a maturity scale useful for driving change.

The critique

In the chapter excerpt published by TechTarget, the authors set out why they prefer capability models. Their objections, in short:

• A destination instead of a journey. Maturity models focus on helping an organisation "arrive" at a mature state, as though improvement ends.
• One path for everyone. They are "quite often a 'lock-step' or linear formula", assuming every team passes through the same levels in the same order.
• A static bar. They "define a static level" of abilities to achieve, while technology and business conditions keep moving.
• Vanity metrics. Measuring tool adoption and skill levels, without linking them to results, produces numbers that look like progress and change nothing.

Capability models, by contrast, are "multidimensional and dynamic", and they "focus on key outcomes and how the capabilities, or levers, drive improvement in those outcomes".

The defence

Martin Fowler's short essay on maturity models from 2014 is the most useful counterweight. He sees a maturity model as a tool for assessing where a person or group is now, and for deciding what to learn next. His central point: "the true outcome of a maturity model assessment isn't what level you are". The real output is the list of things to work on next.

Fowler is just as clear about the misuse. Maturity levels lost their credibility when organisations used certification to claim superiority. Using levels to judge one group against another undermines the whole exercise, and he suggests keeping assessment results with the group that was assessed.

The research view

Academic work points at the same gap. Röglinger, Pöppelbuß and Becker reviewed ten maturity models for business process management against a set of design principles. They found the models generally good at describing where an organisation stands, but weak at prescribing what to do about it. They also noted that practitioners need ready-to-use, adaptable tools for assessment and improvement.

What they agree on

Read side by side, the critique and the defence agree on more than they disagree:

• The level is not the point; the next improvement is.
• Improvement never finishes.
• Teams don't all follow the same path.
• Comparing groups by level destroys the model's value.
• What matters is the link to outcomes, not a score for its own sake.

A maturity scale used that way is, in practice, a capability model with a shared vocabulary for "how far along is this?"

Seven practices for driving change with a maturity scale

1. Score capabilities, not organisations

Never give a team or process a single maturity number and stop there. Score each capability separately. A process can be strong on tooling and weak on ownership, and that difference is the whole diagnosis. An overall score is a summary for a slide, not something to act on.

2. Start from the outcome

DORA's guide to how to transform starts with a direction, a "true north", at organisation or division level. Choose the capabilities you assess because they drive that outcome. If you can't say which outcome a capability affects, leave it out of the model.

3. Treat levels as language, not a destination

Levels are useful because they give people shared words: "we're at defined on hand-offs, but initial on measurement." Don't turn them into targets such as "everyone at level 3 by Q2". Set the targets on outcomes, and let the levels tell you what's in the way.

4. Let each unit take its own path

The lock-step objection is answered by not imposing an order. Each team or process should work on whatever is constraining it now, even if that capability sits "higher" in the model than others it hasn't mastered. The scale shows where each unit is; it shouldn't dictate the sequence of work.

5. Make the output a list of improvements

Fowler's point, applied: an assessment should end with named next steps, not a level. Turn weak capability scores into specific blockers, each with an owner and a date. A score that doesn't lead to a decision is a vanity metric by another name. (More on this in From maturity scores to blockers.)

6. Re-measure on a rhythm

DORA's method is a repeating cycle: assess the current state, set measurable targets, run small plan-do-check-act experiments, then measure again. As the guide puts it, "Change management should be performed in a scientific way in pursuit of a measurable team or organizational goal." A maturity scale re-run every few months, against a stable model, gives you the "check" in that cycle for the capabilities you can't measure from a delivery pipeline.

7. Use results to help, never to rank

This is where maturity scales most often go wrong, and the fastest way to make one useless. If people believe the scores will be used to compare or blame teams, they inflate their answers, and the assessment stops telling you anything.

• Don't publish league tables or rank units by score.
• Write blockers about what is in the way, not who.
• Show the combined score and how much people agreed, not who gave which answer.
• When the same capability is weak across many units, treat it as a programme problem to fix centrally, not as a collection of failing teams.
• Share results first with the people who can act on them.

When a heatmap puts units side by side, read it for patterns: where the programme should invest, and which teams need support. That's what it's for.

In short

Accelerate is right that a maturity model used as a destination, applied in lock-step and scored for its own sake, does more harm than good. Fowler is right that a maturity scale is a useful tool when its output is the next set of improvements. Use the levels as shared language. Score capabilities, not organisations. Let each unit take its own path, turn low scores into blockers, re-measure on a rhythm, and never use the results to rank. Then a maturity scale becomes what Accelerate asks for: a way to find the levers and pull them.

Sources

• Nicole Forsgren, Jez Humble and Gene Kim, Accelerate: The Science of Lean Software and DevOps (IT Revolution, 2018). Excerpt on capability vs maturity models, TechTarget, March 2018.
• Martin Fowler, MaturityModel, August 2014.
• DORA, How to transform and the capability catalog.
• Maximilian Röglinger, Jens Pöppelbuß and Jörg Becker, Maturity models in business process management, Business Process Management Journal, 2012.