What DevOps Is NOT

There’s no shortage of posts explaining what DevOps is—from articles that use acronyms like CALMS (Culture, Automation, Learning, Measurement and Sharing) to more thorough explanations that use the traditional division of business change analysis into “people, process, and tools.” According to this DevOps definition, people refers to an organization’s culture, its unspoken assumptions and formal rules that inform its operation. The process represents the abstract rules that govern how things get done, and tools are the pieces of technology used within those processes to achieve the company’s goals. But there’s another way to answer the question, “What is DevOps?” This article isn’t about affirmatively defining what DevOps is, but rather about what DevOps isn’t. Below, we’ll look at industry patterns that masquerade as DevOps but fail to exemplify its core principles. Because they often result in a failure to deliver expected returns, it’s helpful to know how to steer clear of them.

DevOps is not magic

The first thing to make clear about DevOps is that it is not in any way magical. Many businesses that embrace DevOps do so because it has been sold to them as some kind of shortcut to greater productivity. Things in business are never that easy. If it were, everyone would already be doing it! Any business change takes time – transitioning to a DevOps mindset is no exception, especially because it requires a significant cultural shift. 

This cultural shift can result in cosmetic changes to job titles and then substantive changes to actual job roles. Therefore, a good question to ask any company that claims to have moved to a DevOps methodology is, “How did the conversation with HR go?” 

If HR was not part of that process, then there is a good chance they haven’t achieved the key moves on a path toward a DevOps methodology. 

Consider an organization wants to make the development team responsible for the uptime of their application, move infrastructure engineers directly into development teams, or bake security into its development from the outset—all actions that are commonly taken as part of a shift to a DevOps methodology—then job descriptions would certainly be edited.

Moving to a DevOps approach isn’t pulling a rabbit out of your organization’s proverbial hat, i.e. it’s not quick. Changing people’s ways of working takes time and requires senior leadership’s patience. Commitment is needed to nurture a vineyard to the point it bears fruit.

It’s not a separate team, nor department

Frequently, companies transitioning to a DevOps culture will set up a dedicated DevOps team to deal with ‘DevOps tooling’ and ‘DevOps technologies.’ While maintaining a DevOps “center of excellence” or similarly hived-off group of people advocating DevOps best practices might sound like the way to go, this kind of isolated structure rarely delivers the changes they need.

Creating a separate team effectively creates a new silo in the name of breaking down silos—an inherently ironic strategy. Typically, the motivation behind shifting to DevOps is better integration of development and operational responsibilities. Setting up a separate team to be responsible for goals that are separate from development reiterates, even perpetuates the original problem. A key feature of a DevOps shift is having a single goal across the entire delivery team, not separate ones across different teams and organizational structures.

The separate DevOps team can also fail because it commonly does nothing more than rebrand the already-existing operations team as a DevOps team. This is the least effective method of change of all: purely cosmetic. The practices and structures that silo development and operations remain exactly as they were, and nothing is done to make company procedures more efficient.

It’s not Site Reliability Engineering

There is even less of a chance of seeing change if a team of outside engineers is hired specifically to form a “DevOps team.” These days, such teams are usually named “Site Reliability Engineering (SRE)” crews, a term popularized by Google in their SRE book. 

Again, establishing separate teams makes it even harder to foster the cultural and procedural changes that can make the DevOps process so powerful, whether it be for SREs or within your DevOps department. Unless you work at Google-level scale, this separation makes next-to-no sense. It ends up being just another way to rebrand the ops team, plus doesn’t address the root problem.

It doesn’t mean “Developers in Charge”

Another common mistake is equating DevOps with the idea that developers are now “in charge” of production. Frustration with unreliable or slow delivery can lead to the operations team being blamed. In an attempt to speed up production, companies sometimes adopt a strategy in which DevOps can be taken to mean “let the developers do what they want.”

Unfortunately, this approach also often fails to deliver the expected benefits. While there no doubt exist operations teams that lack competence or fail to work efficiently, more commonly, the constraints and demands of production delivery are insufficiently understood by management and developers alike. This lack of understanding is the real root cause of slow delivery. When developers are put in charge, development teams hit the same security, regulations, and change control challenges that operations teams have come to accept and work with over time.

“Putting developers in charge” in order to implement DevOps generally indicates that management has not worked to understand operational challenges.

There is no single DevOps playbook

Treating DevOps implementation as a playbook of tools and processes that can be applied to any business regardless of its context is another practice that fails to yield success. One example of this is some management teams’ blind and misguided adherence to the lessons gleaned from influential books such as The Toyota Way. This book makes it clear that you cannot derive rules from Toyota’s experience and use them in another business setting without first considering the change in context. 

Nevertheless, many people take the guidelines put forth in the book, such as “you must have small releases,” as articles of faith when it comes to implementing DevOps. A close reading of The Toyota Way reveals that these “rules” are not always applied by Toyota in its own factories. The company’s managers do what they need to do to achieve flow, a far more profound concept both to grasp and to put into effect.

This unthinking adherence to a playbook is also known as “cargo culting.” It is a behavioral pattern exhibited by companies that fail to execute effective change.

This isn’t limited to tooling

DevOps cannot be defined through creating, say, a Jenkins pipeline to build software artifacts or using Terraform to build infrastructure — unless other aspects of the business model have changed to work as intended within a DevOps context. You can apply DevOps methods to any tools that suit your business’s needs. 

Of course, some tools might be more suited to a DevOps style of working, so embracing them might facilitate a cultural shift. For example, Git has a distributed nature that makes collaboration through complex workflows easier (certainly more easily than does, say, CVS). But it’s also possible to use Git in such a way that subverts the DevOps paradigm by strangling it with processes or constraints antithetical to its normal use.

DevOps is not (necessarily) Agile or Lean

Another common confusion about DevOps is the idea that it can be equated to related concepts such as Agile or Lean development. DevOps is a broad philosophy of software delivery. While Agile and Lean put forth similar philosophies and principles that dovetail, they have different histories and lineages. 

Agile grew from a literal manifesto for software development that emphasizes experimentation and adjustment over the pre-planning characteristic of the more traditional waterfall methods of development. It has since grown into a set of standard practices that software development teams can use to structure their work. Lean was originally a philosophy of manufacturing that focused on minimizing waste in the production lifecycle. It has been co-opted by software development to help reduce waste in that domain.

DevOps is a broader concept than Lean and Agile. Lean and Agile are methodologies with specific goals in mind. While they also might demand change to a company’s work culture, DevOps is a more encompassing cultural movement that emphasizes collaboration and cooperation between traditional dev and ops functions.

Conclusion

We have looked at the most common patterns that result in companies’ failures to shift to a DevOps way of working. Most of these patterns stem from an unwillingness or inability to look at the people part of the business as opposed to just the process and tools parts. 

DevOps seeks to make software delivery a single endeavor carried out jointly – or really, in an integrated way – by the development and operations parts of the business. Genuine collaboration and good communication when working towards this goal can result in changes in tooling and in processes, but these changes are not sufficient. Changing the way people think about their work and breaking down silos in a spirit of genuinely shared endeavor is a much more difficult achievement to measure. It’s in this process that organizations typically struggle to make DevOps happen.