Gartner Research

Setting Up Remote Agile in a Hurry?

Published: 02 April 2020

ID: G00723617

Analyst(s): Neil Barton

Summary

The rapid spread of COVID-19 means that many agile teams are being forced to switch from colocated workspaces to remote working. Application leaders and their service providers can make this successful by following the practices set out in this note.

Overview

Key Findings
  • Remote agile is more common than you might think, but it requires particular attention to agile practices to make it work.

  • While colocated agile teams are the ideal, the next best approach is the type of remote agile in which every member of the team is in a different location.

Recommendations

This document will help application leaders looking to make remote agile teams successful by following the 10 practices set out in this research.

Analysis

The rapid imposition of social distancing to combat COVID-19 has a particular impact on agile software development teams.

Many agile practitioners recommend that teams are colocated; that is, everyone in the team sits in the same physical workspace. This principle was established in the 2001 Agile Manifesto, which states, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Gartner strongly believes in this principle and recommends colocating agile teams as much as possible. However, during the COVID-19 pandemic, many countries have rapidly imposed social distancing rules that prevent team members from going to the office. For example, many offshore development centers in India are asking their staff to work from home (see “Coronavirus: Bengaluru Shuts Down; Firms Ask Employees to Work From Home”). Overnight, colocated agile teams are becoming remote agile teams, whether they like it or not.

Remote agile is much more common than one might think. As far back as 2016, a Gartner survey quoted in showed that 60% of organizations that have implemented agile at scale also use remote teams. In 2019, CollabNet’s “13th Annual State of Agile Survey” reported that 78% of respondents said their organization practices agile with team members not colocated.

Over the years, a substantial body of academic research and technology blogs have been published on this topic. This has created a confusing terminology. The term “distributed scrum” has been used by Jeff Sutherland since 2007, and distributed has also been used by agile thought leaders such as Martin Fowler and Scott Ambler. Since then, the terms dispersed, “hub” and “remote” have emerged. In 2019, authors Johanna Rothman and Mark Kilby added “satellite,” “cluster” and “nebula” to the list in their book “From Chaos to Successful Distributed Agile Teams.”

There is no industry standard definition of these terms, but Figure 1 shows the three main choices for locating agile team members.

Figure 1. Three Ways Agile Team Members Can Be Located

A further complication is that after 20 years of globalization, organizations often find that even if all members of a team are in the same location (Type A), different teams are in different locations,especially in enterprise agile environments (see ).

Much is therefore known about the best way to manage agile with remote teams, especially considering that collaboration tools and video conferencing have made huge advances in the 20 years since the Agile Manifesto recommended “face to face” conversations. This research provides a summary of the key practices.

Although colocation for agile teams has often been strongly recommended, there are two factors that should give teams confidence when moving to remote agile.

The first is to understand why remote agile has sometimes failed in the past: large time differences. Some organizations have implemented Type B remote agile (see Figure 1) where team members are in very different time zones. No matter how good the collaboration and conferencing tools, if there is a time difference of more than four hours between team members, there is less time to talk during normal working hours. If the product backlog is stable and well-refined, time differences can be made to work to the team’s advantage so that, for example, work can be defined during the U.S. working day and developed overnight in India or Eastern Europe. However, this will not work for teams where the product backlog changes frequently, such as when a team is exploring or experimenting to see which features customers like best. Some Indian development centers have their software engineers work a night shift to create overlap with U.S. customers. However, this is not a sustainable solution for the engineers’ welfare.

Luckily, time zone problems are unlikely to be created by a team moving rapidly from colocated to remote working because of COVID-19. Team members are most likely to be working from home in the same city as their office and other team members.

A second challenge with Type B remote agile is caused when some team members can communicate face to face while the remote team members may feel isolated and out of touch. With a Type C team, all working from home, this inequality does not occur.

There are many agile teams that have been successfully using Type C remote agile for many years. For example:

  • 18F, a U.S. government consultancy, has a “remote first mindset” — delivering with onshore teams in distributed federal offices or even home offices.

  • GitLab develops and sells a respected DevOps life cycle tool with repository, wiki, issue tracking and continuous integration/continuous delivery pipeline features. It claims to be the world’s largest all-remote company, with over 1,200 team members in more than 65 countries, and it has published a remote working manifesto.

  • Automattic has developed WordPress, a widely respected web content management product, using Type C remote agile.

  • Microsoft has published its experience of having tens of thousands of employees work remotely.

Numerous other examples were publicized in November 2019 at the Remote Forever Summit, an online resource of presentations and workshops with extensive coverage of remote agile.

A 2009 Sloane Management Review article concluded that “Dispersed teams can actually outperform groups that are colocated … if managed in specific ways.” When it is necessary to use remote agile teams, the approach most likely to succeed is the Type C approach in which every team member is in a different place.

Gartner Recommended Reading

Evidence

“How to Manage Virtual Teams,” MIT Sloan Management Review.

©2021 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. and its affiliates. This publication may not be reproduced or distributed in any form without Gartner’s prior written permission. It consists of the opinions of Gartner’s research organization, which should not be construed as statements of fact. While the information contained in this publication has been obtained from sources believed to be reliable, Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Although Gartner research may address legal and financial issues, Gartner does not provide legal or investment advice and its research should not be construed or used as such. Your access and use of this publication are governed by Gartner’s Usage Policy. Gartner prides itself on its reputation for independence and objectivity. Its research is produced independently by its research organization without input or influence from any third party. For further information, see Guiding Principles on Independence and Objectivity.

Already have a Gartner Account?

Become a client

Learn how to access this content as a Gartner client.