Course Info

goodagile Customer List
goodagile Attendee Feedback
goodagile Scrum Certification
goodagile Pricing and Payment
goodagile Contact Us

The Distributed Scrum Primer

 Download The Distributed Scrum Primer 1.0

[Part 1] [Part 2] [Part 3] [Part 4]
In a distributed environment, all the standard practices of Scrum – the roles, meetings, and artifacts – are present. However, it may be necessary to adjust how those practices are implemented, to overcome differences in timezone and geographic location.
There is no "best" Sprint length to use, either in a co-located or a distributed environment. Longer Sprints (3 or 4 weeks) enable teams to produce larger increments of functionality each Sprint, and Sprint Planning and Review / Retrospective (which typically involve early morning or evening meetings for everyone involved) occur less frequently. Unfortunately, both of these benefits can create other drawbacks. Because of the communication problems that flow from having the participants in different locations, it is far more common to discover misunderstood requirements when we reach the Sprint Review. In a 4-week Sprint, it is possible that twice as much of the "wrong" functionality will have been built than would have been built in a 2-week Sprint. Additionally, a 4-week Sprint offers half the frequency of inspect-and-adapt cycles for the team's practices, so many teams find they have fewer opportunities to surface and address dysfunctions.

One solution is to start with 2-week Sprints, and focus initially on mastering the ability to deliver increments of potentially shippable product (possibly very small ones) by the end of a Sprint. A number of Sprints' worth of inspect-and-adapt may be required for the team to achieve this, but once they have succeeded, they can shift to a longer Sprint length, and be able to deliver larger, more satisfying increments of functionality.

The Product Owner
One common distributed Scrum configuration is to have a Product Owner in one geographic location, and the team in one or more other locations. It becomes even more important to have an actively involved and committed Product Owner in this situation. Often, organizations will select an individual in the same location as the team and put them in the role of "Proxy Product Owner," to provide guidance to the team when the actual Product Owner is not available. This can work, but it often brings with it a new set of challenges; the proxy will rarely have the depth of domain expertise or the decision-making authority to give definitive answers to the team, and the risk is that they give answers that are later reversed by the "true" Product Owner (resulting in wasted effort and discouragement for the team), or they serve purely as an intermediary between the team and the "true" Product Owner, which dramatically slows response times, and introduces errors and misunderstandings in both directions. If there is a proxy working with the team, it is probably important to still maintain a daily flow of questions and answers between the team and the "true" Product Owner – for example, by agreeing on a 30-minute overlap between the Product Owner's and the team's working hours, during which time either can phone the other with questions, or having the ScrumMaster compile and email the Product Owner at the end of each day a list of open questions, which ideally the Product Owner will have guidance waiting when the team returns to the office the next day.
The ScrumMaster
The role of the ScrumMaster becomes even more critical in a distributed project, because the "dysfunctions of distance" – for example, the difficulty of communication -- require an even more active and tenacious commitment to openness and inspect-and-adapt. Day-to-day, distributed projects also tend to have a greater-than-usual load of impediments, obstacles, and disruptions that will require the ScrumMaster's attention and effort.

If the Product Owner is in one location and the team is in the other, the ScrumMaster should be located where the team is. While an onshore ScrumMaster may be able to help an offshore team with some types of issues, he or she will unfortunately be entirely absent from the realities of the team's day-to-day worklife, and thus they will be far less useful to the team. The critical ScrumMaster duties of coaching the team, helping remove impediments, and protecting the team from disruption will essentially be absent if the ScrumMaster is located far from the team.

If the team itself is divided between multiple locations, there should be a primary ScrumMaster designated for the team overall, but it will probably be helpful for each location to have a team-member playing the role of "local" ScrumMaster during that location's working hours.

The Team
When the team itself is split between multiple locations – for example, several team members are located in China, and several team members are located in the US – the challenges of development are often multiplied further. The level of coordination, cooperation, and team-work that is necessary to deliver working software every 4 weeks or less is even more demanding. While there are case studies that describe exceptional results with this model, it takes real commitment and a significant investment in the working relationships, skills, and tools used by the various team members to deliver that level of success.

To begin with, team members will typically need to spend periods of time working side-by-side with each other, especially at the beginning of the project. An excellent practice is for the team to be colocated for the entire first Sprint of the project, and ideally the first two or three Sprints. This allows the individual developers to build working relationships with each other, as well as trust and visibility into each others' skills, strengths and weaknesses. In addition, the team will develop a set of working agreements and set standards for their "definition of done," quality, coding conventions and other development practices, tools, escalation, overlapping work hours, and other necessities.

In addition to colocating the team for the first Sprint or more, the distributed teams that succeed with Scrum typically have some sort of "ambassadorship" practice, where team-members are constantly traveling to the other location for periods of time working side-by-side with their distant colleagues. When these "ambassadors" return home, they bring with them knowledge and values that will inform the work of their local colleagues, and they will also be able to function as points of contact for their remote colleagues when issues arise. This ambassadorship is ideally a continuous practice, with one team member placed at the other location at all times, in rotation.

The immediate objection to this constant travel is "it will cost money and time!" The simple response: Yes, but it is cheaper than the alternative, which is getting much less business value from the project. Without face-to-face contact and high-quality working relationships, the team will produce either less software, lower quality software, or functionality that's less right for the customer needs – or all three. A team of 6 developers with a generous travel budget will probably produce much more business value than a team of 7 developers with no travel budget.

A common dysfunction when the team itself is split between two locations and are not properly bonded is that "one team" actually operates as two teams. Team-members may form "cliques" by location, and miscommunication or miscoordination between the locations may give rise to mistrust and conflict. It is also possible that if a portion of the team is located onshore, they will be in closer communication with the Product Owner, and as a result they will have an information advantage over the offshore developers. While one would hope that this could benefit the entire team, it can sometimes do the opposite, driving a wedge between the two groups of developers, with the offshore group being seen by onshore as clueless and always a step behind, and the onshore group being seen by offshore as hoarding knowledge and looking out only for themselves.

Rather than trying to work as a single team, it may be more effective to form into separate Scrum teams, one per location, and as loosely coupled with each other as possible. Each team should be fully cross-functional, and should be responsible for producing entire pieces of functionality, not simply doing a particular activity (coding, testing, etc.).

Technical Practices
In addition to strong working relationships and effective communication, there are a number of other practices which are helpful for the success of teams doing Scrum in a distributed environment.

For teams that are split between multiple locations, it is very important that all team members have the same development environment (same IDE's, plug-ins, code quality checking configurations, etc.), and work on shared DTAP (Development Test Acceptance and Production) servers; this removes ambiguities and reduces problems caused by inconsistencies between the locations.

As is true for colocated Scrum teams, the practice of Continuous Integration is extremely helpful. In Continuous Integration, new or changed code is integrated early and often; commits trigger an automated build-and-test cycle, allowing integration problems to be detected and corrected immediately. By doing this frequently and with small increments of change, problems can be found when they are smaller and more manageable, so less time overall is spent in the finding-and-fixing activities. It is important of course to have the discipline to immediately resolve the issues, and many teams agree on conventions, such as "you can't leave the office with a bad build unfixed"; the last thing the developers on the other side of the globe want is to start their day with this problem. Continuous Integration also enables a less rigid and more emergent approach to defining and building interfaces; with more confidence in their ability to find and fix problems quickly, teams can be more dynamic in the way they work, and work together more smoothly.

It is important that the required knowledge, capabilities, and skill levels are evenly distributed across both locations; an imbalance will possibly result in less value produced each Sprint. For example, having senior architects and designers onshore and junior developers offshore will likely result in a lot less software being produced, and a much more dysfunctional relationship between the two locations, than if a more experienced team was recruited offshore. In the event there are skills or capabilities which cannot be shared across both locations, this should be made clear and visible to all stakeholders as a possible impediment.

When deciding who works on what during a Sprint, it's important that team members from one side not take all the work in a particular area on a regular basis; for example, onshore team members always taking UI tasks, while offshore team members always working on back-end services. While this may sound like a simpler approach initially, it generally results in silos that undermine the "shared responsibility and ownership" mindset of the team.

When the team is physically split, real-time communication tools becomes critically important. At a minimum, teams require the following:

  • Instant Messaging client (not only for communication and easy transfer of text, but also for indicating their presence online to other team members)
  • Comfortable, high-quality headset and VOIP client, to make conversations with remote team-mates quick, easy, and free (with "always on" as an option)
  • Webcam and Skype, for instant videoconferencing
  • Shared digital whiteboard, for design and architecture discussions
  • Desktop sharing solution (for example, a VNC client)
  • Team wiki (with not only project details but also personal info about each team member)
  • Shared bug tracker
  • Team calendar, showing release dates, Sprint dates, local holidays, and vacation plans
  • Team mailing list, to which all key emails are cc:ed.
  • Build status alerting device (such as Nabaztag) at all distributed locations

(The upcoming Scrum Technical Practices Primer will provide more in-depth explanation and guidance around the tools, practices, and techniques referenced in this section.)

Sprint Planning Meeting
One of the practical conflicts in distributed Scrum is the fact that (a) more time is typically needed to properly complete the Sprint Planning, Review, and Retrospective meetings than in a colocated environment, and (b) we often have less time available for these meetings (due to lack of timezone overlap). This is less of an issue for projects between Europe and Asia, for example, but for the US and Asia, it can become a real impediment to success.

One approach that can help is to split the longest of the meetings – Sprint Planning – into 3 shorter sessions over the span of two days, as follows:

  • Sprint Planning Part 1 - (1 hour timeboxed) - Weds 8am New York / 6:30pm India. Product Owner walks the team through the items at the top of the Product Backlog, team asks questions, clarifies their understanding, and make suggestions.
  • Sprint Planning Part 2a - (2-3 hours) - Thurs India workday hours. Team starts doing an initial analysis, task breakdown, and estimation of the items at the top of the Product Backlog. They come up with a list of questions for the Product Owner.
  • Sprint Planning Part 2b - (1 hour timeboxed) - Thurs 8am New York / 6:30pm India. Team and Product Owner discuss the team's open questions, and the team decides their commitment for the Sprint
  • Work begins - Friday India workday hours.

On the days when the team will be staying late for the evening meetings, it is important that they maintain a reasonable workday by coming into the office later in the day than they would normally; a recurring schedule of 12-hour days will very quickly start to exhaust the team, and cause productivity and morale to drop, and mistake rates to go up.

Sprint Planning part 2 is typically also be used for design discussions, to review of major component changes, and other issues. This allows everyone to express their thoughts, and also helps in establishing a clearer vision for the implementation, which should result in more consistent quality from everyone.

Lastly, many teams find it very helpful to budget a generous amount of time during the Sprint for doing Product Backlog Refinement (aka Grooming) with the Product Owner. Together, they look ahead to upcoming Product Backlog items, gain a clearer understanding of them, split larger Product Backlog items in smaller pieces, and prepare them to be considered in the next Sprint Planning meeting; the more time spent on these activities, the more easily and quickly the next Sprint Planning will go.

Daily Scrum Meeting
If the team is colocated together, and the Product Owner is in a different location, the first question is whether the Product Owner should be invited to join the team's Daily Scrum Meeting. There are pro's and con's to this. Some teams find it helpful to have the Product Owner join the meeting, so he or she is aware of their impediments on a day-to-day basis, and to have a window of time after the meeting each day for live discussion with the Product Owner. However, there can also be downsides to having the Product Owner join. It often costs precious minutes each day, as either for the team or the Product Owner waits for the other to join the meeting. Having the Product Owner joining the Daily Scrum Meeting can also make the team feel like they're being monitored and overseen, and this adds pressure and stress, invites micromanagement, and can reduce the team's sense of responsibility and self-organization. Third, if due to the presence of the Product Owner the call has to take place in the evening hours for the team, it will hurt morale and significantly accelerate burnout, with the end result of much less business value being produced. If the Product Owner is anxious to know how the Sprint is progressing, it may be much less disruptive to have the ScrumMaster simply email a camera-phone photo of the team's Sprint Burndown Chart.

If the team itself is in different locations, the ideal is to hold the Daily Scrum Meeting live via webcam each day, at a working hour that overlaps for both teams; this is feasible between Europe and India, or West Coast USA and China. If there is no working hour that overlaps, here are several options to try:

  • Hold the Daily Scrum meeting live via webcam or conference call each day at an hour that is inconvenient for one side or the other. It is very important to rotate the burden of the inconvenience from one side to the other every week or two. The main downside of this approach is the daily outside-regular-work-hours for one part of the team; this will likely add stress, hurt morale, and reduce productivity over time. If this option is chosen, be mindful of different cultures' meal-schedules; for example, in the US, it is common to eat dinner around 7 or 8pm, while in India, it is more typical for dinner to take place at 9 or 10pm.)
  • Hold the Daily Scrum meeting live in each location at a time that's convenient for that location, but have one team member write a summary of the updates, and email them to a team-member in the other location, to read aloud at the start of their Daily Scrum meeting.
  • Hold the Daily Scrum meeting using recorded reports. The team members in each location will do their Daily Scrum meeting at a time that is convenient for them. At the start of the meeting, they will use a cameraphone to record video of their updates, and the video will be emailed to the teammates in the other time zone, and played at their next Daily Scrum meeting. Repeat in reverse.
Sprint Review
Sprint Reviews serve the same purpose for a distributed Scrum project as they do for a colocated one: To enable the Product Owner and team to inspect and adapt what has been produced in the current Sprint, and collaborate about what could be done next. In a distributed Scrum, features may be less "right" the first time they're shown, because clear and complete communication between the Product Owner and the team is made more difficult by the distance. This is one of the realities of distributed development, and the Product Owner should build into the release plan buffer to account for the additional rework that will be required, as items are placed back onto the Product Backlog for improvement.

It is very important that the Sprint Review be planned for a time when the entire team – including all onshore and offshore members – can participate together. All members of the team should feel like full participants in the Sprint Review, and should be able to hear first-hand the comments about has been produced, share their own opinions, and join in the discussion. Ideally, the demoing of the new functionality should be done by team members from both the onshore and offshore locations. Having the onshore team demo everything can often create negative feelings for the offshore team members, who may feel like they're not receiving recognition for their work or are being treated like "second-class" team-members.

Sprint Retrospective
The purpose of the Sprint Retrospective is for the team, the Product Owner, and the ScrumMaster to discuss their experiences and observations from the current Sprint, identify issues and areas for improvement, and agree on changes to make to their way of working to produce better results in the next Sprint. The more distributed the team, the more issues there will be – and thus, the more thorough and effective the Sprint Retrospective needs to be. The most successful Scrum Teams focus on the "learning" or "experimental" mindset that Scrum enables: identifying problems as quickly as possible, and then "testing" a practical solution in the very next Sprint. Rather than agonizing over what is the best possible way to do something, think of the simplest thing that could work and try it for a Sprint. Shorter-length Sprints may accelerate these improvements, by enabling more rapid cycles of inspect and adapt.

As in colocated Scrum projects, the Retrospective should include the Product Owner; many dysfunctions will play out between the Product Owner and the team, and excluding the Product Owner from the Retrospective will significantly hinder improvement. In addition, it's very important for the Retrospective to be visual (via videoconference); the subtle cues of facial expression and body language become even more important in difficult conversations.

In a distributed Scrum project, more written artifacts will typically be used, but just how much and what format should be left to the Product Owner and team to determine. This should not be taken to mean that the written detail is all that is required. Indeed, the presence of more written detail will often mean that more conversation – not less – will be required between the Product Owner and team to achieve an effective shared understanding. The additional written detail simply gives the team a reference tool for answering questions when the Product Owner is not immediately available.

With distributed Scrum teams, aim to share a common vision and break the work into small packages that are easier to inspect and adapt, thus reducing confusion and finding misunderstandings sooner. Product Backlog Items should be short and easy to understand, with clear conditions of satisfaction attached. Pictures in the form of sketches, diagrams and simple mockups can convey a lot of information quickly. While User Stories are a popular and effective format for articulating Product Backlog items, lightweight use cases can also work well. Some teams find that having a demo server where the Product Owner can review functionality on a daily basis can help keep everyone in sync and aligned, and surface misunderstandings sooner.

There are difference approaches to managing the various Scrum artifacts. If the team is colocated, and the Product Owner is in a different location, paper may still be the best choice for the Sprint artifacts (for example, the Sprint Backlog and Sprint Burndown Chart used by the team to manage their work during the Sprint), but some type of electronic tool may be necessary for storing the Product Backlog; for example, using a Wiki or a Google docs spreadsheet may be a simple, very low-cost solution. If the team itself is distributed, or if multiple teams in different locations are working together, a more elaborate electronic Scrum information tool will likely be necessary. In every case, though, the thinking should be driven by the dictum "try the simplest thing that could possibly work, and inspect and adapt". For example, many teams find it helpful to document their agreements with the Product Owner (for example, from a conference call) with some type of written confirmation. A fast, simple way to do this would be to send the Product Owner an email with the subject line "agreements – conf call – aug 11," with a very brief, bullet-pointed list in the body; the email would be cc:ed to a team blog, so everyone could refer back to it.

Product Backlog Refinement
Distributed teams find it particularly important to devote time during the Sprint (typically 5-10% of their availability) to work on Product Backlog Refinement with the Product Owner. New items and items that have changed significantly will be estimated by the team, large items rising in priority will be split into smaller items, and the team will have time to start thinking about how they will approach upcoming Sprints' work. Items that are unclear or too big can be given back to the Product Owner to refine further, and when there is a difficult technical issue or uncertainty, the team can plan a "spike" within an upcoming Sprint to do technical exploration, and gain enough of an understanding to estimate and later implement the item.
Scrum of Scrums
When multiple Scrum teams in different locations are working together on a project, there are three commonly used techniques for coordinating their efforts, all of which can be used together.

The first is enabling and encouraging informal, lateral communication between members of different teams. This is often overlooked, but it is one of the most powerful tools for day-to-day effectiveness. When a team or team-member is blocked by another team, their first step should be to reach out to someone on that team, and this should be made as easy as possible. There should be a project-wide Wiki set up, that everyone on the project has access to. Under each team is listed team-member contact info (including email but also IM, VOIP and mobile phone numbers, plus typical working hours and urgent question contact hours translated into the various teams' timezones) as well their particular domains or areas of expertise.

The second technique is Scrum of Scrums. This is a practice where a representative of each team (selected by their team-mates) meets with the other teams' representatives on a regular schedule (typically 2-3 times per week, but it could be daily if necessary) to update each other on progress, surface and resolve inter-team blocks and dependencies, make cross-team technical decisions, and otherwise provide a forum for cross-project visibility and impediment resolution. When teams are in significantly different timezones, it is important that the Scrum of Scrums meeting time be rotated, so that the pain of late-night calls is shared among all the participants; having a subset of the group perpetually more inconvenienced than others can breed resentment that will often start to manifest in other kinds of dysfunction.

The third technique is to establish cross-geographic "communities of practice," to enable team members with particular specialties (for example, architecture) to work across team boundaries and together guide the overall direction and evolution of the project. These groups inspect and adapt to find the right composition and meeting frequency.