Puppet just released its 10th State of DevOps report, and though 83 per cent of surveyed IT decision-makers state they’re implementing DevOps practices, there is still some way to go until organisations will really be able to make the most of it.

This year’s survey incorporated feedback from 2657 individuals from all over the world — though Africa, the Middle East, Central America and South America still seem at least slightly underrepresented with their share of six per cent. Respondents mostly worked in software development or DevOps teams (52%) and hailed from organisations of all sizes, with those in the 1000 to 10000 bracket supplying almost a third of the data. 

Puppet used the anniversary edition of the report to clarify the DevOps term once more, and examine what it is that stops organisations from becoming highly evolved DevOps orgs. Highly evolved here means that incident responses are automated, resources are available via self-service, apps are remodeled based on business needs, and that security teams are involved in the design and development process of new technologies.

Amongst other things, the report tries to put an end to the still somewhat prevalent idea that DevOps is just about automation and cloud use. Sure, 90 per cent of respondents in the highly evolved category say that they have automated most repetitive tasks and also seem to be using the cloud well. However, there are other aspects that need to be addressed to increase team efficiency.

What’s in a (team) name?

Puppet Field CTO Nigel Kersten highlighted the importance of team identities in this context. While 91 per cent of highly-evolved teams report to be clear on their role and the goals of their work, it’s only 46 per cent in low-evolution teams. A precise team name and clearly defined responsibilities everyone in an organisation understands would already help to improve performance, the report suggests. 

Looking at the number of people stating to work in a DevOps team (21%), the naming problem seems to have been at least recognised, since that number has largely gone down since 2018 (29%). Puppet hopes this is motivated by organisations starting to centre their teams around purpose rather than cost centre, but could also be down to current trends like renaming DevOps teams SRE.

Besides the name, having clear ways to share information and structure teams in a sensible manner are points low-evolution teams can work on. In terms of structure, successful teams tend to go for a combination of stream-aligned teams and platform teams, as described in Skelton and Pais’ Team Topology model. Platform teams herein provide functionality as an internal service to stream-aligned teams, who work on a slice of the business domain without hand-offs to other teams, following the “you build it, you run it” paradigm.

Consider self-service

Having a platform team that provides things like container orchestration, authentication, observability and logging via self-service is key to success at scale, according to Kersten. In a roundtable discussing a decade of DevOps research, he pointed out that the centralised abstractions those teams provide could reduce the extraneous cognitive load on developers “an awful lot”. Like this, developers could focus better on building an external product and not lose time dealing with other teams or managing expectations.

To build up such a structure, however, organisations need buy-in from all levels and an active promotion of DevOps practices — top-down as well as bottom-up. The report therefore calls organisation leaders to help create a culture of knowledge sharing in order to get unstuck in the middle of DevOps evolution — a fate that 78 per cent of organisations seem to run into as of late.

Sharing knowledge about best practices between teams using the same language, making sure everyone understands a company’s IT infrastructure and having change management procedures in place that make sure stakeholders are up to date are just a few things that can actively help progress.

Say goodbye to the feature mindset

Courtney Kissler, CTO at e-commerce company Zulily, calls for a balanced point of view when it comes to features vs maintenance, and a shift in mindset to get everyone on board. “A lot of this transformation, or ways of working, or whatever we want to call it, has been focused on the technology and/or IT org. In order to really get the outcomes that are important, the whole company needs to be shifting their mindset. [..] A lot of what we’re trying to solve through the DevOps community is ‘how do we have this really scale in a meaningful way’, which means it can’t just be a technology topic.” 

To communicate this circumstance better, it’s worth considering staying away from terms like DevOps when talking to certain partners to keep it from sounding like a tech-only problem. “The supporting system is not always optimised for these practices” Kissler pointed out, with funding, auditing and HR in mind. “The work happening in our teams is not just feature and operational. You need to look at the holistic amount of work that is happening and need to accept that the capacity in the organisation is always going to be a constraint.”

So it can’t be all features all day long, otherwise it will be hard to keep what’s already there going. Investments in resilience are therefore a necessity to Kissler, even if “some leaders don’t want to think about” such things. Traditional development and operations teams unfortunately don’t really have the luxury to not ponder such invisible work on the way to DevOps, since many stated legacy systems being a problem on the way to full adoption.

Another often cited hindrance on the way to becoming a highly evolved DevOps organisation is a shortage of the right skills. Charity Majors, co-founder of observability company Honeycomb, used the roundtable to question this notion however.

“We are an apprenticeship profession. I’ve never seen anyone have trouble learning the skills that they need to learn, as long as they’re given the time and space to learn it,” Majors said on the call. “The bigger problem is that we expect people to show up with a checklist of having done this and this and this. Good luck with that. We need to hire, expecting to teach and to learn and to mentor — that is just how the world works.”

DevOps won’t disappear any time soon

At ten years in, the report also tries a look at the future of DevOps. This largely consists of mid-evolution organisations adopting the team structures and platform approach described earlier, while those still in the early stages should embrace the new world of as-a-service and invest in their legacy environments.

Chances that DevOps will just disappear are slim, as VP Platform at CircleCI Michael Stahnke said in the roundtable. “The ability for anything in technology to retire and become gone is basically zero, so I think we’re still going to be talking about it and we’ll be talking about it in different ways. It’s probably most comparable to the way we’re talking about agile today. 

“I would almost argue that to the extent that DevOps succeeds, we will hear about it less,” Majors added. “It will just become part of the atmosphere and ‘this is just the way we do things and why would we think about it’. In my entire career, I’ve never actually worked in a place where we ‘did agile’ but I know that the way I work has been informed generationally from a lot of agile principles.”

Tiffany Jachja, Engineering Manager at Vox Media, even expects a spread into other spaces, and current initiatives such as MLOps indicate she might be onto something. “It’s very, very similar in agile — even today we see other teams, not software teams, working agile for any project based initiatives they may have. And I think it’s going to be very similar in terms of DevOps, where we’ll see it going to the data science and machine learning spaces. We’ll try to branch out into other industries and go towards that.”

We’ll definitely keep an eye out for the next editions to let you know when this becomes measurable.