DevOps is a culture, but here’s why it’s actually not

Source –

When we heard about DevOps for the first time, some of us imagined it was a buzzword that would disappear like many a hipster phenomenon. The fact that we still talk about DevOps every day and have for more than five years, proves it is not just a buzzword, but a necessity for the software industry.

What’s hard about DevOps is its adoption. Even as many companies have become DevOps unicorns, such as Google, Amazon, Facebook and Netflix, others continue to struggle. There are many reasons, including human factors, a company’s size, a conservative environment and finances. But there is also this belief that DevOps is a culture. When we reduce DevOps to a culture, we diminish, somehow, the importance of the tools and the technologies in this growing ecosystem. But those who focus only on technical aspects like CI/CD will surely also find difficulties in introducing the desired change.

The big debate between “DevOps is a culture” and “DevOps is a technology” has become fruitless. Both culture and technologies are required. But we need much more than this. We need more practical approaches. We need standards.

What can Facebook teach us about DevOps?

To really understand how DevOps should work, look at the evolution of social networks. Sure, they are mainly technologies and have also changed our culture. Facebook and Twitter changed the way we communicate, but MySpace, on the other hand, didn’t have the same impact. Why is that?

Facebook — the product as well as the technology — was designed in a way that maximized its impact on users. FaceBook changed our habits. The product was tied to our human nature and our culture, which made it easy to use its tools spontaneously. If we consider this analogy, we could conclude that DevOps is a culture and a technology, and that both sides are important in DevOps adoption.

How is adoption going, by the way? According to the yearly — in this case 2017 — “State of DevOps Reports,” from Puppet and the DevOps Research and Assessment team, it’s going something like this:

  • Sixteen percent of the respondents identified themselves as working in DevOps teams in 2014.
  • Nineteen percent of the respondents identified themselves as working in DevOps teams in 2015.
  • Twenty-two percent of the respondents identified themselves as working in DevOps teams in 2016.
  • Twenty-seven percent of the respondents identified themselves as working in DevOps teams in 2017.

Most importantly, 90% of these teams work in medium- and high-performing IT organizations.

Even with the paradoxes and the limitations of a dedicated DevOps team with the resultant DevOps silos, the numbers show that DevOps works in most cases. DevOps has grown and more and more companies keep adopting it.

Shift to a standards approach

For DevOps to continue to grow, though, we must put the idea that DevOps is a culture aside. That is simply not sufficient and can cause a take everything or nothing approach. DevOps is a transformation process and a collaboration philosophy, and this particular definition comes with different approaches and different criteria for success. It is time to set up standards to help people imagine practical goals and adopt new norms we can all share.

Instead of an all or nothing approach, standards unify people and organizations around unique goals that are independent from the used technology, the team size, priority or any other criterion. Setting up standards can also be an iterative process. Take time to think through and grow standards that can continuously shape the interaction between developers, ops, code and servers. And make sure these DevOps standards give the different stakeholders the time to experiment, learn and provide feedback.

The 12-factor apps, cloud native or Consortium for IT Software Quality standards are some good examples to follow and consider for iteration. Shift DevOps-is-a-culture thinking to the idea that we can break down complex goals into a number of well-specified, pragmatic and logical objectives without creating conflicts between teams and priorities.

Organizations can switch to DevOps in several ways. The definitions are less important than the adoption path and this path should start from where your teams are today. Don’t feel the need to impose one model or another. Just set up standards that will help change the technical practices, the attitude and the mindset.

Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments
Would love your thoughts, please comment.x