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.
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.
This document will help application leaders looking to make remote agile teams successful by following the 10 practices set out in this research.
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.
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