DevOps is Failing, But Here’s How to Succeed

Source- devops.com

As the Data Economy continues to gain momentum, many companies have turned to DevOps in hopes of achieving agility and velocity to compete and win. Whereas it’s no secret that DevOps can have a major impact on agility, what’s not widely known is that most DevOps projects actually fail. In fact, a simple search of “DevOps failures” returns a range of recent results from minor issues to major fiascos. So, what are the warning signs that an initiative is failing to live up to expectations, and how can you fix it before it’s too late?

Focus on People, Not Tools

There are several types of potential problems that undermine the efficacy of DevOps, and the most common one—which is the easiest to overlook—is failing to recognize that DevOps is a changing of processes. So, as with any kind of process change, it can only be effective when it’s embraced and adopted by all people involved. Organizations that are successful are able to not only shift processes but also win the hearts and minds of workers and get their buy-in early on.

When leaders approach DevOps as a tools-first methodology without addressing outdated legacy systems or the underlying IT cultural issues required to make newer tools work for their organization, projects have a tendency to either fail or fall short of expectations. In today’s competitive digital business landscape, DevOps teams need to be able to deploy multiple test environments multiple times a day to collaborate and test effectively.

But deploying DevOps technology is often the easiest part. The real problem is trying to use the same tired data management techniques with those new tools. If marrying new tools with old structures (or systems) were simple, most companies today would already have DevOps approach in place. For initiatives to be successful, though, requires a significant shift in thought from leaders and workers alike to achieve both short and long-term development goals.

Slow-to-Change Culture

DevOps is all about using rapid iterations and collaboration without requiring formalized meetings to move forward, broker alliances or seek permissions. Given that DevOps is a people-driven process at its core, you know you’re in trouble when your teams are holding routine meetings lasting 30 minutes or longer. If you are doing this, it means the organization is still operating in a siloed manner, which undermines DevOps efforts.

Creating a successful initiative takes clear communication because even though everyone wants the same result, they often want said result on their own terms. Introducing DevOps efforts into a well-established organization isn’t easy, and often there can be culture shock and even pushback from rank-and-file workers all the way to mid-management or senior leaders.

With that in mind, to build a culture that enables agile development, it’s important to communicate objectives clearly and act with discipline early. There should be a well-defined explanation of the objectives, metrics and goals by which your DevOps initiatives will be measured across the organization. It’s not enough to adopt DevOps practices just because it’s the buzz right now; rather, you need to be able to understand how it can help you rebuild your business process and achieve specific development goals—or else your success is not likely.

You can’t evolve a company culture overnight, but with the right approach and commitment to the DevOps journey, you can lay the groundwork for organizational change and achieve more agility.

Inefficient Workflows (Data Friction)

DevOps initiatives are often dependent on applications, which are powered by business data, but getting that data to the right teams can create an enormous amount of drag on the workflow. We often call this data friction. This is a prime example of data friction or the tension between demand for data access and the constraints that stand in the way.

This commonly leaves DevOps teams in one of three places, each with their own drawbacks: using stale and polluted data sets, stopping Dev and Test to wait on data provisions and refreshes, or just developing on purely synthetic data (punting the data problem to Test). To avoid returning to the same constraints, we need to rethink the way our teams access data in a way that minimizes the current friction so that we’re no longer choosing between quality, security and agility.

Data should flow securely, freely and at lower cost, eliminating the friction around data. Synthetic data should be used for development because it is the correct data to use for development, not simply because it is the fastest. Taking a DataOps approach—tackling the data constraints around people, process and technology—is the only way to ensure you are eliminating data friction, rather than shifting it to someone else.

Conclusion

Companies set themselves up to repeat mistakes when they try to throw even more technology at the problem, without considering how existing infrastructure, culture and tools will work together in a DevOps strategy. At the end of the day, a tool is only as good as the teams who use it, and DevOps as a methodology should always be considered a continuous cycle of improvement. It’s time to broaden our perspective on the aspects of data management that we can improve upon to also include the people behind the tools. The future of DevOps depends on our own team’s flexibility and willingness to continually improve our own processes.