What is a DevOps Team?

Many managers and leaders in the IT industry today talk of leveraging the DevOps teams and gaining all the advantages that come with implementing DevOps. The reality is starkly daring and different. I am sorry to say that they have no idea what they are talking about.

We have DevOps as a methodology that brings together three massive areas of people, process and technology under a single umbrella to work as a cohesive unit. The term or concept of a DevOps team is a part of the people changes that we try to bring about in implementing DevOps methodology.

In my book Reinventing ITIL in the Age of DevOps, I go into the depth of what a DevOps team is all about and how it should be framed. In this post, I will try and put the thought out tersely.

A DevOps team is a single group of people who come together under a single roof (not literally although I wish it was the case) to manage a product end to end.

This is a 40,000 feet definition. Let me expand further on managing a product end to end.

Any product (software) needs growth. Growth is nothing but enhancements. In case of a COTS product, it could be upgrading with new releases. The product also will run into trouble every so often. Users will raise incidents and also there could be some service requests like new user accesses. So essentially, you have two major streams of work for any product:

1. Development of Enhancements
2. Resolution of Incidents and Fulfilment of Service Requests

A single team is expected to take care of both streams of work. Remember that people who work on enhancements have a different mindset from those who fix incidents. Yet, these two sets of people have to come together and work as a single unit. Actually it gets even worse. When we build DevOps teams, we don’t have any intention to label certain people to work on incidents alone and certain others to develop enhancements only. The real deal with a DevOps team is when everybody (read most of them) on the team are able to switch roles and carry out the work that needs to be done at that instant.

Let me give a classic example that I normally share during my training sessions. If there is a problem (not ITIL problem) with the product, who would be best suited to fix it? Let’s say that the problem faced by the user (s) is impacting the business badly and is costing them dollars every minute it is down. In other words, time is of essence. The faster this problem gets resolved, the business will stop losing money and will be happy.

So let me repeat my question, who is best suited to fix the problem – the person who developed it or the person who fixes incidents only based on the knowledge gained with 2 hours of KT?

You know the answer. That’s one of the prime reasons why the DevOps team does not segregate people based on the work they do. Don’t get me wrong. It is not wrong to designate certain people to responsibilities, but it is equally important that they be made aligned with the rule of flexibility of jumping into any kind of work at a drop of a hat. This is one of the reasons why organizational change management gets involved during the formation of a DevOps team.

Let me give another advantage of such a team where the development side of the product gets benefited through this arrangement.

Let’s say that during the good times (if there is), there are a handful of incidents which leaves the people manning the support work with few hours of spare time. This time can be leveraged in the development area, and can come quite handy in most sprints. This in fact serves another purpose. This support personnel who is working on development work is actually learning on the job, is trying to do something that the developers normally do. Say in about a few weeks or months, this support person can probably pick up complex coding work? People get better when they work shoulder to shoulder with others who have superior skillsets, and this is no different in a DevOps team. I am not putting the developers on the pedestal or degrading support personnel. Generally, juniors with fewer years of experience work in support, and those with have a number of years under their belts graduate to become developers. So in the same vein, a DevOps team can accelerate this graduation. Right?

The forming of a DevOps team is just one of the pieces in the game of DevOps. This alone cannot do wonders. Just by bringing people together under a single team structure will do more damage if the processes and technology are not designed and implemented as a cohesive unit.