The implementation of DevOps is fundamentally a change of process. And as with any change of process, it will either be embraced by those making the change and it will succeed, or it will be rejected, subverted, or otherwise undermined, and it will fail. Here I want to focus on reasons for DevOps failure and what you can do to avoid it.
When DevOps fails, it's easy to point fingers without really getting to the bottom of the cause. Aphorisms about "failing to define DevOps" or "failing to focus on people" are well and good (and undoubtedly true), but what do they really mean? Why do DevOps initiatives really go south?
We spoke to experts in the trenches about DevOps failures and why the initiative sometimes doesn't pan out. The reasons they gave us are all actionable and unambiguous. Here are four specific factors and actions that can cause any new DevOps initiative to fail—and how you can avoid that fate.
1. Creating a "DevOps department"
Mistake number one, and perhaps the easiest to avoid, is when DevOps adopters create a new department in the organization tasked with managing the strategy and framework.
That's not how DevOps works, says Rogue Wave Software CTO Rod Cope. "When starting a new process or idea, organizations often jump straight into the new idea and don't take into consideration how it will impact all the other connected parts," says Cope. "Oftentimes, organizations add a new department without removing something (or someone) else, so it ends up adding more process and more red tape."
This is the opposite of what DevOps should accomplish. Yes, a DevOps implementation requires leadership, but that's not the same thing as traditional, department-based management. Your DevOps strategy should be implemented as a framework in which your development and operations staff can begin to interoperate, not as a new department that's tasked with overseeing these disparate groups and somehow forcing them to work together. "Organizations have more success if they focus solely on the new processes of DevOps and not on introducing a new department," Cope says.
Remember that the goal is to step away from old thinking and find ways to streamline the development process. Never in the history of business has simply introducing more people into a system helped it run faster or more smoothly.
2. Failing to properly consider staff workloads and other resources
Are your developers putting in 12-hour days, arriving bleary-eyed, and polishing up their resumes so they can jump ship? Before you dump a DevOps strategy in their laps, you need a clear understanding of existing staff workloads and their ability to execute on the ideas that underlie DevOps.
"Quantify your team's workload and each individual's performance," says SUMO Heavy CTO Bob Brodie. "Set up and monitor KPIs to see where you are failing. If you come across an unmanageable boost in workload, you can either re-prioritize the workload, or hire new resources. Freelancers will offer some much needed help in a pinch. Learn where each of your employees performs best by communicating with the individuals and their managers. That way, you'll be better able to prioritize workloads." Only after this has been completed should you be considering which tool or tools to use in the development and release of your software builds. That's because another common mistake is selecting tools without a proper understanding of which will work best in your environment.
As noted above, a DevOps department is a terrible idea, but at the same time, a DevOps implementation isn't going to manage itself. Someone has to manage resources (both the budget and talent), and tasks must still be delegated appropriately. "Failure comes out of an inability to prioritize and break down your issues," says Brodie. The more fully informed everyone is along the way, the greater your chances for success.
Also, remember that a properly scoped DevOps strategy represents an ongoing learning environment that involves continuous improvement. Done right, DevOps represents a fluid framework that must be allowed to grow and change to meet the unique needs of each organization. Rigidity in the way a DevOps strategy is designed—and in the goals you set—is a clear factor in DevOps failure.
3. Setting unrealistic goals
For many organizations accustomed to a siloed structure in the development process, DevOps can represent a considerable culture shock. Rajesh Sethu, director of DevOps at Replicon, says, "A fundamental reason that DevOps is trickier to introduce than other technologies is that it fuses cultural shifts with operations and development. Upending the business culture—especially with large companies with well-established processes—is not something that can be instantly transformed at the people, process, and information levels."
The larger your enterprise is, the longer this transformation is going to take.
One of the most jarring examples of culture shock can come in the form of new goals given to the dev and ops team members. To tell your staff to shift overnight from delivering releases at a pace of one per month to five per day is simply unrealistic, even if it's ultimately where you want to take the organization. In general, a more measured transition is the best approach. In fact, in the initial stages of implementing DevOps, the release schedule can actually slow down, sometimes considerably, as staff members work to gain an understanding of the DevOps strategy and the tools you've chosen to adopt. DevOps requires training, education, and a breaking-in period. A period of initial sluggishness is a natural initial outcome and shouldn't be thought of as an organizational failure.
Also, says Sethu, it's important to set and track multiple metrics and that these metrics be specific and aligned with the goals of the business. Issuing frequent releases simply for the sake of having lots of releases isn't a viable business goal since it has no real impact on the bottom line. However, customer satisfaction, quality of service, or overall revenue goals (or, preferably, metrics that track all the above) do have relevance to the business and should be tracked vigorously.
4. Attempting to create "hybrid" DevOps while keeping old structures intact
As discussed above, bringing DevOps into a well-established organization can cause culture shock and, initially, some pushback from the rank and file. Development—often motivated to resolve tickets quickly and release as many new features as possible—has historically been at odds with operations, which has been tasked with ensuring 100 percent uptime and guaranteeing that systems are functioning correctly. That kind of culture can't be transformed overnight. Smart DevOps implementations begin with a careful explanation of DevOps objectives, its metrics, and the expectations of management.
What doesn't work is an approach that gives in completely to this cultural pushback. What some organizations try to do, in a misguided attempt to keep the old culture intact, is to build a hybrid structure, one that applies agile methodologies but keeps IT operations and engineering/development teams in their traditional silos. This is especially problematic in companies that have dev and ops teams in different offices or, worse, spread out across the country or around the world. Without somehow combining these groups, either physically or through a significant investment in improved virtual communication, there's little hope of creating the type of collaborative environment that DevOps requires.
Sethu says that it's impossible to truly embrace some of the core best practices of DevOps—including automated testing, integrated configuration management, and continuous integration—without dismantling those old-school silos. Anything else, he says, will result in a "half-baked" DevOps implementation that won't meet the organization's goals and which is doomed to failure.
Sethu adds, "To fully realize the benefits of DevOps, larger organizations with more complex internal structures must look beyond the immediate relationship between developers and operations. Applying the principles of DevOps so that teams feel they have the breadth to drive constant value and improvements will help enable its success across the organization."
Shift it
Transitioning to DevOps is, first, a cultural shift, and then a process and organizational shift. But all of those shifts must take place at the department level and in a fashion that goes beyond paying lip service to the fundamental ideas of DevOps. If you're considering DevOps simply because "it's the future" or as a means of keeping up with the Joneses, rather than out of a desire to fundamentally rebuild and improve your business processes, success is highly unlikely.
Remember that DevOps takes time and effort, requires strong leadership and advocacy, and must be measured in a way that's compatible with your organization's goals. Set yourself up for success by avoiding the mistakes that those who've come before you have already made.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
