“DevOps” it’s about automation, right?

Let’s clear up some common misconceptions.

It isn’t easy to put your finger on exactly what DevOps is, and searching on Google often results in more questions than answers. In this post, I demystify what DevOps is and what it means for your work life.

Let’s first get rid of some misconceptions. DevOps is not:

• about automation
• about operations (or development)
• something developers do
• a team in the organization
• an alternative to Agile

Indeed, some of these components are related to DevOps, but we tend to miss the point if we focus on them. So, if you are looking for a simple way to navigate what DevOps is about, here is my take:

DevOps means

we collaborate to improve how we build software

No principles or tools are necessary to say that we “do DevOps.” But when we collaborate more closely, we often discover new improvements that were invisible or impossible to us before. These improvements may involve automating something or adopting new tools. Tools and automation are part of DevOps in the same way that getting to your destination is part of driving. Therefore there is also no “core DevOps.” It is all about building software better.

The name “DevOps” is formed by pulling together Development and Operations. However, the concept goes far beyond those two groups. In modern DevOps, we do not constrain our focus to Dev and Ops. Instead, we look for beneficial collaboration anywhere; Ops and Git, Sec and Dev, UX and Arch. Collaborating across the value chain is not a new idea; it is what the Definitive Scrum Guide calls “cross-functional teams.” Close collaboration between everybody needed to deliver the product.

The most significant cultural shift comes from asking the question, “can we solve this issue by collaborating with the right people?” Usually, the answer is “yes.” Everyone in the organization should ask this question, not just developers. When we discover a barrier, we should try to sit down with the people we believe are causing it. Once we understand their context and they understand ours, we can begin to look for solutions that work for everybody. When we do this, some problems may turn out to be entirely imagined.

During a transitional period, we may need someone to help initiate or facilitate this collaboration. There may be a dedicated team to address this responsibility. But crucially, this is a temporary installment. Such a team should build the foundation that makes collaboration a tool with which we are comfortable. To help break the curse of “business as usual.” And to make sure it leads to a culture of continuous improvement.

“Being DevOps” does not happen suddenly. And the benefits are not promised. Therefore we need to perform many experiments to find out what works in your context. To make this feasible, we need Agile. Agile is about making smaller and smaller experiments and adjusting based on their outcomes. Some might call this PDCA. Whatever the name, it is hard-wired into DevOps. Being Agile is a requirement to beginning a DevOps journey. Instead of making multi-month roadmaps, we ask: can we try this thing next week? This week? Today? And start learning — and improving — sooner.

I am passionate about DevOps, but I am also passionate about technical excellence, and if you are too, you should consider reading my book: