Can devops be delivered in a distributed labor model?

Companies frequently ask us at Everest Group if the benefits a devops team can be delivered in a distributed labor model. In other words, can a company configure a devops team to operate with part of the team in one onshore location and other part of the offshore or in a different onshore location? To be clear, there is currently a significant debate around this question. Many tech companies and new service providers emphatically say devops can’t work in a distributed model. But legacy service providers with large investments in offshore talent factories argue that It absolutely can work and point to examples in which they are utilizing components of a devops model in an offshore and distributed manner. 

Legacy service providers have a strong vested interest in maintaining their current offshore factories, which are highly leveraged with cheap junior resources and are working hard to persuade their customers that the offshore models only need an injection of devops technology. However, none of them appear to be running at the productivity level – or even close to the level – of devops teams that are not in a distributed model. 

Two aspects that set the high-performing devops teams apart are their location (or degree of separation) and the fact that they are persistent teams. Let’s examine how these aspects affect productivity. 

Two pizzas and one Nerf ball 

In a conversation I had with senior people in Azure development devops teams at Microsoft, we locked in on the ideal size and location of the teams. They mentioned a company should be able to feed a devops team with two boxes of pizzas. That means the team needs to be between 8-16 people. 

Continuing our conversation, I added the parameter of one nerf ball. In other words, team members should be collocated close enough together in an open environment where anyone sitting in that environment can hit someone else on the team with a Nerf ball. 

Naturally, companies want teams that operate at a high productivity level. This means they need to be cross-functional, interacting between operations and development, and they must stay in constant communication with one another. Members of large teams cannot communication in this intense manner, so their pace is slower. But a company could break up a large team into smaller teams focusing on sprints that can be managed by the smaller team. 

There is no doubt a company can inject the same technology and methodologies (such as self-provisioning, agile, cloud) into a traditional IT organization or a distributed model. But this construct only enables an incremental impact; it won’t enable a breakthrough impact in performance. The two-pizzas size and one Nerf ball location are essential for achieving breakthrough performance. 

Learning curve impact 

The other aspect to establishing a high-performing devops team is that it must be a persistent team – one that stays together. The traditional IT factory model, whether delivering services onshore internally or with third parties, assembles teams for specific projects to conduct a project. In contrast to this project orientation, a devops team is journey oriented. It continues to support and drive forward a set of functionalities throughout an ongoing journey to achieve breakthrough performance. 

The traditional, project-oriented model is very wasteful. The company spends a lot of time forming teams with qualified skills and equipping them with accelerators such as a cloud environment and agile methodology. But much of the time is spent coming down the learning curve: assembling the team, normalizing the team, understanding the new environment, building the requirements. Only a small portion of time focuses on delivering on the promise. And churning those teams, either bringing in outside consultants or from a leveraged bench of talent, basically wastes tremendous time on the learning curve. 

Again, in contrast, that cycle time collapses in a devops team model because the people who built the original kernel understand that environment. A persistent team is much better at aligning with the business objectives. 

Cost factor 

As I said before, the team in that construct will not run anywhere close to the possible productivity level. devops teams that are small, collocated close together and are persistent, staying together beyond completing a project, operate at many times the speed and at many times the productivity of the traditional model. Consequently, they also operate at a much lower cost than a leveraged factory model. 

So, can your company run a devops team in a distributed model? Definitely. But not optimally. So, why do that?