Getting Devops right isn’t easy. It’s downright hard. I am not going to explain here, how to “do” DevOps in your organization, because there is not just one “right” way to do it. Here I would like to share some misconceptions—call them antipatterns—of DevOps.

Being an Agile Coach and a DevOps Consultant, I have worked closely with many MNCs to help them with Transformation. Here, I am sharing some observations from these experiences to help you make the best DevOps experience and save you from going wrong on DevOps. I hope, after reading this, you will have a basic understanding of how (not) to do DevOps and what exactly does it mean to be DevOps-enabled.

DevOps helps with Innovation

It is a known fact that an organization’s success depends on its ability to innovate quickly, repeatedly, and consistently. This encompasses an all-inclusive change from improving the way a business engages its customers to increase workforce effectiveness. Digitisation enables businesses to reinvent themselves as they discover new and radical ways of acquiring customers while adding incremental value.

But innovation is not just about adopting or revamping technology. Investing in people and their practices matter even more. Organizations need to discover how these interconnected forces can impact culture, influence collaboration, and spur innovation in a competitive market. They must first understand the difference between doing something and doing the right thing.

That is where DevOps comes into the picture with an immense influence on innovation, and how adoption challenges are causing some organizations to struggle with embracing change.

As per the State of DevOps Report by Puppet Labs, “High-performing IT organizations experience 60X fewer failures and recover from failure 168X faster than their lower-performing peers. They also deploy 30X more frequently with 200X shorter lead times”.

To stay ahead of the competition, businesses will need to establish scalable teams designed with agility, velocity, and innovation capabilities, which are the common traits displayed in teams that embrace DevOps practices. High-performing teams are characterized by their ability to deliver and maintain a high degree of software performance.

A quick look back at the origin of DevOps

Originating from the desire to improve collaboration between Development and Operations, DevOps (hence the name) is fundamentally a transitive concept designed to accelerate software delivery through collaboration, and concurrently keep quality and security intact. Neither the concept of automation nor the frustrations of siloed mentality are new. This stretches way back before Patrick Debois started championing for change in 2009, after experiencing the “wall” between these two traditionally opposing units.

At the time, he was inspired by an O’Reilly Velocity conference presentation: 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr.To have fully shared responsibilities between Development and Operations, and eliminate “hand overs, no longer my concern” mentalities between units along the value chain, DevOps encourages nothing but everyone’s end-to-end commitment. Unfortunately, this motivation is lost to some adopters, who simply view DevOps as using a certain set of tools.

Using Ansible or Puppet or Docker or Jenkins or other tools does not mean you are “doing DevOps.” The tools are not DevOps, they merely enable it.

Some are even confused and cannot distinguish between DevOps, Continuous Integration, and Continuous Delivery (CI/CD). While CI/CD is definitely a key practice, the scope of DevOps is larger than that.

DevOps is more than CI/CD

As you may know, Continuous Integration (CI) and Continuous Delivery (CD) is all about building and testing the software while Continuous Deployment (CD) is getting your stuff into Production. Although they integrate and deliver software, CI and CD are neither the primary nor the holistic answer to an organization’s collaboration challenges.

As per an article written by Gartner, Through 2023, 90% of DevOps initiatives will fail to fully meet expectations due to the limitations of leadership approaches, not technical reasons.

The key to avoiding this very common mistake is to simply refrain from thinking “tools-first,” as this usually leads to a cascading effect of building platforms, integrating tools, and automating aimlessly to fulfill the DevOps development and delivery lifecycle. The intent of implementing tools is first and foremost, serving as enablers to sharing, and this motivation sets up the underlying premise for collaboration.

You don’t need a central DevOps team

I have noticed that in some organizations, they have the Dev team and the Ops team and they put the DevOps team in between. Please don’t do that, because DevOps is about removing those Silos, not about adding more.

Devops is more about shared responsibilities. It’s not about building the stuff together and at night running away assuming the Ops guys will fix any issues in production. If it’s your commit that caused the trouble, you get out of your bed and fix it. And this should go both ways. By doing this next time before the commit you will think again, if you wanted a good sleep. So you should make sure the stuff you build is solid and will not fall out overnight or during the day.

DevOps is not just for Developers and Operational Engineers

Just as the name specifies, it’s not just a combination of Dev and Ops, Everyone is in. In fact, the whole team is in. Especially the testers, because the testers can really help.

There is an awesome talk by Ioana Serban about TestOps. She explains her role as a tester in a DevOps-enabled team and how she engages in Performance testing, Security stuff etc, which really touches the Operation side of things. In fact the team should have a shared responsibility in terms of the availability of the application and its functionality in production.

I have even seen in some mature organisations where Testers do the Production Deployments. They would know which button to press and which release to deploy. They could go to tools like Kibana to view production logs to see whether an error from the previous release has been resolved in the new release etc. Because most of these work by pressing or triggering a button in tools like Jenkins.

Containers, Microservices and the Cloud. Do you really need those to be DevOps?

Of course not. It’s not about technology. It is more about collaboration and culture. You can even do DevOps with old-fashioned servers if that gets you things faster within your expectations.

Devops is not just about automating things. I agree automation helps, but it’s not the main goal of DevOps. It certainly helps to give energy to things that were slow, but it’s not a main goal. It’s important, that’s it.

And as I said before, Devops is not just about tools. But it helps a lot when you automate stuff which enables us to reach the market even faster. Let me tell you one quote which I have heard somewhere: “A fool with a tool is still a fool!”

DevOps is not a Job Title

I know seeing this many of the ‘Certified Devops’ people would be frowning. Let me tell you guys it is always good to learn something, but sorry if I am going to hurt your feelings.

Devops is more like the way of working, a culture we need to adopt and am sure we are all DevOps-certified. Because we learned how to work together, how to communicate, how to collaborate, how to cooperate, how to play together … In Kindergarten. So congratulations you are all DevOps-certified years ago even if you don’t know. DevOps is not just a Job Title that you can be certified with.

DevOps doesn’t replace Agile

If you ask me if Agile and DevOps are two different things, let me remind you that Agile is not just for Software Development. Agile is the way of working by knowing its value and DevOps helps in having a broader goal when you become agile in the context of Software Development.
Defining Devops for your organisation is important.

It’s really important that everyone in your organisation should have the same understanding in terms of what Devops means to their organisation. I have seen many organisations not doing this and I have seen them regret that.

In a conversation I heard somewhere, a CTO was explaining about one of his Project Managers complaining to him saying, “I don’t want to do stuff for DevOps, I want DevOps take care of my team, I want Devops service the team” and the CTO was going mad and started shouting at him. And later when he shared this story with his friend, he asked one simple question to him: “Did you explain it to him?” And then he realized who was wrong. He didn’t explain to the team, ‘What are we going to do’ and ‘Why are we doing it this way’ and ‘What are the benefits we will get out of it?’. Moving to DevOps is a change process and you need change management.

You cannot enforce DevOps so easily as you cannot enforce cultural change. You are changing the way people work, you are changing people’s responsibilities ,you need to change the way they think or the way they approach a problem. And not everyone will be happy with change.

If you ask your employees, “don’t we need a change everyone will say yooo, Yeah!” and if you ask them “Who is ready to change the response” is not gonna be as you expect. So it’s really important that you explain to your people what are you going to do and why are you doing it this way and what are the benefits you will get out of it so that everyone knows it well and has the same understanding.

DevOps will not prevent all your failures

DevOps actually embraces failures because failure is where you learn from. Every failure is a learning opportunity to get better, to learn how (negative) stuff happens and how you can prevent it from happening next time or make it even better.

I’ve heard about companies that order a cake when they fail. The bigger the failure, the bigger the cake would be. :) I have heard people asking questions like “What’s the role of a Project Manager/Scrum Master in a Devops enabled team?” I think one of their roles is to create an environment where failure is Ok to happen. For Eg. If there is something wrong happening in the production environment and if it is not getting noticed by the end users, it’s still ok that we act fast and fix it asap so that we learned something out of it without having much bigger impact.

I have noticed a practice of finding someone to blame when failure happens. Something breaks and you form an investigation team to find out who broke it and start humiliating him/her to make sure they never do it again. I don’t think that’s fair because I always think about doing something as a team. When something breaks, the team is responsible. Somebody coded it, somebody reviewed it, somebody tested it, somebody approved it and maybe somebody deployed it. When all these people are involved in this process, why blame just one.

So don’t look for someone to blame. Try to find a way to fix it and try to find out how we can do it better next time so that next time you will be fine. And if not next time, the time next to it. This ensures that you are continuously learning and improving.

I think we can break it down to 3 things

1) DevOps is about Culture: It’s about reinforcing culture with technology and vice versa. It’s about collaboration, cooperation, and communication. It’s about being agile and having an agile mindset and continuously waiting to improve yourself. It’s about creating a healthy engineering culture.

2) DevOps is all about Freedom and Responsibility: Freedom is cool and the price you may need to pay for that freedom is Responsibility. You build it, you run it, and if something bad happens you fix it or ask help from the team and be with them to make it work. So take responsibility, trust your teammates and design a system in which people are comfortable doing things and learning stuff.

3) DevOps is about Empathy: Empathy is about placing yourself in someone else’s position. Think about his/her feelings about what’s happening at that moment. As a developer, it can be very healthy to have empathy for the operations side of things. As an Operations Engineer, it can be very healthy to have empathy for the development side of things and as both parties have empathy on the quality side of things. Empathy is one of the most important characteristics that people need to have to succeed in a DevOps environment.

So when you do Devops you may automate the work, giving a shit about your job enough to learn all the parts, not just a little one. Empathy allows you to view all the teams as enablers rather than as blockers. So be likeable, be approachable and get stuff done! Go give a kick to yourself and start being Devops!

An organisation’s innovation potential is influenced by its ability to develop and deliver quickly. While DevOps adoption has increased significantly in recent years, it is important for organisations to remain vigilant on the common pitfalls and we have identified cultural and misguided practices as dominant obstacles.

Conclusion

Our approach and strategies, when coupled with the right motivation, can play a pivotal role in accelerating transformation by establishing a solid foundation necessary to catalyse and sustain change. Organisations will observe smoother transition through various stages of their transformative journey. They’ll see some tangible outcomes from DevOps practices, leading to better alignment with business vision, closer collaboration, shorter release cycles, and a culture of continuous learning.

Feel free to have a talk with one of our Devops experts or get in touch with your queries at [email protected]