Even if Agile approaches favor collocated teams, distributed Scrum teams are more common that what you might think. Many Agile software development teams are based on a virtual organization.
Its increasingly common that Agile software development teams are distributed across multiple offices, in different countries, all working remotely on the same product or project. But how do you make this work well? There seem to be a number of readily accepted tenants of conventional wisdom to help deal with leading distributed teams, from seeming good ideas “teams must be co-located” to ones that are purely economic “offshore teams can be run at a far lower cost”.
Agile approaches like Scrum recommend a “just enough” attitude in software development and this is also the case when you discuss tools. Ideally, you would work with a small team that is collocated, but this is not always possible and you might be running your project virtually with a distributed Scrum team scattered around the world.
As Agile practitioners, we’ve learned to love highly cohesive, cross-functional on-site teams. These teams, much like monolithic applications; succeed due to the proximity of useful knowledge. Distributed Scrum teams must rely on different strategies and tactics in order to be effective while still adhering to the principles laid out in the Agile Manifesto.
Pair programming is one of the original practice of eXtreme programming, but it is also one of the least used by Agile software development teams. In his blog post, Alisdair McDiarmid explains how Customer.io uses pair programming with remote teams.
The retrospective is one of 12 principles outlined in the Agile Manifesto. If this is easy to do this for collocated Scrum teams, how can you achieve good results if you have remote members. In this blog post, Robert Matheson provides a valuable collaborative retrospective technique that can be used for distributed Scrum teams.
In large Agile projects where a Scrum team cannot deliver the full system, you have different options to organize your team. You can use feature teams that work on a set of user stories or component teams that work on a subsystem or component. In his blog post, Michael Valenta reports his experience as a ScrumMaster from the usage of features teams.