DevOps maturity is the honest answer to a question most leadership teams ask badly: “are we good at shipping software?” A tool inventory cannot answer it, and neither can a team that has been asked to grade itself in front of its own director. A structured DevOps maturity assessment can, because it scores observable capability rather than intent, and it ends with a dated plan instead of a slide.
This guide is a working method for UK businesses that want a defensible baseline and a twelve-month roadmap they can actually fund. It sits alongside our DevOps and agile methodologies work, and it assumes you have engineers shipping to production today rather than a greenfield platform still on a whiteboard.
You will find the capability domains a DevOps maturity assessment covers, the five levels and what evidence each one demands, the metrics worth tracking, a four-week assessment schedule, a scoring rubric that survives disagreement, the quarter-by-quarter roadmap itself, what it costs, and the mistakes that turn a useful baseline into an expensive filing exercise.
Table of contents
- What a DevOps maturity assessment actually measures
- The five DevOps maturity levels, from ad hoc to self-service
- DevOps maturity metrics that matter: DORA and beyond
- How to run a DevOps maturity assessment in four weeks
- Scoring DevOps maturity without turning it into theatre
- The 12-month DevOps maturity roadmap, quarter by quarter
- What the roadmap costs and how to build the business case
- Common DevOps maturity assessment mistakes
- Frequently asked questions about DevOps maturity
- References
What a DevOps maturity assessment actually measures
DevOps as a label covers enough ground to mean almost nothing on its own, which is why the assessment has to be specific. A DevOps maturity assessment measures how reliably and how quickly your organisation can take an idea from a decision to running, supported software — and how well it recovers when that software breaks. It is a capability audit, not a technology audit.
The four capability domains
Assessments that hold up under scrutiny cover four domains: delivery (how change reaches production), reliability (how the estate behaves and recovers), security and compliance (how risk is handled without stopping flow), and the operating model (how teams, ownership and funding are arranged). Score three of the four and you get a distorted picture. Most estates score far higher on delivery tooling than on the operating model, which is exactly why so many pipeline investments fail to move the numbers.
Why tool counts are not DevOps maturity
Owning a CI server, a container registry and an observability platform tells you nothing about DevOps maturity. The question is whether a change written on Tuesday morning is in production by Tuesday afternoon without a human copying artefacts between environments. Plenty of estates with an impressive tool list still have a release manager pasting deployment steps from a document, and plenty of modest estates deploy twenty times a day safely.
Capability, not compliance
A maturity model is not a certification. Nobody is coming to check whether you reached level four, and a level-five score with a business that cannot fund the next quarter is worthless. Treat DevOps maturity scoring as a diagnostic that tells you where the queue is, then spend money on the queue.
What a finished assessment produces
A complete DevOps maturity assessment produces five artefacts: a scored baseline per domain with the evidence behind each score, a value-stream map showing where change waits, a target state twelve months out, a prioritised roadmap with owners and dates, and an agreed set of measures that will be reported monthly. If your assessment output is a spider chart and nothing else, it is not finished.
The five DevOps maturity levels, from ad hoc to self-service
Most usable models run five levels. The names vary; the evidence does not. What matters is that each level has a test somebody outside the team could verify.
Level 1 — Ad hoc
Deployments are events. They happen out of hours, they need a named person, and the steps live in that person’s head or in a wiki page nobody has revised since the last outage. Environments drift because they were built by hand. Recovery is improvisation.
Level 2 — Repeatable
The build is automated and version-controlled, so the same commit produces the same artefact. Deployment is still partly manual, but there is a runbook, and someone other than the original author can follow it. Environments are scripted, if inconsistently.
Level 3 — Defined
Every change reaches production through one automated pipeline with gates that are enforced rather than advisory. Infrastructure is code. Rollback is a tested path, not a theory. This is where most established UK mid-market estates plateau, and it is a perfectly respectable place to stop if the business case does not justify going further.
Level 4 — Measured
Delivery and reliability are instrumented, and the numbers drive decisions. Change failure rate, lead time and recovery time are reported per service and reviewed. Alerting maps to user-visible symptoms rather than to CPU graphs. Capacity and cost are visible to the teams that create them.
Level 5 — Optimising
Teams self-serve environments, pipelines and observability from an internal platform with paved paths. Security and compliance controls are automated into the pipeline. The platform team treats developers as customers and measures its own service. Very few organisations need level five everywhere; most need it for two or three critical value streams.
| Level | Deployment | Environments | Evidence a reviewer can check |
|---|---|---|---|
| 1 Ad hoc | Manual, out of hours | Hand-built, drifted | No repeatable build; steps held by one person |
| 2 Repeatable | Scripted, human-triggered | Scripted, inconsistent | Same commit rebuilds the same artefact |
| 3 Defined | One pipeline, enforced gates | Infrastructure as code | A rollback rehearsed in the last quarter |
| 4 Measured | On demand, low ceremony | Reproducible per service | Delivery metrics reported per service monthly |
| 5 Optimising | Self-service, paved paths | Ephemeral on request | A developer provisions an environment unaided |
DevOps maturity metrics that matter: DORA and beyond
Scores are subjective; telemetry is not. Every DevOps maturity assessment should be anchored to numbers you can pull from your own systems, because those numbers are what the roadmap will move.
The four DORA keys
The DORA research programme settled on four throughput and stability measures: deployment frequency, lead time for changes, change failure rate, and time to restore service after a failed deployment. They are useful precisely because they are hard to game together — you can ship faster by skipping tests, but the failure rate exposes it within a month.
Reliability beyond the four keys
Add availability against a stated objective, the time your incident response takes to acknowledge and communicate, and the proportion of engineering time spent on unplanned work. That last one is the most honest DevOps maturity indicator in the set. When more than a third of an engineer’s week goes to interruptions, no roadmap survives, and every capability improvement you plan will slip.
Flow metrics that expose queueing
Lead time is an average that hides the interesting part. Break it into coding time, review wait, environment wait and release wait. In most assessments the code is written quickly and then waits — for a reviewer, for a shared test environment, or for a change advisory board that meets on Thursdays. Fixing the queue is cheaper than fixing the tooling.
The metrics to stop reporting
Story points delivered, lines of code, and per-team velocity comparisons tell you nothing about DevOps maturity and quietly incentivise the wrong behaviour. Retire them from the pack before you add anything new, or the reporting burden alone will sink adoption.
The bands below are DORA’s published performance clusters, simplified. Use them to locate yourself, not to set a target on day one.
How to run a DevOps maturity assessment in four weeks
Four weeks is enough for an estate of up to about eighty engineers. Longer than six weeks and the findings start ageing before the roadmap is signed.
Week 1 — evidence gathering
Pull what the systems already know before you talk to anybody. Export deployment records, incident tickets, pipeline run history, code review turnaround and change approval records for the last six months. Inventory repositories, environments and the services nobody owns. Evidence gathered first stops week three becoming a debate about whose memory is correct.
Week 2 — interviews and value-stream mapping
Interview engineers, testers, operations and one product owner per stream, separately and without their manager present. Then map one representative change end to end, wall-clock, from decision to production. The gap between the map and the story people tell is usually the single most valuable output of the whole DevOps maturity assessment.
Week 3 — scoring workshop
Score each domain against the rubric with the evidence on screen. Run it as a facilitated session with the teams in the room, because a score handed down in a report gets rejected, and a score argued to a conclusion gets defended.
Week 4 — readout and prioritisation
Present the baseline, the target and three candidate roadmaps at different funding levels. Leadership picks one. Anything you cannot name an owner for on the day does not go on the roadmap; it goes on a backlog you revisit at the next quarterly review.
| Method | Effort | Bias risk | Best used for |
|---|---|---|---|
| Self-assessment survey | Low | High — optimism and fear | Breadth across many teams, sentiment |
| Structured interviews | Medium | Medium — loudest voice | Understanding why a control exists |
| System telemetry | Medium | Low — but incomplete | Throughput, stability, review wait |
| Value-stream mapping | High | Low | Locating the queue that costs you weeks |
| External review | High | Low — but needs context | A baseline leadership will believe |
Scoring DevOps maturity without turning it into theatre
The fastest way to waste an assessment is to let it become a performance review. Scores must attach to systems and processes, never to named people.
The rubric
Score each capability from one to five, and require a specific artefact for every score above two. “We do code review” scores two. “Every merge to main requires an approving review, enforced by branch protection, and the median review wait is under four hours” scores four. Write the evidence next to the number; six months later nobody will remember why a domain scored three.
Evidence beats opinion
Where a team’s self-score and the telemetry disagree, record both and investigate rather than averaging them. The disagreement is data. A team that believes it deploys weekly while the logs show monthly is usually describing the last time a deployment felt routine, and that gap tells you where the friction sits.
Handling disagreement between teams
Different value streams will have genuinely different DevOps maturity, and forcing one organisational number hides the useful detail. Score per stream, then report the range alongside the median. A single blended figure lets a strong platform team mask a payments service that nobody can deploy safely.
Weighting for what the business actually needs
Not every domain deserves equal weight. A regulated financial service should weight security, auditability and recovery more heavily than deployment frequency. An early-stage product should do the opposite. Agree the weights before scoring, in writing, or they will be renegotiated the moment somebody dislikes a result.
The illustrative profile below is a common shape: solid delivery tooling, weak operating model and security automation. Use it as a pattern to check against, not as a benchmark.
The 12-month DevOps maturity roadmap, quarter by quarter
A twelve-month roadmap works because it is long enough to change how software is built and short enough that the sponsor who approved it is still in post. The sequence below assumes a level-two or level-three baseline, which is where most assessments land.
Q1 — Stabilise and make work visible
Do not automate a broken process. Spend the first quarter cutting unplanned work: fix the top three recurring incident causes, put one on-call rotation in place with a written escalation path, and start recording deployments and incidents consistently so the metrics mean something by Q2. Freeze new tooling purchases for the quarter.
Q2 — Automate the path to production
Consolidate onto one pipeline. Every service builds the same way, deploys the same way, and rolls back the same way. Move environment definitions into code, starting with the environment that blocks the most people. This is the quarter that moves lead time, and it is where visible DevOps maturity gains first appear on the dashboard.
Q3 — Shift quality and security left
With a single pipeline in place, gates become cheap. Add automated testing at the level that catches your actual defects, dependency and secret scanning, and policy checks that fail the build rather than emailing somebody. Pair this with a review of change approval: most boards can be replaced by automated evidence for low-risk changes.
Q4 — Platform, self-service and the operating model
Turn the pipeline into a paved path other teams adopt by choice. Publish golden templates, give teams self-service environments, and make ownership explicit for every service. Close the year by re-running the DevOps maturity assessment with the same rubric, so the delta is real rather than rhetorical.
| Quarter | Theme | Owner | Measure that must move |
|---|---|---|---|
| Q1 | Stabilise, make work visible | Head of engineering | Unplanned work below 25% of capacity |
| Q2 | One pipeline, infrastructure as code | Platform lead | Lead time for changes under one week |
| Q3 | Automated quality and security gates | Security and QA leads | Change failure rate under 15% |
| Q4 | Self-service platform, clear ownership | Platform lead | Environment provisioned unaided in a day |
What the roadmap costs and how to build the business case
DevOps maturity work competes for budget with features, so it needs the same treatment as any other investment: a cost, a benefit, and a date by which the two cross.
Where the money actually goes
Most of a twelve-month programme is people, not licences. Expect a platform lead, one or two engineers for a substantial part of the year, and a slice of everyone else’s time for adoption. Tooling matters less than teams assume; the pipeline, scanning and observability licences for a mid-sized estate are usually a small fraction of the engineering cost.
A worked example for a forty-engineer estate
Assume forty engineers and a fully loaded cost of £75,000 each. If unplanned work sits at 35% of capacity and the Q1 stabilisation work brings it to 20%, that is 15% of forty engineers — six engineer-years, or roughly £450,000 of capacity returned annually. Against a programme cost in the low hundreds of thousands, the argument writes itself, provided you measured the starting point.
The numbers leadership will ask for
They will ask three things: what does it cost, what do we get, and what happens if we do nothing. Answer the third with your own incident record rather than industry statistics. The cost of last year’s outages, the overtime, and the release weekends are more persuasive than any DevOps maturity benchmark from a vendor report. Our guidance on the technical debt audit covers how to price that side of the ledger.
Funding it without a big-bang bid
Ask for the first quarter, with the Q2 release conditional on hitting the Q1 measure. Sponsors approve smaller, evidenced increments far more readily than a twelve-month lump sum, and the conditional structure protects you from being held to a plan that the first quarter proves wrong.
Common DevOps maturity assessment mistakes
The failure modes are consistent, and every one of them is avoidable if you name it before you start.
Benchmarking against organisations you are not
Comparing a forty-engineer product team to a company deploying thousands of times a day produces despair, not a plan. Benchmark against your own last assessment. The only comparison that matters is whether this quarter is better than the last one, and by how much.
Rebuilding the platform before fixing the process
A new pipeline laid over an unchanged approval process just moves the queue. If a change waits nine days for a Thursday board, a faster build saves you minutes. Sequence the operating model work first when the value-stream map says the wait is human, and consider whether managed IT services can absorb the operational load while your engineers do the rebuild.
Treating the roadmap as fixed
Twelve months is long enough for the business to change. Re-plan the roadmap quarterly against the same rubric, and expect at least one quarter’s theme to be replaced. A DevOps maturity roadmap that has not changed all year has not been used.
Leaving the operating model unowned
Pipelines have owners; operating models frequently do not. Someone senior must own how teams are structured, how services are assigned, and how funding flows — otherwise the technical work lands and the DevOps maturity score barely moves. If you are running the assessment alongside a platform change, our cloud adoption work covers how the two sequence together.
Measuring once and never again
An assessment run once is a snapshot; run twice it is a trend; run quarterly it is a management system. Put the re-assessment in the calendar on the day you finish the first one, and hold the rubric constant so the numbers stay comparable.
Frequently asked questions about DevOps maturity
How long does a DevOps maturity assessment take?
Four to six weeks for most mid-market estates, including the readout. Anything faster is a survey; anything slower is stale before it lands.
Should we use an external assessor?
Use one when you need a baseline leadership will believe, or when internal politics make honest scoring impossible. Use internal people when you already have telemetry and a culture that tolerates bad news.
What score should we be aiming for?
For most businesses, a solid level three across the board with level four on the two or three value streams that carry revenue. Level five everywhere is rarely worth the cost.
How often should we re-assess?
Re-score quarterly against the same rubric, with a full re-assessment annually. The quarterly cadence keeps the roadmap honest without turning DevOps maturity measurement into a job of its own.
Does DevOps maturity mean we no longer need operations people?
No. It changes what they do. Operational expertise moves into platform, reliability and automation work rather than manual release and firefighting, and the strongest platform engineers are usually former operations engineers.
