Stop calling DevOps teams 'DevOps teams'

Latest Puppet survey finds DevOps teams actually have a variety of roles that are more in line with business goals.

The authors of Puppet's latest industry-wide DevOps survey have a bit of advice for DevOps proponents: stop calling it "DevOps." It's only creating confusion. And don't even get started on DevSecOps. They also bring another interesting tidbit of news: a well-designed IT architecture can help resolve corporate cultural issues.

DevOps: What is it, and how can it help your business?

Inspired by the world of just-in-time manufacturing and widely practised in 'greenfield' IT organisations such as web-scale businesses and startups, DevOps is now making inroads into the 'brownfield' enterprise market.

Read More

That's the word from Puppet's 2021 State of DevOps Report, which includes the experiences of 2,650 IT, development, and information security professionals. It's not that DevOps is slipping in popularity -- 83% are implementing DevOps, and many are seeing benefits including more rapid delivery of quality software. 

Also: What is low-code and no-code? A guide to development platforms

"We strongly believe that the presence of 'DevOps teams' is confusing for the industry and many organizations, and in most cases doesn't help organizations evolve," the survey report's authors, led by Nigel Kersten, CTO of Puppet, and Kate McCarthy, principal at ClearPath Strategies, state. "In our experience, organizations that have less ambiguous team names, with more clearly defined responsibilities, are far more likely to have a higher performing IT function." 

DevOps functions are typically charged with a range of responsibilities, including the following identified through survey respondents' self-descriptions of their teams:

  • Traditional infrastructure & operations
  • System administration
  • End-to-end product responsibilities
  • Supporting development teams with a combination of release automation, deployment pipelines, and tooling
  • Building the awkward things that application developers don't want or need to care about: infrastructure, container fabrics, monitoring, and metrics.
  • Encouraging and enabling DevOps practices across an organization

"Lack of clarity around team identities creates significant organizational friction, impeding software delivery in a variety of ways," Kersten and McCarthy advise. "We suggest that organizations move away from the use of 'DevOps' teams towards clearer team names, and in particular that the use of stream-aligned and platform teams is a well-defined path to achieving DevOps success at scale." 

In other words, DevOps may be the mechanism by which teams goals are accomplished, but is not a goal in itself. And security should be built into these efforts from the start -- not a separate "DevSecOps" effort.  

The Puppet team also looked at a smaller segment, what they call "highly evolved firms" that have seen greater success with DevOps approaches, to track what they are doing differently from their lagging peers. For starters, they take a platform approach, "enabling developers to access authentication (62%), container orchestration (60%), and service-to-service authentication (53%), tracing and observability (49%), and logging request (47%) services via self-service." This was accomplished "by understanding their internal customers and offering a curated set of technologies for infrastructure and for development capabilities on their platform."

Teams also look different in highly evolved firms, the Puppet team observes. They employ "a combination of stream-aligned teams and platform teams as the most effective way to manage team cognitive load at scale, and they have a small number of team types whose role and responsibilities are clearly understood by their adjacent teams." Tellingly, 91% of highly evolved teams report a clear understanding of their responsibilities to other teams, compared to only 46% of low-evolution teams. In addition, 89% of highly evolved teams report members of their own team have clear roles, plans, and goals for their work, compared to just 46% of low-evolution teams.

Highly evolved teams worry less about corporate cultural issues that tend to hamstring DevOps efforts. It's not that they're less concerned about culture. Rather, they've created a technology stack that enables workflows and information to scale and move quickly to where it is needed. They moved to an approach that "leverages significant automation and invested in internal platforms," Kersten and McCarthy state. In short, for highly evolved firms, culture is no longer a barrier.

For example, the survey shows, 84% of highly evolved firms can elastically provision and release capabilities -- in some cases automatically -- to scale rapidly outward and inward commensurate with demand. Only 17% of low-evolution firms can scale elastically, the survey reports. Similarly, developers at 79% of highly evolved firms can provision computing capabilities, such as server time and network storage, as needed automatically -- versus only 16% of firms at the lowest level of DevOps evolution.