DevOps Explained: Culture, Practices and Measurement

DevOps is one of the most used and least agreed-upon words in modern software. It appears in job titles, product names and conference themes. Yet at its core it describes something fairly simple: the people who build software and the people who run it working as one system rather than as separate camps.

Historically, many organizations split those responsibilities. Developers wrote features and handed them over; an operations group deployed and kept them running. Each side had different goals, speed for one and stability for the other, and handoffs between them were slow and often tense.

This guide explains where DevOps came from, what it looks like in practice, how it connects to agile, what the DORA research program has found, and the CALMS shorthand many people use to describe it.

Where the Term Came From

The word grew out of practitioner communities in the late 2000s. In 2009 the first DevOpsDays conference was held in Ghent, Belgium, organized by Belgian consultant Patrick Debois, and the name of that event helped the term spread. There was no single founding document; DevOps emerged as a movement of people sharing what worked.

Culture Comes First

A 2015 article by Rouan Wilsenach on Martin Fowler's site describes the primary characteristic of DevOps culture as increased collaboration between development and operations. That shows up as shared responsibility: the team that builds a service also cares about how it behaves in production, and operations specialists understand the product's goals.

The same article warns against a common mistake. Hiring a "DevOps engineer" or creating a separate "DevOps team" can simply create a new silo between the two groups DevOps was meant to join. Specialist platform or tooling roles can be useful, but they do not replace shared ownership.

Common DevOps Practices

Culture is supported by technical practices that make collaboration fast and safe. Commonly associated practices include:

• Continuous integration and continuous delivery, so changes flow through automated checks to a releasable state.
• Infrastructure defined in version-controlled files instead of configured by hand.
• Automated testing and deployment, reducing manual, error-prone steps.
• Monitoring and observability, so teams can see how their software behaves for real users.
• Blameless reviews of incidents that focus on learning rather than finding someone to punish.

How DevOps Relates to Agile

Agile methods broke down walls between analysts, developers and testers by putting them on one team with short feedback loops. DevOps extends the same thinking to deployment and operations. Wilsenach's article describes it in exactly those terms: agile removed silos inside development, and DevOps carries that further.

DevOps is also not a replacement for agile frameworks such as Scrum or Kanban. A team can use Scrum to plan and inspect its work while relying on DevOps practices to build, release and run that work safely. The two address different parts of the same flow from idea to user.

In practice, an agile team that finishes features every two weeks but waits months for a release has only half the benefit. DevOps practices close that gap, so the feedback agile aims for actually reaches real users.

The DORA Research Program

DORA, short for DevOps Research and Assessment, is a research program now run by Google Cloud. It describes itself as the longest running academically rigorous research investigation of its kind. Its early work, conducted with Puppet through the State of DevOps reports, was summarized in the 2018 book Accelerate by Nicole Forsgren, Jez Humble and Gene Kim.

DORA is best known for its software delivery performance metrics. The program originally used four key metrics and now describes five, divided into throughput and instability:

• Change lead time: how long a change takes to go from being committed to version control to running in production.
• Deployment frequency: how often deployments happen.
• Failed deployment recovery time: how long it takes to recover from a deployment that fails and needs immediate intervention.
• Change fail rate: the share of deployments that need immediate intervention afterward.
• Deployment rework rate: the share of deployments that are unplanned and happen because of a production incident.

The first three measure throughput; the last two measure instability. DORA states that its research has repeatedly shown speed and stability are not trade-offs, and that top performers tend to do well on all five.

DORA also studies culture. Drawing on sociologist Ron Westrum's typology of organizations, it reports that a high-trust, generative culture, one where information flows freely and failures lead to inquiry, predicts software delivery and organizational performance.

Using the Metrics Wisely

DORA's own guidance includes cautions. It warns against turning metrics into targets, which invites gaming, against relying on a single metric, and against comparing very different applications. The metrics are meant to be applied to one application or service at a time and used by teams to guide their own improvement, not to rank teams against each other.

The CALMS Idea

CALMS is a popular shorthand for the elements of DevOps: Culture, Automation, Lean, Measurement and Sharing. Its roots lie in an earlier acronym, CAMS. In a July 2010 blog post titled "What DevOps Means to Me," John Willis set out Culture, Automation, Measurement and Sharing as core values. Atlassian's guide to the framework credits Jez Humble with the expanded CALMS acronym, which adds Lean, the focus on flow, small batches and reducing waste.

CALMS is most useful as a conversation tool. A team can ask, for each letter, where it is strong and where it struggles. A hypothetical team might find it has excellent automation but poor sharing between developers and on-call staff, which points to a cultural fix rather than another tool.

Key takeaways

• DevOps is about the people who build and run software working as one team with shared responsibility.
• It extends agile's feedback loops all the way to production and real users.
• DORA, now run by Google Cloud, measures delivery with five metrics covering throughput and instability.
• DORA's research reports that speed and stability go together and that generative culture predicts performance.
• CALMS (Culture, Automation, Lean, Measurement, Sharing) builds on John Willis's CAMS and is a handy self-assessment lens.

Sources

• DORA, Software delivery performance metrics
• DORA, Generative organizational culture
• Rouan Wilsenach, DevOps Culture
• John Willis, What DevOps Means to Me
• Atlassian, CALMS framework
• IT Revolution, Accelerate