DevOps maturity model

A DevOps maturity model is an assessment scale that rates how well one capability works: building, testing and releasing software. It hands you a level and a next step. It scores that capability only, and it transforms nothing on its own.

Keep the scope tight. A digital maturity model scores a whole enterprise across channels, data, operations and skills, while this one looks at the path from a commit to production and nothing else.

It is also not a change programme. A DevOps transformation is the work of changing how engineering operates, where the model is only the instrument that tells you where you are standing before and after.

Levels are a communication device. Their job is to turn a pile of pipeline evidence into one sentence a board can act on — and one specific thing engineering does next.

The scale borrows its shape from the capability maturity model, which ranked software process discipline on five levels long before continuous delivery existed.

Key takeaways

• The model scores one capability: software build, test and release. It changes nothing by itself.
• Levels are only useful when each one names a specific next capability to build.
• Score with evidence from the pipeline, not from a self assessment survey.
• Reassess on a fixed cycle — a maturity level with no date on it is a souvenir.

How it works

Assessment runs in three passes: gather pipeline evidence, place each capability on the scale, then publish one level plus the single next capability to build. The level is a summary, and the next capability is the actual output.

Evidence beats opinion. Pull deployment records, test results and incident history from the tooling, because a team’s self reported level is almost always one step above what the pipeline shows.

Resist the single score. A team can sit at level 4 for deployment and level 1 for database changes — averaging those into one number hides the exact thing you needed to find.

Four measures do most of the scoring work: how often you deploy, how long a change takes to reach production, how often a release fails, and how fast you recover when one does.

DevOps Research and Assessment (DORA) publishes a catalog of capabilities that accelerate software delivery, covering continuous delivery, deployment automation, documentation quality and loosely coupled teams.

That catalog lists a generative, high trust culture and job satisfaction alongside the tooling capabilities, which surprises people who expect a maturity model to be purely technical.

The catalog matters because it is evidence based rather than invented. Google Cloud’s architecture documentation states that the DORA team has identified and validated capabilities that drive higher software delivery performance.

Two supporting numbers make the level defensible. Your automation coverage rate shows how much of the pipeline still needs a human hand on it.

The other is process cycle time, measured from the moment work starts to the moment it is live, including every wait state in between.

Set the reassessment date when you publish the level — otherwise the number gets quoted in sales decks two years after it stopped being true.

Who performs the assessment matters as much as the scale. A DevOps engineer from outside the team reads the evidence more honestly than the people who built the pipeline.

Scope it before you start when delivery is shared. In software development outsourcing, the client often owns the release gate while the provider owns the build, so score the joint pipeline rather than either half.

Examples

Retail banking. A bank with a quarterly release train scores at level 2, with the next capability named as continuous integration rather than a general instruction to move faster. That instruction is specific enough to fund.

Software as a service. A product company deploying several times a day usually scores at level 4, where the remaining work is reducing change failure rate rather than increasing frequency.

Outsourced delivery. Providers in Manila, Bengaluru and Kraków increasingly publish an assessed level in bids. The level is only credible when the evidence behind it is the client’s own pipeline data rather than a questionnaire.

Public sector. Agencies modernising legacy systems often sit at level 1 for the core platform and level 3 for newer services. Score the two separately and publish both, because one organisation wide number hides more than it reveals.

Related terms

• Software testing outsourcing: moves test execution to a partner, which affects the automation evidence an assessment reads.
• Benchmarking: compares your result against peers, where a maturity model scores you against a fixed scale.
• Capability maturity model: the older five level ancestor, aimed at process discipline rather than delivery speed.
• DevOps engineer: the practitioner who gathers the pipeline evidence and usually runs the assessment.
• Process cycle time: the elapsed measure that exposes wait states a deployment count alone will miss.

FAQ

What does a DevOps maturity model measure?

One capability: how software is built, tested and released. It reads deployment frequency, lead time for changes, change failure rate and recovery time, then places the team on a scale.

How is it different from a digital maturity model?

A DevOps model scores engineering delivery only. A digital maturity model scores the whole organisation, including channels, data, operations and skills, so the two answer entirely different questions.

How many levels should a model have?

Five is the convention, inherited from older process models. The count matters far less than whether each level names a specific capability to build next.

How often should a team be reassessed?

Every six to twelve months, on a fixed date agreed in advance. More often than that and nothing has changed; less often and the level stops describing the team you have.

Can you assess an outsourced engineering team?

Yes, provided you score the joint pipeline rather than the provider alone. Define at the start who owns the build, the test gate and the release, then assess the path end to end.

Find engineering delivery partners by country and specialism across the Outsource Accelerator provider hubs.