6 Points of DevOps Failure

6 Points of DevOps Failure

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?

Lets look at some reasons that leads to failure of DevOps implementation in any organization

1.Creating a DevOps 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 silos is only going to make matters worse.

2. Its Not Just 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.

3. Its not just between Dev and Ops Team

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.

4. Neglecting Business Owners

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 the organization as well as customers. Involve business units in your DevOps planning and implementation.

5. 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.

6. Putting a timeline to DevOps

Usually management puts a timeline to measure success of DevOps. They thrive to achieve 100% DevOps implementation and push the teams to achieve the same. This leads to a wrong direction where the culture is put aside and the materialistic changes of departments and tool set are just made to show the outcome. However, the business benefit is ignored. DevOps, infact, is a continuous improvement and it never stops and the simple reason is, there is never a case where everything around you is perfect.

Conclusion

DevOps 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.