CALMS is an acronym standing for Culture-Automation-Lean-Measurement-Sharing and is a foundational model for DevOps. CALMS is a useful starting point for understanding De
John Willis and Damon Edwards coined the acronym CAMS in 2010 which was later expanded to CALMS by Jez Humble.
CALMS stands for:
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).
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.
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.
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.
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.
Click here to download the full CALMS Model of DevOps PDF.Download Diagram
When we talk about Culture in the DevOps model of Culture-Lean-Automation-Measurement-Sharing (CALMS) what do we really mean?
What are the top 5 cultural challenges facing organisations adopting Cloud and DevOps at scale?
Our CPO, Stephen Thair, joins a panel discussion alongside speakers from Microsoft and Nearform, where they discuss DevOps culture change.