Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News The Industry Just Can't Decide about DevOps Teams

The Industry Just Can't Decide about DevOps Teams

The incidence of DevOps teams is on the rise according to reports, but the industry remains divided on whether a DevOps team should even exist. Some are wary of creating additional silos, or are of the opinion that DevOps is a methodology that everyone should subscribe to in an organisation; others point to DevOps teams as an effective way of transitioning to a new way of working.

The sixth annual State of DevOps Report was published in June reporting on empirical data gathered from 27,000 survey responses. The report stated that:

As DevOps evolves and spreads, we've noticed that the percentage of people working on DevOps teams increases each year. In 2014, 16 percent of our respondents worked on DevOps teams. Three years later, 27 percent of respondents work on such a team.

The State of DevOps Reports do not describe what a DevOps team is, however, Matthew Skelton and Manuel Pais explore the topic at Team topologies in which DevOps can be made to work that have been observed include:

  1. Dev and Ops collaboration (the "promised land")
  2. Fully shared Ops responsibilities
  3. Ops as Infrastructure-as-a-Service
  4. DevOps as an external service
  5. DevOps team with an expiry date
  6. DevOps evangelists team
  7. SRE team (Google model)
  8. Container-driven collaboration
  9. Dev and DBA collaboration

But a recent article from Anouska Streets, head of engineering at Finkit, discourages the creation of a DevOps team:

Dedicating one team to DevOps or adopting the tools doesn't mean you're doing it right. Everyone from the CEO down needs to be on board to really do DevOps.

This concept of "DevOps is not one person's job, it's everyone's job" is increasingly prevalent in the industry and closely linked to the conversation around whether DevOps is, or should be, included within a job title; as Pete Cheslock, director of operations and support at Threat Stack says in his article, 'DevOps in Your Job Title Is Doing You Harm':

The reality is that DevOps is a culture that should be accepted by every facet of your organization. Everyone needs to embrace the changes of a DevOps culture, and there cannot be a single owner of it.

However, some still argue that DevOps job titles, particularly the DevOps engineer, have a place. Spike Morelli, founder of SpikeLab, ex-Googler and teaching assistant at Stanford University's Technology Entrepreneurship MOOC, says:

DevOps isn't the job title, DevOps engineer is, and in this sense DevOps is just a qualifier.

Rajat Bhargava, CEO of JumpCloud Inc, does not agree and makes several points to explain his position:

DevOps is a methodology not a job description – we don't call our developers agile engineers, they are just developers. They happen to follow the agile methodology but their job description isn't to do agile, it's to create awesome products.

DevOps should permeate an organization – having a DevOps group sort of missed the point of DevOps. DevOps should be embedded into the fabric of the company, not an adjunct to the development process. If it isn't embedded how can you actually practice DevOps?

So there is a contradiction in the DevOps market - the evidence for an increasing number of organisations standing up DevOps teams flies in the face of opinions that DevOps teams are a bad thing. The authors of the State of DevOps Report make the following observation on the increase in DevOps teams:

We feel this increase represents both an acknowledgement that DevOps works, and the fact that DevOps teams represent a strategy for shifting the entire organization from older ways of working to newer DevOps processes.

This backlash against DevOps teams isn't new; Jez Humble (also one of the authors of the State of DevOps Reports as well as Continuous Delivery, Lean Enterprise and The DevOps Handbook) claimed 'There's No Such Thing as DevOps Teams' back in 2012:

...the DevOps movement addresses the dysfunction that results from organizations composed of functional silos. Thus, creating another functional silo that sits between dev and ops is clearly a poor (and ironic) way to try and solve these problems. DevOps proposes instead strategies to create better collaboration between functional silos, or doing away with the functional silos altogether and creating cross-functional teams (or some combination of these approaches).

InfoQ checked with Humble and he still holds this view in 2017. Humble strongly agrees with the point Streets makes. However, there are times that Humble believes we can talk about DevOps teams:

For developers to take responsibility for the systems they create, they need support from operations to understand how to build reliable software that can be continuous deployed to an unreliable platform that scales horizontally. They need to be able to self-service environments and deployments. They need to understand how to write testable, maintainable code. They need to know how to do packaging, deployment, and post-deployment support. Somebody needs to support the developers in this, and if you want to call the people who do that the "DevOps team", then I'm OK with that.

Alanna Brown, director of product marketing at Puppet says that:

Dedicated DevOps teams are often made up of experienced operations people with a mix of skills including using version control, writing infrastructure as code, and continuous delivery. These teams typically start by addressing the things that are most painful, such as deployment automation, and if they're successful, can evolve to providing shared services for the rest of the organization.

And despite the general opinion that DevOps teams are an antipattern, the same article also notes a positive correlation between a DevOps team and the performance of the IT organisation:

One surprise in our 2014 State of DevOps Report was that 16 percent of respondents identified themselves as working specifically in a DevOps department, and 90 percent of those DevOps team members were working in high- or medium-performing IT organizations.

Michael Coté at Pivotal works through the roles and responsibilities in agile and DevOps teams (for clarity, Coté sees 'DevOps as inclusive of "agile"'):

There are generally two types of teams we see: "business capabilities teams" who work on the actual software or services ("the application") in question and "agile operations teams...

Coté doesn't describe the work that the agile operations teams do, but his diagram represents effort around platform engineering, site reliability and infrastructure for the production PAAS.

DevOps teams are on the increase whether or not the industry agrees this is the right approach to evolving DevOps capabilities across an organisation. Do you think the trend will continue and, more importantly, do you think it should?

Rate this Article