Technology is always changing, and thus the way organizations manage around technology is always changing. There are always new methodologies entering the field, promising various benefits if only you could adopt it correctly. 

Many of these fizzle out and remain nothing more than buzzwords, but according to Charles Betz, principal analyst at Forrester, DevOps has been an exception to this “IT fashion show.”

Despite this, a majority of companies aren’t where they could be when it comes to their DevOps evolutions. 

RELATED CONTENT: 
How HCL Software helps companies evolve their DevOps practices
A guide to DevOps tools

According to Puppet’s 2021 State of DevOps report, the majority of companies practicing DevOps are stuck in the middle of their DevOps evolution. This has remained mostly consistent over the past few years, dropping just 1% since 2018, to 79% of companies. 

In 2021, Puppet found that 18% were at a high level of evolution and 4% were at a low level of evolution. Despite the percentage of companies in the mid-level of evolution, the percentage of those on the high or low end actually has shifted over the past four years of the study. By comparison, in 2018, only 10% were highly evolved while 11% were considered to be at the low portion of DevOps evolution. 

So what is keeping so many companies in the middle? And what exactly does it mean to be in “mid-level evolution?” 

According to Puppet’s report, they define mid-level evolution as companies who have already laid their DevOps foundations. “They have introduced automated testing and version control, hired and/or retrained teams,  and are working to improve their CI/CD pipelines. They’ve managed to start optimizing for individual teams, and if they’ve managed to avoid many of the  foundational dysfunctions from which large organizations can suffer, they’re in a great position to start optimizing for larger departments, the ‘team of teams,’” Puppet explained in the report. 

Always looking to improve

Betz argues that DevOps transformation is never truly done. Even though it might have stalled at a certain point in some organizations, DevOps as a practice in general has largely been a success. 

Rob Cuddy, global application security evangelist at HCL Software, agreed, adding that DevOps is a continual evolution of trying to deliver better quality software faster. “ So, you’re always going to be improving, and looking to improve as you go,” he said. 

Al Wagner, solution architect at HCL Software, added that changing technologies means that DevOps also has to continually change to keep up. It’s a moving target, not a stationary finish line where once you’ve crossed it, you’ve succeeded at DevOps. 

“As DevOps has grown, we discover new problems and new solutions to those problems, where every time we embrace something, if you think about cloud, it has only evolved post this term DevOps, and same with Kubernetes, Docker. So when people get stuck, the beauty of DevOps is it continually evolves and grows, and it’s not locked down by a manifesto,” said Wagner.  

Even so, there are some bottlenecks that companies run into when they’re trying to evolve their DevOps practice. Cuddy believes one bottleneck is a lack of understanding of what you’re doing. He sees this in companies automating for the sake of automating without really knowing why they’re trying to automate some part of the process. 

“The whole goal should be to improve the quality as it goes through the pipeline,” said Cuddy. “But if you’re just running scans, or running tests for the sake of running them, and you’re not doing anything with the results, well, great, you’ve added a lot of automation, but now you’ve created a ton of noise.” 

Three reasons for struggle

Paul Delory, VP analyst at Gartner, also defined three main reasons why he believes an organization might struggle to move forward with DevOps.

First is skills. There are all of these technologies that allow companies to do amazing things, but in order to actually do those amazing things, they need people with the right skillsets on board. Delory explained that a lot of initiatives get stuck because of a lack of talented people. 

Those few that do have the matching skillset you’re looking for don’t tend to stay on the market for very long, and they also get offered really high salaries, which might be difficult for all companies to match.

When companies find themselves in this position, they must look to growing these skills internally instead. But this option is a longer process, so it injects further delays into their DevOps transformation. 

“I think that’s a big part of the reason why a lot of people get stuck on this plateau,” said Delory.

The second reason people stall out in their DevOps transformation is that they might not actually need DevOps in every aspect of their business. 

“If I look at the portfolio of applications that an IT department is asked to support. I think there are a lot of cases where essentially, you don’t have the problem that DevOps solves,” said Delory.  

According to Delory, when talking about DevOps, we’re often speaking of fast moving, line of business applications that are directly impacting revenue. But not every application in the company is going to fit that bill, and thus, won’t really be an ideal candidate for DevOps. 

Delory gave the example of an employee phone directory as an application where applying DevOps wouldn’t make sense. 

“Your employee phone directory is probably a Ruby on Rails app that was written in 2009, and nobody’s touched it since,” said Delory. “Bringing in these kinds of DevOps transformation, cloud transformation, you could do that, but it’s not really necessary, and I don’t think you’re going to see ROI on that in any reasonable time horizon.”

The third factor that Delory thinks keeps people stuck in their DevOps transformation is politics and team structure. 

For example, organizing a central operations team is something that some developers might not be too thrilled about, while others are happy about the change. The developers who don’t want to have to manage their own infrastructure would be ready and willing to hand that over to someone else, and the developers who really like getting their hands dirty and being involved in that aspect would probably be the ones not too happy about having to adopt this new team structure. 

“In all of these conversations around redesigned team boundaries and roles, getting it right is critical. And if you don’t get it right, then that can definitely be a barrier to adoption,” said Delory. 

Cuddy agrees with this sentiment, and believes that the single biggest piece of DevOps is the people, not the tools or processes. 

“If you are not maintaining any kind of an organizational culture that supports DevOps that enables people that builds trust, that allows for flexibility, that allows room to fail fast and grow and learn, you’re gonna get stuck eventually,” said Cuddy. 

He says that a bad culture will always beat out good processes, every single time. This is why it’s so important to focus on getting the team culture to where it needs to be. 

Cuddy believes that in order to successfully change culture, you need leadership buy-in so that change can be enacted not only bottom-up, but top-down. 

This idea has necessitated the need for value stream management. According to Wagner, when companies have been investing significantly in something like DevOps for years, they want to be able to see the relationship between their investments and business outcomes. 

“Leaders may not be seeing a return on investment, and perhaps there’s not as much money coming back to the development teams to improve,” said Wagner. “So it’s really finding those bottlenecks using things like value stream mapping, value stream management, prioritizing, working closer with the leadership and the stakeholders to make sure that we are linking, and that the things we do in the product teams are directly contributing to the business.”