Distributed Scrum

There are three Distributed Scrum Team configurations. Fully-integrated Teams can achieve the best results, but any of the three configurations can be effective if implemented and maintained with rigor. The common variable in deciding which configuration will work best for your organization is communication. How much do the geographically divided Team members need to coordinate to create a deliverable product every Sprint?

Isolated Scrum Team: Like any Scrum Team, an isolated Team should be cross functional, self-organized, and self-managed. It should also have all the skill sets necessary for delivering product at the end of each Sprint. However, they are working from their own Product Backlog and don’t have any common rituals such as Sprint Planning meetings and Retrospectives with the larger organization. Google’s Ad Words functions this way. Each team serves a specific market very effectively but they don’t have a formal collaborative relationship with each other.

For Google’s purposes, this configuration works fine (they generate 90% of Google’s revenue) and depending upon your companies needs, it may work well for you too. However, there are some major drawbacks. Isolating teams in this way can exacerbate cross-cultural communication issues. Commonly, outsourced teams might not even be using Scrum, and their productivity and rhythm can be more akin to typical waterfall projects. This makes communication and transparency with the home organization extremely challenging and may make the business case for outsourcing a bit dubious. This configuration only works when there is little need for the Scrum Teams to collaborate.

Overlapping Scrum Teams with shared Scrum of Scrums can help minimize cross-cultural and communication issues by linking the remote teams through a Scrum of Scrums.This allows the Teams to be in multiple-locations but work on a common project through the Chief Product Owner coordinating efforts between all Scrum Masters. These teams also share a common Product Backlog to coordinate their work. Jeff explains the Scrum of Scrums nicely in the video.

For example, if the Teams were designing a software suite that combines audio, video and text editing, perhaps one Scrum Team would be in charge of developing the video interface while another Team would be responsible for designing the text editor. Each Team would still be capable of delivering a feature set at the end of the Sprint but because the Product Owner is working from one Product Backlog and the Scrum Masters from each Team coordinate with each other as much as necessary, no Team is creating impediments for the others and the code integrates as the Team expects.

There is no formula for the Scrum of Scrums. Perhaps the graphic designers need to meet monthly, the testers weekly and the Product Owner talks daily with the Scrum Masters. The point is for the Teams to reach a certain level of communication saturation that allows them to efficiently coordinate their work.

Integrated Scrums work from the same Sprint and Product Backlog. This can be the most efficient, but also most challenging distribution model, where individual team members are at multiple locations. The best practice is to have roughly half the team in one location and the other half in another so each location has critical mass. Each part of the team should include cross-functional members to mitigate the risk that progress will be held up because someone with a critical skill is in another time zone or geography. Finally, it is important to allow distributed teams to form and gel like co-located teams. Bringing the two halves of the team together for the first few Sprints can facilitate this process.

Scrum Inc. has used this integrated configuration to deliver almost the same performance results as Teams located in the same place.