DevOps is the IT industry’s attempt to fundamentally improve how software gets built: lower human costs such as burnout, cut the economic waste of building the wrong software and make the industry as a whole more professional. The DevOps CALMS model turns this into five concrete dimensions: Culture, Automation, Lean, Measurement and Sharing. Four metrics, the DORA metrics, make progress measurable.
Key Takeaways
- The CALMS acronym (Culture, Automation, Lean, Measurement, Sharing) makes DevOps practical and gives teams a frame for getting from abstract goals to daily work.
- Four metrics are enough to gauge a team’s DevOps maturity: Lead Time for Changes, Deployment Frequency, Mean Time to Recovery and Change Failure Rate.
- Anyone working at one point in the software value chain always affects the people before and after them. Ignoring that creates exactly the human and economic costs DevOps is meant to reduce.
- In projects under acute pressure, one small improvement, such as an automated script or a pointless meeting that gets canceled, brings others on the team immediate, noticeable relief.
DevOps Is a Rallying Cry, Not a Phase Model
DevOps is the IT industry’s attempt to organize its work better than it has so far. The term covers practices, values and tools brought together under one umbrella, and the DevOps CALMS model is one of the most practical ways to make it concrete. Georgia König describes DevOps as a call from IT people to IT people: the way things have been going, many won’t last until they retire.
What sets it apart from the agile movement is where it came from. DevOps was demanded, developed and reworked again and again by the people affected. The driving forces came from the field, had access to the systems and wanted more than good ideas: they wanted solutions you can actually program, automate and share.
That closeness to practice makes DevOps a possible way to deliver what agility originally set out to achieve. Agile also grew out of software, but over the years it was taken over by process facilitators who have little to do with the systems themselves. DevOps stayed closer to everyday technical work.
Why the IT Industry Needs DevOps
Three reasons justify DevOps: human costs, economic costs and the maturity of the industry.
The human costs are real. IT has a high burnout rate, and people suffer in their jobs. DevOps is meant to ease that strain.
Economic costs arise when software is developed inefficiently. Projects get scrapped, the wrong thing gets built, development misses what the customer needs, or good software never reaches the end user. DevOps is meant to stop money from going up in flames this way.
The third reason is about identity. Computer science is a young field with teething problems that older disciplines such as medicine overcame long ago. DevOps helps establish a standard and get taken seriously, beyond the old clichés of the kid in the basement or the teenage hacker.
DevOps CALMS: Five Letters That Make DevOps Tangible
CALMS stands for Culture, Automation, Lean, Measurement and Sharing. Instead of lofty goals, it gives a team five questions it can actually work on.
- Culture: What culture supports the goals you want to reach with DevOps?
- Automation: What needs to be automated so it’s out of the way?
- Lean: What should you limit yourself to so you get the most out of the least effort?
- Measurement: Which numbers does the team need to make good decisions and avoid bad ones?
- Sharing: How does knowledge spread, and how is access shared?
Georgia uses the acronym in workshops. Participants first learn what each letter stands for and then think about what they can put to explicit use. What culture do we need to build? What do we need to measure, automate, share, cut back? That’s how DevOps moves from its grand ambitions into daily work.
In a Running Project, What Counts Is Tomorrow’s Effect
In projects under pressure, a DevOps intervention can’t start with weeks of standstill. Clients suffering from developer pain, whose projects are close to being shut down, need results fast.
So the most useful question is: what can you do in a short time that makes the next few days and weeks easier? What could you automate in an hour, just to get it out of the way? Which meeting could you cancel because it doesn’t serve the goal? What knowledge does the team need access to so a recurring problem goes away?
The yardstick is your own day-to-day work in the near future. You work in a way that makes you think, a week or a month from now: good thing I took care of that. For worn-down or resigned team members, that quick, noticeable effect is the difference between real change and yet another consultant who only brings another acronym.
Four DORA Metrics Are Enough to Measure Impact
If you want to measure the impact of DevOps, start by limiting yourself to four metrics. The DevOps literature recommends the DORA metrics, named after DevOps Research and Assessment.
| Metric | What It Shows |
|---|---|
| Lead Time for Changes | How long a change takes to reach deployment |
| Deployment Frequency | How often the team actually deploys |
| Mean Time to Recovery | How quickly service is restored after an outage |
| Change Failure Rate | Share of changes that lead to failures |
Deployment frequency is often the most revealing. If a team deploys only once a year because preparation takes six months, the constructive lever is obvious: what would have to happen for that preparation to take one month instead of six?
Focusing on a few metrics is also a relief. A team doesn’t need to know every number or turn every knob. Just finding out your own four values is often an intervention in itself.
“Dare to step on the scale, look at the number, be sad for two days, that’s completely fine, and then off you go.”
(Georgia König)
The magic dashboard technique helps here: what would a dashboard look like that shows every number you ever wanted to know? Capture the values, get a brief fright, and then work on them.
What the Wall of Confusion Is in DevOps
DevOps means Dev and Ops. The Wall of Confusion is the barrier of misunderstanding between development and operations. It makes one thing clear: in every phase there is someone before you and someone after you, and if these people don’t talk to each other, nothing moves as fast as it could.
Nobody works in a vacuum. If you hand over untested code, you burden the tester. If you’re a tester who just reports “all green” and passes it on, you burden operations. If operations throws in the towel, the whole company suffers, because the customer can’t use the product.
That’s where the community idea of DevOps comes from. If operations staff are treated badly, developers suffer. If developers are treated badly, that doesn’t help operations either. It’s not about “us over here and you over there,” two groups who see each other once a year at the holiday party. Both sides work on the same software. They are two sides of the same coin.
The DevOps infinity loop, the popular phase model with phases such as planning, development, testing, deployment and release, is mostly useful as a checklist. It shows that every phase is being thought about, but it says little about what you’ll actually do tomorrow to make your working day better. It works as a vehicle for marketing slides, hardly as help against developer pain.
How to Get DevOps Rolling without a Big Budget
A single talk or a short workshop is often enough to get started. What matters is that every participant works out for themselves where they can translate DevOps concepts into their own daily work.
Take the S for Sharing. Where are you holding back knowledge that would help others in the same boat? Even small changes can remove a stressor for the next person in the chain, without you having been aware of that potential before.
So the first step is a nudge, not a major project: what you do in the value chain always affects the person before and after you. From there come the honest questions to ask yourself. Do you live a culture others benefit from? Are you capturing the right numbers for your decisions? Do you share your knowledge in an accessible way? And do you really cut what isn’t relevant?
The biggest lever is clarity about the problem. Smart people can solve almost any problem once they understand what the problem is. Most of the time, they just don’t know. A lack of clarity is more often the cause than a lack of ability.
A Culture Where You Can Ask Questions
DevOps needs a culture where you can admit you don’t understand something. In IT, people are often expected to understand a tool right away, get up to speed instantly and teach themselves everything on the side with a quick search. Ask for help and you sometimes just hear: figure it out yourself. That’s where the conversation ends.
That’s not fertile ground for openness. Nobody learns everything at once, and sometimes it takes more guidance, more explanation, more resources for good training. Saying openly “I have no idea what you’re talking about, please explain it to me” should be possible without being looked down on.
It also takes the courage to ask your manager what actually completes a task. What’s the Definition of Done? What level of improvement, in numbers, would show that things got better? Which costs specifically need to be saved? Questions like these connect Measurement with Culture, because they only work if the environment allows them in the first place.
Asking openly instead of searching around in secret pays off in practice. If you say “Loop me in” early on, you skip the covert poking around and get to the information you’re missing faster.
Frequently Asked Questions
What distinguishes DevOps from the agile movement?
DevOps was demanded, developed, and continually refined by the people directly involved. The driving forces behind it came from the field, had access to the systems, and wanted solutions that could be programmed, automated, and shared. Agile also emerged from the software itself, but over the years it was taken over by process consultants who had little to do with the systems. DevOps remained closer to day-to-day technical work.
What are the benefits of DevOps beyond faster releases?
Three reasons justify DevOps: human costs, economic costs, and the maturity of the industry. The IT sector has a high burnout rate, and DevOps is intended to alleviate this strain. Economically, the issue is that projects get scrapped, development proceeds without customer input, or good software never reaches the end customer. Third, a standard helps this young industry be taken seriously.
What do the five letters of CALMS stand for?
CALMS stands for Culture, Automation, Lean, Measurement, and Sharing. Each letter becomes a working question: What kind of culture supports the goals? What needs to be automated so it’s out of the way? What metrics does the team need to make good decisions? What should we limit ourselves to? How are knowledge and access shared? This brings DevOps from abstract goals into everyday practice.
Where do you start in a project that’s already under pressure?
With a small step that will make a noticeable difference in the next few days, not with weeks of downtime. Useful questions: What could be automated in an hour, just to get it out of the way? Which meeting could be canceled because it doesn’t serve the goal? What knowledge would the team need access to in order to eliminate a recurring problem?
Which metrics show whether DevOps is making a difference in the team?
Four are enough: Lead Time for Changes, Deployment Frequency, Mean Time to Recovery, and Change Failure Rate, known as DORA metrics. Deployment frequency is particularly revealing. If a team deploys only once a year because preparation takes six months, there’s clearly room for improvement. Simply tracking these four metrics often acts as an intervention in itself.
What happens when development and operations don’t communicate with each other?
Work slows down more than it should, and the burden gets passed along. Anyone who passes on untested code puts a strain on the tester. Any tester who simply reports “all green” puts a strain on operations. If operations give up, the entire company suffers because the customer cannot use the product. No one in the value chain works in a vacuum.
Does the well-known DevOps phase model, the infinity loop, help in everyday work?
Only to a limited extent. The DevOps “infinity loop” (with phases such as planning, development, testing, deployment, and release) works best as a checklist: it shows that all phases are being considered. But it says little about what you’ll actually do tomorrow to better navigate your day-to-day work. It works as a vehicle for marketing slides, but hardly as a tool to alleviate developer pain.
Why is it difficult for IT teams to ask clarifying questions?
People are often expected to understand a tool immediately and to teach themselves everything on the side through search queries. When someone asks for clarification, they sometimes hear nothing more than: “Figure it out yourself.” And that’s the end of the conversation. A sustainable culture includes being able to say, without feeling belittled, that you don’t understand something, and asking your supervisor what actually constitutes completing a task.
