6 Reasons Why DevOps Transformations Fail
Introduction
DevOps is the hottest buzzword in the world of service delivery. More and more organizations are jumping onto the DevOps bandwagon in the hope of transforming their broken product delivery pipeline. And yet, not many people know what exactly DevOps is.
Is DevOps about technology? About process? About people? What does it mean to go through a DevOps Transformation?
Founders of DevOps coined the acronym “CAMS” to describe the aspects of DevOps – “Culture, Automation, Measurement, and Sharing”
In my experience, I find that most organizations trying to introduce DevOps into their functioning go wrong when changing the “Culture” aspect of “CAMS”.
In this post, we’ll look at the common reasons why most DevOps transformations fail to meet the required objectives.
Creating a DevOps Transformation team
The first step usually taken by most organizations is to create a new department in which everyone works using DevOps strategy. This is a misguided approach and is the opposite of the recommend DevOps principles.
The objective of DevOps is to stop teams working in their own silo, to get everyone working together to streamline the development process. Instead, by creating a new DevOps team or department, it ensures the creation of yet another silo within the organization and adds to the red tape that is already hindering efficient working environment.
Cross-departmental collaboration is needed for DevOps to succeed, building new silios is only going to make matters worse.
DevOps is not a set of tools
When the management decides to implement DevOps practices in the organization, it usually means that they expect the technical department to change their work process and use new tools.
Technical people love new tools and are always on the lookout to introduce them in their work. More often than not, this leads to installation of tools that introduce automation and measure metrics.
Yes DevOps needs tools, but tools do not make up DevOps in its entirety.
Unfortunately, neither the management nor the technical teams realize that DevOps requires you focus differently from the start. It needs a change in the way everyone thinks, interacts and works, in order to truly gain the values that DevOps promises.
Not just Devs and Ops DevOps
is not just about Dev teams and Operations team. All the stakeholders involved in creating the product must be involved right from the beginning. This includes roles across the organization such as business folks, developers, operations teams, security teams, QA and everyone else involved in getting the product out of the door.
DevOps is a philosophy of collaborating with everyone involved, specific roles and titles of people do not matter. In that sense, successful DevOps needs the overall culture of the organization to change. Everyone involved in the delivery of the product is part of DevOps.
I have seen many companies get this fundamental aspect wrong and consider that DevOps is only an IT initiative. Many instances of such are to be found on the job portals where companies advertise for a role with a statement such as “DevOps Engineer needed with 5 years experience”. There is no “DevOps Engineer”, there is only a “DevOps culture”.
Role of Business owners in a DevOps Transformation
Business owners or Product owners are required to meticulously come up with requirements that precisely map out how business requirements and customer priorities relate. It is not unusual to also provide a delivery date to the customer along with detailed documents of what would be built for them.
When customers and business owners are happy, these requirements would be handed off to software engineers. The implementation could take a few months and includes carefully planned and estimated times for the code to be complete and for the testing to be carried out.
All that changes with DevOps. Previously the business owner spent all their time with clients and business stakeholders, hardly talking to the engineers who would build what was asked for. Now with DevOps, they are needed to work closely with engineers and determine how and what they can and can’t build.
The shift from long-term planning to short bursts of activity in sprints, expediting feedback from customers after each sprint, and repeating this cycle is a major change for organization as well as customers. Involve business units in your DevOps planning and implementation.
Not embracing a culture where failure is tolerated
People and organizations are resistant to change. They display even more disdain towards failure. Fear of failing is hard-wired in most of us.
Acceptance that something has gone wrong is the first step towards meaningful progress. Without analyzing the failures and learning from them, organizations are doomed to repeat the same mistakes over and over again. Clarify to your team that failure is not always a bad thing, and they won’t get reprimanded for it.
The same philosophy is also laid out in the Phoenix project – the famous resource on DevOps about a software company in trouble. A culture that fosters continual experimentation, taking risks and learning from failure is well suited to DevOps.
Top Down or Bottom Up?
Should the DevOps be initiated Top Down and Bottom Up?
DevOps initiatives from Bottom Up falter when they try to enforce the same outside their silos (e.g. Dev dept trying to get Ops involved). In large organizations with many political entities, changing how other teams work is almost impossible without any political clout from senior management.
The bottom up approach to DevOps consider impacts and benefits only from the IT perspective. This will lead to disappointments at the executive level, no matter how many improvements can be brought about at the technical level.
Top down DevOps transformation driven from management also fail because teams feel like yet another mandate has been imposed on them.
The ideal way to introduce DevOps successfully is to support the transformation from both the top and the bottom. This way, the involved parties can define and agree on the objectives and also support each other in achieving the transformation.
Conclusion
DevOps Transformations is not a panacea to all the challenges faced by the company. Before going ahead with introducing DevOps in your company, you should recognize why you want it.
Secondly, DevOps represents cultural change. It is not a team or a product. Every stakeholder starting from management, developers, product owners and QA need to embrace the change; not just developers and ops.
Ultimately, implementing DevOps should deliver value to the end user, else there is no point in going through the troubles as it will quickly become a hindrance.
