DevOpsGroup has joined Sourced, an Amdocs company. Read more about this partnership and what this means for the future in our blog.

The CALMS Model of DevOps

CALMS is an acronym for Culture-Automation-Lean-Measurement-Sharing and is a foundational model for DevOps. CALMS is a useful starting point to understand DevOps.

DevOpsGroup - CALMS Model
DevOpsGroup - CALMS Model Culture

What CALMS stands for

John Willis and Damon Edwards coined the acronym CAMS in 2010 which was later expanded to CALMS by Jez Humble. ​

CALMS stands for:​

  • Culture
  • ​Automation​
  • Lean​
  • Measurement​
  • Sharing​

Let’s take a look at these in turn. ​

Firstly, Culture. We have written at length in our blog on what a DevOps culture means – we even have an infographic for it but at it’s heart a DevOps culture is one that embraces change, is constantly seeking feedback in order to improve, and seeks to take accountability and responsibility, not shirk it or pass it onto other people. A DevOps culture seeks to push decision making responsibility as close to the edge (autonomy) as opposed to centralising all decision making (Command&Control).

DevOpsGroup - CALMS Model Automation


Secondly, Automation. DevOps loves automation! The everything-as-code mindset is at the heart of DevOps, regardless of the tooling you might use (Ansible, Puppet, Chef, Terrform, Cloud Formation, ARM templates etc). Google express it best in their SRE (site Reliability Engineering) website when they talk about Toil:​

“So what is toil? Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows. Not every task deemed toil has all these attributes, but the more closely work matches one or more of the following descriptions, the more likely it is to be toil:” – Google

Automation is the antidote to toil – by automating the low value toil it leaves more time for the higher value-add work. Automation should also improve repeatability and reliability in that the same taks is performed the same way every time, as opposed to manual work with can introduce high levels of variation.

DevOpsGroup - CALMS Model Lean

Lean (IT)

Thirdly, Lean (IT) – the 5 key principles of Lean are well documented and the Lean IT movement seeks to extend these concepts into the world of Information technology, and software development in particular. Key texts are Lean Software Development by Tom & Mary Poppendieck and Lean Enterprise by Humble, Molesky and O’Reilly. Lean seeks to achieve FLOW – the smooth transition of work from one “work centre” to the next, in the minimum time. Ideally with as few queues/buffers as possible.

DevOpsGroup - CALMS Model Measurments


Fourthly, Measurement. Whilst it is a truism “what gets measured gets done” (see management guru Tom Peters) DevOps seeks to take this to the next level.  The Build-Measure-Learn model from Eric Ries book “Lean Startup” identifies the key cycle, and without measurement, you can never learn or improve. So “measure all the things” is the rallying cry (and a great meme). The annual State of DevOps report focuses on 4 key measures – 2 for speed balanced with 2 for stability.

  • Lead time (for change) – how long does it take from Code Commit to Production Deployment?
  • Change Frequency – how frequently are you deploying to production? Multiple times per day? Per week? Per month? Per year?
  • Change Failure Rate – how often does a change (either the code itself or the deployment process) introduce a bug into production?​
  • MTTR – Mean Time to Repair – how long does it take you to restore service in the case of an incident?
DevOpsGroup - CALMS Model Sharing


Lastly, Sharing – a focus on breaking down silos between departments and sharing knowledge and best practice. Sharing needs to be encouraged and rewarded, and hoarding of knowledge in silos discouraged. A great way to get started is by setting up our own internal “communities of practice” around DevOps, or even hosting your own “DevOpsDays” conference for your organisation. But more than that, it is the day-to-day knowledge sharing that’s important, whether it’s writing an awesome git commit message, a helpful Github README, or writing up an entire knowledgebase article in a wiki like Confluence.  Sharing *IS* caring.

If you want to learn more about DevOps, and CALMS, our BCS Foundation Level Certificate in DevOps is based on on the CALMS model. You can sign up for classroom or online course here.

Want a high-res PDF of this?

Click here to download the full CALMS Model of DevOps PDF.

Download Diagram

Related Content

DevOpsGroup Blog Icon
What does the C in CALMS really mean? #DevOps

When we talk about Culture in the DevOps model of Culture-Lean-Automation-Measurement-Sharing (CALMS) what do we really mean?

DevOpsGroup Infographics Icon
5 DevOps Cultural Challenges Infographic

What are the top 5 cultural challenges facing organisations adopting Cloud and DevOps at scale?

DevOpsGroup Videos Icon
DevOps Culture Change Panel Discussion

Our CPO, Stephen Thair, joins a panel discussion alongside speakers from Microsoft and Nearform, where they discuss DevOps culture change.