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 organisation’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?” by defining not what DevOps is, but rather about what DevOps is not.

DevOps is not magic

DevOps 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 they were, everyone would already be doing them. 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.

Moving to a DevOps approach isn’t pulling a rabbit out of your organisation’s proverbial hat – it doesn’t happen that quickly. Changing people’s ways of working takes time and requires senior leadership’s patience.

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 “centre 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 organisational structures.

It’s not just a new word for 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 popularised by Google in its 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 are probably 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.

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 behavioural pattern exhibited by companies that fail to execute effective change.

DevOps isn’t limited to tooling

DevOps cannot be defined through creating, say, a Jenkins pipeline to build software artefacts 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 emphasises experimentation and adjustment, while lean was originally a philosophy of manufacturing that focused on minimising waste in the production lifecycle.

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 emphasises collaboration and cooperation between traditional dev and ops functions.

Conclusion

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 endeavour 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 endeavour is a much more difficult achievement to measure. It’s in this process that organisations typically struggle to make DevOps happen.