Why DevOps Fails: A Closer Look
Not Considering the Big PictureWhen considering a digital transformation of any kind, one common mistake involves not considering or even defining the big picture. And this picture should go beyond developers and operations—the entire organization should have the same shared understanding and vision for the DevOps transformation. Does this mean that every team must implement DevOps the same way? No. That might not even be possible. As you may know, there are many ways to implement DevOps and many tools you can use. However, depending on the software, age of infrastructure, and other considerations, it may not make sense to have exactly the same tool or process for every product. So although it’s common for some teams to take a slightly different path toward DevOps and possibly use different tools, there should still be a shared vision across the organization. Therefore, if everyone in the organization drives toward the same vision and goals, we can still get what we need out of the DevOps transformation.
Not Talking About Cross-Team CollaborationWith larger organizations, some amount of siloing is inevitable. Whether it’s separate products or thin slices of functionality in a larger product suite—or even different operational functions like infrastructure and data—one team can’t do it all. And although DevOps encourages teams to own their own operations, that’s not always feasible on day one. It might take a while to get to the point where operations and infrastructure can be handled by a product team. Now, how does that relate to your DevOps transformation? There will almost always be dependencies between teams, so you’ll have to consider cross-team collaboration and implement solutions that automate processes between teams. For example, if a software team automates its own processes, but has to rely on ticketing systems to get infrastructure changes made or JIRA tickets for database changes, you’re simply moving bottlenecks to different areas. Part of the DevOps transformation should involve improving cross-team collaboration and coordination so that product deployments aren’t blocked by external teams with different priorities.
Trying to Transform Everything at OnceWe can’t go from no DevOps to deploying each application multiple times a day. We have to take it slow and consider how we’ll evolve the solution over time. In the same way you’d handle refactoring a software application or decomposing microservices, start with a product or process that’s not the most critical. Start at the edges of the development pipeline, where new processes and tools won’t be as disruptive. And find use cases where you can solve pain quickly, so that benefits are quickly realized and motivate additional changes. Then take the lessons from that implementation and improve on the process. Make small, iterative changes as you spread the knowledge and processes to the next team.
Not Using Metrics or Measuring ResultsDevOps is more than just release and deploy. Without gathering metrics on what deployed and when, you’re just shooting blindly and hoping automation saves the day. As we drive toward continuous delivery, we must add objective metrics that clearly communicate the health of our system. Measure & Improve, think DevOps Value Stream Mapping. Without metrics, we might miss small failures that need to be corrected quickly. This can decrease the confidence of everyone involved in the transformation process.
Forgetting Important ComponentsWhen looking at DevOps, most companies focus on software and the CI/CD pipeline. It’s OK if that’s where you want to start, but you also need to pay attention to other parts of the pipeline. First, if you can’t roll out and roll back infrastructure changes automatically, then you have the same problems you originally did with your software. Although you won’t get there overnight, strive toward environments that you can spin up and down without difficulty. Next, companies often forget data. They consider data to be this static, untouchable thing, but data should be considered in the automation pipeline as well. As with infrastructure, it may be hard to get here overnight, but thinking about the state of data in new ways will make your products more resilient to failures. Lastly, we must consider automating testing as much as possible. If we really want to deliver code more frequently, we can’t rely on manual testing. That will only create further bottlenecks in our QA team when we’re shipping code to various environments daily or weekly.
Not Considering the CultureDevOps is more than just software and tools. One big component of DevOps success that goes beyond automation involves people and culture. It’s not enough to have all the DevOps tools and processes. The culture needs to be one of continuous improvement, feedback, and reflection. And this culture change can’t be segregated to just developers and operations. This is a change that involves the whole company, because if you’re going to release products faster, then it’s not just your developers and ops that are affected. QA needs to be on board. More testing needs to be automated. Support personnel need to be up to date on what’s going out and when. So, what makes up a good DevOps culture across the whole organization?
- A culture that allows for mistakes while finding the best path forward.
- The ability to explore improvement opportunities.
- Blameless retrospectives on what’s going well and what still needs improvement.
- Communication of successes and failures to the whole organization.
- A drive toward continuous improvement.
Find What Works for Your OrganizationThere are many reasons why DevOps fails within organizations, and these reasons are affected by existing practices and culture. It’s important to take a look at the big picture in an objective and caring way. Then we’ll be able to make changes and improvements to move us toward success. Furthermore, it’s not a definite sign of failure if you see some of these problems in your organization. Consider what your particular pain points are and strive to correct those first. And finally, keep in mind that a DevOps transformation is never truly done. Different companies may not be able to solve all automation problems using DevOps. Iterate on solutions to improve the processes and culture every step of the way.
09 SEPTEMBER, 2022 by Michiel MuldersDo you want your company to scale efficiently? Look for an enterprise release manager (ERM). An ERM protects and manages the movements of releases in multiple environments. This includes build, test, and production environments....
22 August, 2022 by Louay Hazami *Update from October 2020Data privacy is one of the most pressing issues in the new digital era. Data holds so much value for normal internet users and for all types of companies that are looking to capitalize on this new resource. To...
16August, 2022 by Carlos Schults *Update from 15 Mar 2021In today's post, we'll answer what looks like a simple question: what is data fabrication in TDM? That's such an unimposing question, but it contains a lot for us to unpack.What is TDM to begin with? Isn't data...
08August, 2022 by Carlos Schults *Update from 26 Nov 2019.Your Essential TEM Checklist "Test Environment Management Checklist." Yep, that sounds like a mouthful, but don't let that discourage you. The idea here is quite simple—adopting a checklist to evaluate...
03JUNE, 2022 by Niall Crawford & Carlos "Kami" Maldonado. Modified by Eric Goebelbecker.DevOps at scale is what we call the process of implementing DevOps culture at big, structured companies. Although the DevOps term was back in 2009, most organizations still...
3JUNE, 2022 by Erik Dietrich, Ukpai Ugochi, and Jane Temov. Modified by Eric GoebelbeckerMost companies spend between 45%-55% of their IT budget on non-production activities like Training, Development & Testing and lose 20-40% of productivity across their...