In the past, software development and IT teams operated separately. This led to a variety of manual processes that slowed projects down and delayed product launches. When DevOps practices entered the mainstream in 2009, tech leaders saw how many of these tasks could be automated and make their teams more productive.
With that in mind, you’d probably assume that all organizations quickly merged their infrastructure, operations, and development teams. But a recent report from 2nd Watch found that only 22% of companies have embraced DevOps. This statistic begs two questions. First, why haven’t 78% of engineering teams begun their DevOps adoption? For the ones that have, what’s the impact of getting it wrong?
We presented both of these questions to Thomas Limoncelli, Site Reliability Engineering Manager here at Stack Overflow. Here’s what he told us about the importance of DevOps.
How Do Organizations Get DevOps Wrong?
When it comes to DevOps adoption, Limoncelli says he sees a few things too often. The first thing he highlighted was the initial changes that organizations tend to make. “Companies change job titles without shifting job functions,” Limoncelli continues. “The problem is that it’s more than a job title. It’s a strategy for producing better results in software development.”
Additionally, he says that many engineering teams focus too much of their attention on tools, not people. “Companies buy a product thinking that a tool will magically transform their organization,” he adds. “But tools can only facilitate the transformation. DevOps transformations begin with people from different teams talking to each other, finding common values and pain-points, and working together to make improvements.”
Finally, Limoncelli says that top-down edicts from executives don’t work. Even if a CTO simply declares that everyone must apply these practices to their workflow, nothing will change. He continues, “People have attempted these transformations using many management strategies, including top-down and bottom-up approaches. Top-down has never worked. It must be bottom-up, with or without management support.”
“DevOps adoption usually begins with one grassroots project. Over time, other teams want to copy their success,” Limoncelli says. Interestingly, some of the biggest success stories he described were all done with the quiet support of upper management, and in some cases, behind its back to avoid getting too many people involved.
The Impact of Poor Implementation
The outcome of implementing DevOps in name only creates bigger problems. “Generally, you keep doing things the old, broken way and see no improvement. This gives DevOps a bad name,” according to Limoncelli. If these practices have such a negative reputation, how can you overcome it to drive adoption?
“I know people that had their transformation plans rejected because they walked into organizations that had misperceptions about the term ‘DevOps’,” Limoncelli says. “For example, they incorrectly through it just meant everyone would get paged late at night whenever the website went down. They decided to rewrite their presentations without the term and focused on one benefit that everyone would find appealing: The ability to rapidly release new versions of your product.” Soon after these presentations, his colleagues’ companies were entirely on board. Still, most people only realized what had occurred after the majority of projects saw the benefits.
Looking for an easier way to implement DevOps practices at your organization? Find out how Stack Overflow for Teams can help.