LF

Why DevOps Fails: A Closer Look

09

DECEMBER, 2018

by Sylvia Fronczak

DevOps promises greater innovation, speed, and automation—along with a more engaged and motivated team. With this list of benefits, many organizations are working to bring DevOps to their teams. However, with all the companies jumping onboard the DevOps transformation train, there are still many cases in which the transformations fail.

So what can we do to ensure that our DevOps implementations take hold? What should we look out for that could go wrong? Let’s take a look at the different reasons why DevOps fails, so we can take some of these warning signs and make sure we don’t fall into the same traps.

 

Not Considering the Big Picture

When 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 Collaboration

With 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 Once

We 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 Results

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

When 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 Culture

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

  1. A culture that allows for mistakes while finding the best path forward.
  2. The ability to explore improvement opportunities.
  3. Blameless retrospectives on what’s going well and what still needs improvement.
  4. Communication of successes and failures to the whole organization.
  5. A drive toward continuous improvement.

Without these components, we can go through the motions of DevOps, but we won’t be driving innovation and delivery as well as we could be.

Find What Works for Your Organization

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

 

Author: Sylvia Fronczak. 

 

Relevant Articles

5 Red Flags Deployment Management Is Failing

20 MAY, 2019 by Mark Henke It’s a great step when teams deliberately manage their deployments instead of treating them as second-class citizens to writing code. But there are many pitfalls to managing deployments effectively. Many things lurk, waiting to trip us up....

5 Red Flags Enterprise Release Management Is Failing

08 MAY, 2019 by Mark Henke Taking enterprise release management seriously is a great step toward helping our organization flourish. Embracing release management will allow us to make the invisible visible. We’ll be able to effectively manage how work flows through our...

Marrying SAFe and DevOps

04 MAY, 2019 by Rodney Smith If you work in an organization that uses the scaled agile framework (SAFe), chances are it's not a small company. It's enterprise-y. It's probably gone through some growing pains, which is a good problem to have in the business sense. The...

DevOps vs. DevOps at Scale

29 APRIL, 2019 by Carlos "Kami" Maldonado "DevOps at scale" is what we call the process of implementing DevOps culture at big, structured companies. Although the DevOps term was coined almost 10 years ago, even in 2018 most organizations still haven't completely...

DevOps Anti-Patterns

24 APRIL, 2019 by Mark Robinson It’s the normal case with software buzzwords that people focus so much on what something is that they forget what it is not. DevOps is no exception. To truly embrace DevOps and cherish what it is, it’s important to comprehend what it...

Delivering at Scale, Why SAFe Is Essential for Agile Teams

16 April, 2019 by Eric Goebelbecker Your organization is in the midst of an agile transformation. You know that agile is the way to go, and you're looking forward to, or maybe already reaping, some of the benefits. Who can argue with what agile brings to the table?...