Welcome to the relaunch of the Agile Austin blog! Dan Zentgraf and I organize the Agile Austin DevOps SIG. DevOps is a new term, and we get a lot of questions about “what is DevOps anyway?” I thought I’d take a crack at bringing some clarity to this still-evolving term.

Defining DevOps, much like defining Agile, can become a contentious topic. As you have new people discovering the term and trying to make sense of it, you have early adopters wary of attempts to “dilute” or “cash in” on the term. Many pixels have been spilled over debating what “is” or “isn’t” DevOps.

Most of the confusion is in trying to define a very wide field in a single sentence; it’s like trying to define “science” or other wide ranging fields.  I like using a parallel method to define DevOps to the method often used to define Agile.  In Agile software development, there are different layers of what “Agile” is.

  • Agile Values – top level philosophy, usually agreed to be embodied in the Agile Manifesto.
  • Agile Principles – generally agreed upon strategic approaches that support these values.  The Agile Manifesto cites a dozen of these more specific principles. You don’t have to buy into all of them to be Agile, but if you don’t subscribe to many of them, you’re probably doing something else.
  • Agile Methods – more specific process implementations of the principles.  XP, Scrum, your own homebrew process – this is where the philosophy gives way to operational playbooks of “how we intend to do this in real life.” None of them are mandatory, just possible implementations
  • Agile Practices – highly specific tactical  practices that tend to cluster with agile implementations.  None are required to be agile but many agile implementations have seen value from adopting them. Standups, planning poker, backlogs, all the specific artifacts a developer uses to perform their work.

The DevOps community, as it is still new, has not necessarily come to as nuanced a definition yet and therefore argues a lot about labeling. “You can’t put ‘DevOps’ on a tool!” people cry. While it’s true that a tool can’t grant you DevOps (or Agile) values or principles, a poker planning tool like planningpoker.com can be called an Agile tool in that it’s a tool that implements a specific Agile practice.  “You can’t say poker planning is Agile!” is both true and false, given that enough words have been omitted from that sentence to cause it to make no sense. You’ll find people arguing over whether you can put DevOps on a job title, on an org chart, on a tool, on a process…

Let’s cut through the theory wrangling, therefore, and define DevOps. DevOps is the joining of two different primary goals – that of driving collaboration across the entire system lifecycle as well as adopting a newer set of more flexible tools and practices designed to generate rapid and flexible response.  In a certain sense it can be seen as simply extending Agile principles beyond the boundaries of “the code” to the entire delivered service. In Patrick Debois’ view (he coined the term DevOps in 2009), it arose as a reaction against the silos and inflexibility that were resulting from existing practices, which probably sounds familiar. Here’s a good piece on the history of the DevOps movement that deconstructs the threads that came together to create it. But anyway, on to defining DevOps in a similar hierarchy as we’ve defined Agile.

  • DevOps Values – I believe the fundamental DevOps values are effectively captured in the Agile Manifesto – with perhaps one slight emendation to focus on the overall service instead of simply “working software.” Some definitions of DevOps, like Alex Honor’s “People over Process over Tools,” echo basic Agile Manifesto statements.
  • DevOps Principles – There is not a single agreed upon list, but there are several widely accepted attempts – here’s John Willis coining “CAMS” and here’s James Turnbull giving his own definition at this level. “Infrastructure as code” is a commonly cited DevOps principle. I’ve made a cut at “DevOps’ing” the existing Agile manifesto and principles here. I personally believe that DevOps at the conceptual level is mainly just the adaptation of Agile to include systems and operations instead of stopping its concerns at code checkin.
  • DevOps Methods – Some of the methods here are the same; you can use Scrum with operations, Kanban with operations, etc. (although usually with more focus on integrating ops with dev, QA, and product in the product teams). There are some more distinct ones, like Visible Ops-style change control and using the Incident Command System for incident reponse.
  • DevOps Practices – as with Agile, there are a long list. Continuous integration and continuous deployment, “Give your developers a pager,” using configuration management tools, metrics and monitoring schemes… Even using virtualization and cloud computing is a common practice used to accelerate change.

In the end, DevOps is a little tricky to define, just like its big brother Agile. But it’s worth doing. When left at the pure philosophy level, both can seem like empty mom-and-apple-pie statements, subject to the criticism “You’re just telling me ‘do my job better,’ duh…” But conversely, just the practices without the higher level guidance turn into a cargo cult. “I do what this Scrum book says so I’m doing Agile” is like “I’m using Chef so I’m DevOps right?” To be a successful Agile or DevOps practitioner is to understand all the layers that explain what it is, what it might be, and what a given implementation might contain or not contain. In the end, what DevOps hopes to bring to Agile is the understanding and practice that software isn’t done until it’s successfully delivered to a user and meets their expectations around availability, performance, and pace of change.