• LinkedIn
  • YouTube
  • RSS

Distributed Scrum

Distributed Teams almost always deliver product slower, with more bugs, and higher costs. However, globalization makes working in different locations a reality, so in this online course we outline a number techniques that will minimize the costs.

Estimated time for this course: 65 minutes
Audience: Advanced
Suggested Prerequisites: Scrum at Scale, RetrospectiveScrum Master

Upon completion you will:

  • Understand the costs of distribution
  • Know the warning signs of disfunction caused by distribution
  • Learn several patterns to facilitate successful distributed Scrum
  • Qualify for PMI PDUs. See FAQ for details
Distributed Scrum Overview:
Distributed Scrum teams are inherently problematic. Whether it is one team spread across geographies, or separate teams using a single backlog, it just isn’t easy. In fact, our first recommendation is don’t do it, the productivity costs almost always outweighs the savings.

Unfortunately, the globalized economy is not aligned with best Scrum practices. We know organizations are going to spread their teams across a variety of locations regardless of what the research says.

The question then becomes: can distributed teams match the performance of co-located teams? The answer is yes, but it’s tricky. In this course we share the patterns that are found among successful implementations.

View and Download Class Slides

Download Distributed Scrum slides

Three ways of doing 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.

sign up for scrum inc. news

Stay Connected

The market changes fast. Here’s how to stay ahead…

Join a community of over 40K+ subscribers who receive the latest in Scrum industry news, emerging thoughts and community updates from the Scrum Inc. Team.

You have successfully subscribed, welcome!