CALMS

The problem

Acme Shop's back-office IT department has 40 people: 22 developers who write the ERP and warehouse code, 12 operations engineers who run the servers in the company's own data centre, and a release group of six engineers who came from operations. After the shop's product teams moved to small, frequent deploys, the department wanted the same results. In January it bought a pipeline tool, and it renamed the release group the DevOps team. (Acme's numbers are the example's own, not research findings.)

Nine months later, every commit is built and tested in 12 minutes, and then it waits. A change still travels from development to the DevOps team to operations as a ticket, and everything ships in one monthly release: Release 2026.09 went out on Saturday 26 September with 41 changes. Two days later warehouse picking failed for 3 hours 20 minutes (INC-0917). The review began by asking who had deployed the change. Developers blamed a configuration change by operations, operations blamed a bad build from development, and the notes stayed in the operations wiki. The monthly IT report shows server uptime and tickets closed, so nobody can say whether delivery is getting better.

The department adopted the parts of DevOps that can be bought or renamed and left the rest alone. Nobody has looked at all of it together, so nobody can say which part is holding the others back.

How it works

Where CALMS comes from

In a July 2010 post, What Devops Means to Me, John Willis described DevOps as CAMS: culture, automation, measurement and sharing. He put people and process first and argued that automation fails without the culture to support it; he asked for measurement of performance, process and people; and he called sharing the feedback loop that closes the cycle. Writing on IT Revolution in 2012, Willis said that he and Damon Edwards had coined CAMS after the first DevOpsDays in the United States, held in Mountain View in 2010, and that Jez Humble later added an L for Lean. Atlassian's CALMS page also credits Humble with the acronym. In their August 2011 Cutter IT Journal article on why enterprises need DevOps to deliver continuously, Humble and Joanne Molesky still worked through the four CAMS dimensions, citing Willis.

CALMS is a mnemonic, not a standard. Neither Willis's posts nor Atlassian's page define levels, a questionnaire or a scoring scale, so every organisation that scores CALMS makes up its own. Acme's 1-to-5 scale in the diagram is the example's own.

The five dimensions

The dimensions depend on each other. Automation built by teams that blame each other becomes one more wall, measurements nobody shares change nothing, and small batches need the trust to release them. That's why the useful output of an assessment is the shape, and above all its lowest point, rather than an average.

A lens, not a model

CALMS tells you where to look. It is not a research instrument, and its scores are a group's own judgement. Two neighbours in this catalog are often used alongside it:

For example, DORA's generative organizational culture capability builds on the sociologist Ron Westrum's typology of organisational cultures, and DORA reports that a high-trust culture with good information flow predicts software delivery and organisational performance. Its catalog also covers work in process limits, visibility of work in the value stream, visual management and streamlining change approval, which map onto lean, measurement and sharing. The Three Ways and DORA Metrics pages cover those two in depth.

Putting it into practice

1. Put both sides in the room. Developers, operations and, where one exists, the DevOps or platform team, plus someone who owns the business process the systems support. Pick a facilitator who isn't being scored; Acme borrowed one from the shop's SRE group.
2. Agree the scale before scoring. Write down what each level means for each dimension. Acme's runs from 1 (nobody does it) to 5 (everyone does it and keeps improving).
3. Bring evidence, not opinions. The last few incident reviews, a week of pipeline runs, the release log, the team boards, the monthly report, the chat channels. A score without evidence isn't recorded.
4. Score one dimension at a time. Where development and operations disagree, write down both views and the evidence behind them: the disagreement is itself a finding.
5. Find what holds the rest back, usually the lowest dimension. At Acme, sharing (1) and culture (2) explain why a good pipeline (4) still feeds a monthly release.
6. Pick a few actions there, each with an owner and a date. Acme's: blameless postmortems shared with all 40 people (October), one on-call rota for developers and operations (November), WIP limits on every team board (December) and DORA's delivery metrics on a dashboard everyone sees (January).
7. Reassess on a schedule, with the same people and the same scale, and compare the department with its own past. Acme's second assessment, on 8 April 2027, gave culture 3, automation 4, lean 3, measurement 4 and sharing 3: reviews now ask what failed rather than who, items in progress fell from 38 to 15, the delivery metrics are read every week, and seven postmortems have been shared in one incident channel.
8. Go deeper where the score is low. CALMS points at an area; other tools examine it. A value stream map shows where work waits, DORA's Quick Check and its five delivery metrics give measurement a baseline, and DORA's How to transform guide describes the loop that follows: understand the current condition, set a measurable target, experiment, and check again, based on Mike Rother's improvement kata.

Where it fits

Team Topologies offers a way out of Acme's org chart: stream-aligned teams that build and run their own systems, and a platform team that offers the pipeline as a self-service product rather than a ticket queue. Where IT service management follows ITIL, the ITIL 4 page shows how change enablement can work with DevOps rather than against it.

When to use it

CALMS pays off where an organisation has started a DevOps adoption and can't say why it isn't working, typically after a tool purchase or a reorganisation, when the parts that were easy to buy are done. It gives development and operations one vocabulary, takes a day or less and needs no tools. It suits large and traditional IT departments, where the conversation between the two sides is often the main result.

Adapt it where the context differs:

• Regulated environments need segregation of duties and an audit trail. Score how the controls are met (automated checks, peer review, the pipeline's records) rather than whether a manual approval exists.
• Legacy and vendor systems such as an ERP limit how far automation can go and how small a release can be. Score against what the platform allows and look for the next step, not against a cloud-native team.
• Small teams don't need a day: an hour around the five letters and the last few incidents is enough.

It costs more than it returns as a benchmark between teams or companies (home-made scales aren't comparable), as a certification, or as a substitute for measuring delivery. Once a team tracks DORA's metrics and runs postmortems, a value stream map or DORA's capability catalog will tell it more than another round of scores.

Common pitfalls

• CALMS as a maturity score to rank teams. A league table of self-assessed scores teaches teams to argue their numbers up and hide problems. Keep the scores inside the group that produced them and compare it with its own past.
• Automation first, and only. Tools are the easiest part to buy, and they speed up whatever culture is already there: Acme's pipeline was its strongest dimension and changed little on its own. Start with the weakest dimension; Willis put culture first because, without it, automation achieves little.
• The DevOps team as a new silo. Jez Humble argued in 2012 that a separate DevOps team between development and operations is a poor way to fix the problems that silos cause, and Matthew Skelton and Manuel Pais's DevOps Topologies list it as an anti-type (DevOps Team Silo), next to an operations team that just hires or renames people as "DevOps engineers" (Rebranded SysAdmin). Let development and operations share the work and the on-call, and let a platform team offer self-service instead of a ticket queue (Platform as a Product).
• Measuring without sharing the results. A dashboard that only managers see changes no one's work. Put the numbers where the teams look, review them together, and use them to find the next problem rather than someone to blame.
• Averaging the five scores. Acme's average rose from 2.4 to 3.4, which hides that sharing went from 1 to 3 while automation didn't move. Read the shape and its lowest point.
• Scoring opinions. Without evidence the scores reflect the loudest voice in the room. No evidence, no score.
• A one-off assessment with no follow-up. One assessment is a snapshot: the slides get filed, and nothing shows whether the actions worked. Give every action an owner and a date, and book the reassessment before the day ends.