DevOps is the IT industry’s attempt to fundamentally improve software development: reduce human costs such as burnout, reduce economic waste caused by incorrectly developed software and professionalize the industry as a whole. The CALMS model concretizes DevOps in five dimensions: Culture, Automation, Lean, Measurement and Sharing. Four metrics, known as DORA metrics, measure progress in a measurable way.
Key Takeaways
- The CALMS acronym (Culture, Automation, Lean, Measurement, Sharing) makes DevOps tangible and gives teams a framework for moving from abstract goals to daily practice.
- Four key figures are sufficient to measure the DevOps maturity level of a team: Lead Time for Changes, Deployment Frequency, Mean Time to Failure and Change Failure Rate.
- Whoever works at one point in the software value chain always influences the person before and after them; if this is ignored, the human and economic costs that DevOps is supposed to reduce will arise.
- In acutely stressed projects, a single small improvement, such as an automated script or a canceled pointless meeting, immediately brings tangible benefits for others in the team.
DevOps is a battle cry, not a phase model
DevOps is the IT industry’s attempt to organize its work better than it has in the past. Behind the term are practices, values, tools and instruments that are brought together under a common umbrella. Georgia König describes DevOps as a call from IT people to IT people: “The way things have been going so far, many people won’t last until they retire.
The difference to the agile movement lies in its origins. DevOps was demanded, developed and repeatedly revised by those affected. The people driving the movement came from the field, had access to the systems and not only wanted good ideas, but also solutions that could be programmed, automated and shared.
This practical approach makes DevOps a possible implementation of what agility originally wanted to achieve. Agile also emerged from software, but over the years it was taken over by process facilitators who had little to do with the systems themselves. DevOps remained closer to everyday technical life.
Why the IT industry needs DevOps at all
There are three reasons that justify DevOps: human costs, economic costs and the maturity of the industry.
The human costs are real. IT has a high burnout rate, people are suffering from their jobs. DevOps should reduce this burden.
The economic costs arise when software is developed inefficiently. Projects are scrapped, the wrong thing is built, the customer is bypassed in development, or good software never reaches the end customer. DevOps is designed to prevent money from going up in flames in this way.
The third reason relates to self-image. IT is a young industry with teething problems that older domains such as medicine have long since overcome. DevOps helps to establish a standard and to be taken seriously, beyond the old images of the basement kid or hacker kid.
CALMS makes DevOps tangible
The CALMS acronym is one of the most practical ways to concretize DevOps. It stands for Culture, Automation, Measurement, Lean and Sharing. Instead of big goals, it provides five questions that a team can work on specifically.
- Culture: What culture supports the goals to be achieved with DevOps?
- Automation: What needs to be automated to get it out of the way?
- Measurement: What numbers does the team need to make good decisions and let bad ones go?
- Lean: What do you need to focus on to get the maximum result with the minimum effort?
- Sharing: How is knowledge disseminated and accessibility shared?
Georgia uses the acronym in workshops. Participants first understand what each letter stands for and then consider what can be used explicitly. What culture do we need to create? What do we need to measure, automate, share, reduce? This is how DevOps moves from its lofty goals to everyday life.
Tomorrow’s effect counts in the current project
In projects under pressure, a DevOps intervention must not begin with weeks of downtime. Customers suffering from developer pains, whose projects are on the brink of collapse, need a result quickly.
The most useful question is therefore: What can be done in a short time that will make the next few days and weeks easier? What could be automated in an hour, just so that it’s gone? Which meeting could be canceled because it does not serve the goal? What knowledge would the team need to have access to so that a recurring problem disappears?
The benchmark is your own everyday life in the near future. You work in such a way that in a week or a month you think to yourself: Good thing I took care of that. For demoralized or resigned project team members, this quick, tangible effect is the difference between serious change and the next consultant who just brings another acronym.
Four key figures are enough to measure impact
If you want to measure the impact of DevOps, you should initially limit yourself to four key figures. 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 deploy |
| Deployment Frequency | How often a change is actually deployed |
| Mean Time to Failure | Time around failures |
| Change Failure Rate | Proportion of changes that lead to failures |
The most revealing question is often about the deployment frequency. If a team only deploys once a year because the preparation time is six months, the constructive lever is open: What would have to happen for this preparation to take only one month instead of six months?
The focus on just a few key figures is also a relief. A team doesn’t have to know all the figures and doesn’t have to screw everywhere. Even the first step of finding out your own four values is often an intervention in itself.
Dare to step on the scales, look at the number, be sad for two days, that’s completely okay, and then it’s on.
- Georgia König
The magic dashboard technique is suitable for this: What would a dashboard look like with all the numbers you ever wanted to know? Record the values, get a brief fright and then work on them.
The Wall of Confusion separates what belongs together
DevOps means Dev and Ops. The Wall of Confusion describes the wall of confusion between development and operations. It makes it clear: in every phase there is someone before and someone after, and if these people don’t talk to each other, nothing runs as fast as it could.
Nobody works in a vacuum. Passing on untested code is a burden on the tester. A tester who only reports and passes on “all green” is a burden on the company. If the company throws in the towel, the whole company suffers because the customer can’t use the product.
This leads to the community concept of DevOps. If operations employees are treated badly, the developers suffer. If developers are treated badly, it doesn’t help the company. It’s not about “us here and you there” who see each other once a year at the Christmas party. Both sides are working on the same software, they are two sides of the same coin.
The DevOps eight, the widespread phase model consisting of planning, development, testing, deployment and release, is primarily useful as a checklist. It shows that all phases have been considered, but says little about what you will actually do tomorrow to better navigate your day-to-day work. It works as a vehicle for marketing slides, but hardly as an aid against developer pains.
How to get DevOps rolling without a big budget
A single presentation or a short workshop is often sufficient as a starting point. It is crucial that each participant considers for themselves where they can translate the DevOps concepts into their own everyday life.
One example is the S for sharing. Where are you not passing on 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 being aware of your own potential for this beforehand.
The first step is therefore an impulse, not a major project: what you do in the value chain always has an effect on the person before and after you. This leads to honest questions for yourself. Are you living a culture that benefits others? Do you collect the right figures for your decisions? Do you share your knowledge in an accessible way? And are you really eliminating what is not relevant?
The biggest leverage lies in clarity about the problem. Smart people solve almost every problem when they understand what the problem is. Most of the time they just don’t know. Lack of clarity is more often the cause than lack of ability.
A culture where you are allowed to ask questions
DevOps needs a culture in which you can admit that you don’t understand something. In IT, it is often expected that the other person understands a tool immediately, is immediately familiar with it and learns everything by searching for it. If you ask, you sometimes just hear: teach yourself. That’s the end of the exchange.
That’s not a good breeding ground for openness. You don’t learn everything straight away, and sometimes you need more guidance, more explanation, more resources for good training. It should be possible to openly say “I have no idea what you’re talking about, please explain it to me” without devaluation.
This also includes having the courage to ask your line manager what actually completes a task. What is the Definition of Done? What level of improvement in figures would show that things have improved? What specific costs would have to be saved? Such questions are linked to measurement and culture, because they only work if the environment allows them in the first place.
The principle of Essing, i.e. asking openly instead of secretly searching, pays off in practice. If you say “Bring me in” at an early stage, you save yourself the trouble of poking around in secret and get the information you need more quickly.
