Top 3 reasons why DevOps fails
If you are a business owner or an executive, optimization of business processes to minimize expenses must be one of your priorities, ass a dollar saved is a dollar earned. With that goal in mind, you’ve probably heard about DevOps several dozen times already. However, you might have also heard that DevOps initiatives fail quite often (this being the reason more and more organizations delegate their DevOps processes to Managed Services Providers like IT Svit). Based on our experience, we list the top 3 reasons why DevOps fails, so you will be able to avoid them.
In the majority of cases, the reasons behind failed DevOps projects are as follows:
- Lack of understanding of what must be done
- Lack of commitment from the executives
- Lack of trust from the team members
Below is the explanation of why it happens this way and how this can be amended.
Reason 1: lack of understanding
When a company wants to adopt DevOps practices, it quit often falls for the fallacy of multiple DevOps consulting “gurus, evangelists, experts and visionaries”, who have written lots of articles and spoken on lots of conferences. These wonderful people will consult you (for a hefty sum of money) and explain that in order to make the DevOps magic happen you need to place developers, QA specialists and system engineers in one big room and let them work together, teaching each other the basics and advanced tricks of their trades.
They say that a DevOps engineer is a symbiosis of a Dev, QA and Ops, who can write, test and deploy the code. This is supposed to implement the “you built it, you run it” approach announced by the Amazon CTO Dr. Wener Vogels back in 2006.
However, these “specialists” misinterpret the meaning of this quote completely. Mixing the teams up does not lead to improving their performance. Even the best experts in software development are quite often bad teachers and cannot share their knowledge quickly and efficiently enough. Such an initiative can only lea to frustration and drop in productivity, after which your organization goes back to the way the things were before and spits acid whenever they hear that DevOps can be hugely beneficial for their operations.
Solution: Ask the practitioners who do DevOps every day, how it should be done — and follow their best practices. The meaning of “you built it, you run it” is quite different. It means the developers who wrote the code have to work several shifts a month as support representatives to come into direct contact with the customers and receive immediate feedback regarding the convenience and performance of their products.
However, THEY STILL WORK IN PAIRS WITH SYSTEM ENGINEERS, as while they know how their code works and what might cause the bug, THEY DON’T KNOW HOW THE SYSTEMS WORK — nor should they.
But this was said back in 2006, is it still relevant in 2020? To a degree, yes. In real DevOps, not the skills, but the goals and operational objectives of Devs, QA and Ops are combined and aligned to allow them to reach the business objectives better. Real-life DevOps engineers DISCUSS how an app should operate in production with the Devs and QA.
Understanding the best ways to scale, reboot and update the application dictates its architecture — monolith or microservices, which impacts the approaches used to build and test it. When all is discussed, the Devs write the codebase for automated unit and integration tests, the QA prepare high-level automated testing routines and the Ops write the scripts that automate the majority of repetitive operations, like provisioning and configuring testing environments. When this is done, the devs can perform the basic tests themselves, just by running the needed scripts, which speeds up the process immensely.
Thus said, real-life DevOps is about fostering communication and collaboration between Devs, QA and Ops to ensure timely software development and cost-efficient operations in production. Mind you, we never said anything about sitting a crowd of people in a huge open space office and trying to teach a developer or QA to deploy the Kubernetes cluster — as it is not their job!
Reason 2: Lack of commitment from the executives
Many more companies, even the ones that get the meaning of DevOps right, fail in their digital transformation efforts because they are not persistent enough. Transition to DevOps is perceived as “another trendy idea” and it is followed in the letter, but not in spirit. This means that the management itself is not confident in its ability to transform the organizational culture (and this is what transition to DevOps is largely about).
As a matter of fact, while actively claiming to strive to improve the performance of their organizations, most managers are actually quite satisfied with the existing status quo. In addition, everybody talks about the success of such reforms — but everybody thinks about the risks of failure — losing time and money, losing the confidence of their superiors and respect of their underlings, maybe even losing their jobs — all of this hinders the actual effort made towards implementing the DevOps in earnest.
Thus said, the company starts to “implement the DevOps culture” with zeal and energy. It is a culture of communication and collaboration? Okay, we will appoint a committee of the representatives of all the parties involved, who will communicate and collaborate on the strategy of transformation, outline the roadmap we want to execute, define the results we want to achieve, assign the measurable KPIs we want to improve…. aren’t you lost yet?
If not, the committee begins to meet and discuss, and evaluate, and propose, and define, and outline — and finally comes up with a huge document where everything is described in detail, and which will help the company transition to DevOps and become a lean, mean and efficient machine. The only flaw of this document is that it crumbles into pieces after meeting the very first roadblock, and must be thrown away and forgotten. But what about the time, effort and money that went into creating it — are they lost too? Unfortunately, yes.
Solution: DevOps transformation must have a full commitment from the executives in order to be successful. It must not be a directive from the above — it must be a grassroots initiative based on the needs and goals of the people who are actually going to implement it — BUT LEVERAGING THE WHOLEHEARTED AND ALL-ENCOMPASSING SUPPORT from the managerial body.
The main problem with this approach is that DevOps is actually a self-governing culture that needs quite little managerial control — and many executives are afraid to give the reins to their underlings, as they become slightly (or totally) unnecessary in self-sufficient teams that can make their own operational decisions and have a say for their needs in the C-suite meetings. However, it is either done this way or you are left to rot on the curb and eat dust from more dynamic competitors.
After all, adaptation is not necessary, and the survival of your business is not mandatory, as Edwards Deming said.
Reason 3: lack of trust from the team members
Largely originating in the second reason, this is another quite common issue with all the DevOps initiatives. Most teams are used to working the way they do. They grumble and they are not satisfied with the tasks they receive and the feedback they get, they are tired of dealing with the same issues time and again — but they actually DON’T want to change ANYTHING. Why so? Because people are lazy and your employees do the absolute minimum they MUST do in order to keep their jobs.
Now imagine your Ops engineers receive a requirement to transform their operations, cooperate with the Devs and QA more (those insolent Des, who throw them half-baked code over the wall to run it in their precious production systems — collaborate with THEM???). And what for — to DO MORE, FASTER? Be sure, the same opinions are voiced in the QA and Dev teams as well. Such initiatives are doomed from the start.
Solution: The guerilla resistance from your team members can be overcome by showing hem that DevOps is actually about making their life EASIER. Instead of waiting for the Ops to provide the needed testing environments, the Devs will be able to do it themselves by running a single script. Believe us, it is as great as it seems.
Instead of checking for the same minor integration bug time and again, QA will be engaged in smoke tests, regression and user acceptance tests on the staging server. Instead of configuring the same testing machines or rebooting the same faulty process in production over and over again, the Ops engineers can experiment with reorganizing the systems to remove the performance bottlenecks and get rid of these tiresome repetitive incidents, while not being bothered by the Devs who need yet another testing environment configured. But most importantly — the Ops team will finally get recognition for their hard work on keeping the systems running!
Instate a Center of Excellence within your organization, where an external DevOps practitioner will help a team of your select employees to master the DevOps tools and practices like IaC, CI and CD. Give them a minor project to accomplish in under a month — and don’t intervene. People who do DevOps daily can quite quickly show all the parties involved how cool it is to communicate, collaborate and join efforts to reach common goals.
This team will later spread the word among their colleagues and become a catalyst and a working agent to transform your operational culture across the entire organization — and make your business more agile and competitive, your IT operations more predictable and cost-efficient and your employees more productive and innovative.
Conclusions: how to ensure DevOps does not fail for you
Therefore, you can ensure your DevOps journey will be a successful one. It can be done, if you stand on the right premises, ensure wholehearted project support and let your team learn by doing the first steps together with professionals.
However, this is all good and fine, but how to get quick results when you cannot spare the time required to retrain your employees? The best way is to delegate DevOps tasks to Managed DevOps Services providers like IT Svit and include the reps from your IT department into the group of business stakeholders working on this project. This way the business gets instant access to skilled DevOps talents and your internal team learns to do DevOps by participating in the project.
Still unsure how to implement this? Let us know, we would be happy to explain and assist!