The DevOps Ladder

The now (in)famous Joel Test asks 12 questions to determine the maturity of an organisation. Nearly 2 decades later the development ecosystem has evolved and many practises and techniques have become commonplace.

The DevOps Ladder is an attempt to document the best practises in the form of an information radiator that provides a guided path for continous improvement.

The vertical (Capablity) ladder includes 10 steps that are required throughout a project or product’s lifecycle. The horizontal (Maturity) ladder has 4 levels or steps. The goal of any project should be to implement all capabilities and then move them to of Level 1 ASAP.

Climbing Styles

Adding a capability or improving the maturity level is called climbing the ladder, There are many styles of climbing:

With a combination of styles being common:

Anti Patterns

Many DevOps and “agile” anti-patterns are highlighted by the outliers.

The Ladder

Capability Underwater Level 1 Level 2 Level 3
Plan/SDLC Adhoc/Email Jira
Github IssuesIssues
Kanban Scrum SAFe
Source Code Shared Drive / Zip SVN Git Branching Strategies e.g.
Git Flow
Trunk Based
Build Manual / IDE Snowflake Phoenix Reproducible Builds
CI None Nightly Per Commit / PR - Matrix
- Epemeral testing instance per PR
Test Manual Integration OR Unit Testing Integration AND Unit Testing - Fuzzy Testing
- Matrix
- Downstream
Code Review None Pair Programming
Code Review
Static Analysis - Security scanning
- Dependency scanning
- Architecture compliance
Deliver Shared drive / FTP Artifact Repository versioning strategy e.g. semver feature toggles
Deploy Using a checklist 1-step to production Manual release strategies e.g. canary or blue/green Automatic rollout strategies based on business metrics e.g. using Spinnaker
Run   Snowflake Phoenix Run offline
Docs   Getting Started / README Architecture Decision Records - Playbook
- Cultural Manifesto


Every team and project’s ladder should be unique - which levels you are targeting will reflect the architectural decisions and trade-offs being made.

Mature ladders will have most if not all capabilties at Level 2 and a few at Level 3 - but never everything at Level 3. If everything is at Level 3 you are not stretching yourself - reconsider what L3 means for you. e.g. If you are already conducting code reviews then maybe stretch to having the reviewers automatically selected by git history or an OWNERS file - There is always something more you can do.

One or two L1 capabilties may also be OK on a mature ladder. e.g. Open Source projects rarely have planning above issue tracking - there is nothing inherently wrong with that. Likewise your deployment target may be very static and a L1 CI system is sufficient.

More Reading