Course Info

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

The Distributed Scrum Primer
The Distributed Scrum Primer is an introduction to the principals and practices of successful distributed agile development using Scrum. It was created by Pete Deemer, the founder of GoodAgile and co-author of The Scrum Primer. Its main contributors are Narinder Kumar and Vikas Hazrati, founders of Inphina Technologies, and Gabrielle Benefield and Robert Benefield of Agile Lean Training. Pete Deemer and Gabrielle Benefield are Scrum Alliance Certified Scrum Trainers, and all the contributors have extensive experience with distributed agile development using Scrum.

 Download The Distributed Scrum Primer 1.0

[Part 1] [Part 2] [Part 3] [Part 4]
Attracted by significantly lower costs in places like India, China, and Eastern Europe, many companies have embarked on globally distributed software development initiatives. Unfortunately, many have found that while per-hour development costs are indeed lower, overall project costs can be higher, after factoring in the significant challenges of communication and coordination, the cost of difficulties and delays, and higher project failure rates. Not surprisingly, many organizations have turned to Scrum in hopes that it will enable their distributed teams to achieve significantly better results. This primer outlines practices that can help distributed Scrum Teams excel, and highlights some of the common pitfalls that teams encounter, along with ways to respond to these challenges.

The most important point to start with is that the principles and practices of Scrum in a distributed project are no different from the principles and practices of Scrum in a single-location project: It's simply Scrum, but with added challenges brought on by the distances and differences between locations. The Scrum practices enable teams to deliver customer value early and often, add transparency, surface dysfunction, and drive continuous improvement through a simple framework of inspect and adapt – all of which are even more more acutely needed in a distributed project, but at the same time are logistically more difficult to conduct. The following pages outline practices which can help overcome these challenges, first in enabling communication and then in building trust. Then, useful tips for implementing the Scrum roles, meetings, artifacts, and technical practices are outlined, as well as common pitfalls to be avoided.

In the final analysis, there is no one "right" way to do distributed development using Scrum, other than for teams to start with the principles and standard practices of Scrum, and inspect and adapt to a solution that is well suited to their particular situation – but this Primer provides starting points and ideas that may help speed teams along the path of improvement.

While there are technical issues that need to be considered when using Scrum in a distributed environment, the biggest challenges center around human issues, starting with communication.

At its most basic level, software development is both enabled by, and constrained by, the quality of the communication that takes place among the people involved. Customers form ideas about what they need, and communicate them to the development team; the team-members communicate with each other and with the customer to build functionality that satisfies those needs; the customer communicates feedback to the team about what's been built; and throughout this process, everyone communicates with each other about questions they have, obstacles they encounter, opportunities they see, and how they are feeling (satisfied, concerned, etc.)

Consider a Product Owner in one location and a development team in another location. The quality of the communication between them will directly determine how much business value (in the form of useful, high-quality software) is delivered. Every misunderstanding between the Product Owner and team means a little less value will be delivered; when the team implements a piece of functionality incorrectly, and has to go back and redo it, there is other work that in the end will not be completed. Also, the more effort the communication requires, the less business value will be produced; if the team has to leave 3 voicemails for the Product Owner to get a response to their question, the Product Owner will inevitably get a little less software in the end; the team was spending their time dialing and waiting, not coding! Great software is typically produced only when there is great communication between the people involved, and poor communication will limit the quantity, quality, and correctness of the end result.

So how do we ensure that communication between the Product Owner and team is as effective as possible?

First, there are practical considerations. The various modes of communication – email, telephone, face-to-face conversation – can be placed on a "richness" scale, which looks something like this:

By and large, the higher up this scale you are, the richer and easier the communication, the more natural the interaction and the more immediate and faithful the understanding between people.

Email is, unfortunately, the go-to mode of communication between most distributed Product Owners and teams, and this is a mixed blessing. Its great strength is that it is not dependent on both parties being present simultaneously, and it preserves a record of the discussion that can be referenced later. The big disadvantage of email is that it is often much more time and effort-intensive. A discussion that might otherwise require a single, five-minute telephone chat could easily turn into 10 back-and-forth emails, each cc:ed to other people (thus consuming their time and attention, if even just to hit the delete key). Email conversations also breed misunderstanding, and as a result, unnecessary or unintended emotionality; without the subtle cues of voice intonation and facial expression, one can easily misunderstand the mood, tone, and intent of the writer.

ScrumMasters working with teams and Product Owners that are distributed need to help everyone shift away from email as the primary means of communication. This starts with making live communication as effortless as possible.

First, the group itself (including the Product Owner) needs to agree that wherever possible, conversations should take place live rather than via email. (If the conversation needs to be documented, either party is always free to send a brief email summary after the call.)

It is important for the Product Owner to clearly communicate to the team that it is acceptable to phone with quick, urgent questions without any "pre-scheduling" required – otherwise, many teams will assume that it is not ok to call, and will default to email.

Next, everyone's (and especially the Product Owner's) desk and mobile phone numbers and IM usernames need to be placed on a wiki or other shared location, along with acceptable outside-of-offices hours to phone with urgent questions, as well as a photo of the person (to remind us that it is in fact a person!). For example:

Tom (Product Owner)
desk: +1-123-456-5678 mobile: +1-123-456-6789
office hours: Mon-Fri, 8am-6pm PST = 8:30pm-6:30am India time
urgent questions: Call mobile Mon-Fri 6:30am-9:30pm PST = 7pm-10am India time

In the team work area, there should be a high-quality speakerphone (for example, a Polycom SoundStation) with the speed-dial buttons programmed to the Product Owner's desk and mobile phone numbers (preceded by any long-distance "unlocking" codes), plus a sticker attached to the phone with the acceptable local hours to call (or clocks will the different location times).

In addition, each team-member's desk phone or VOIP application (and if possible, mobile phone as well) should also have the Product Owner's telephone numbers programmed on speed dial.

Enabling easier telephone communication is an important step, but it is not enough. All of the key Scrum meetings – Sprint Planning, Product Backlog Grooming, Sprint Review, and Sprint Retrospective – should be conducted visually. The problem with audio-only meetings are many. One misses out on facial expressions and body language entirely. It can be unclear which voice belongs to which person. The natural "flow" and cadence of a conversation is often missing; there are either unintentional interruptions, or people are afraid to speak up for fear of interrupting. If participants have unfamiliar accents, it is harder to understand them without a view of their face as they speak. However, the most significant dysfunctions of voice-only calls is people "multitasking" during the call; without a visual on what they are doing, people will often find checking email or surfing the Internet irresistable, and only pay partial attention to what is being discussed. Participants are effectively only "half-there."

Some companies have invested in sophisticated videoconference equipment, but teams may find it complex and cumbersome to operate, or the conference room where it is located is often booked. It may be more effective to provide the team with an improvised solution as follows:

Video: Skype with a wide-angle high-resolution webcam. (It is important to use a wide-angle webcam – this gives a wider field of view, enabling more people to be seen on-camera)

Audio: High-quality conference phone connected via a land-line, with multiple extension microphones for the table. (In some cases doing the audio via Skype is sufficient, but generally a high-quality conference phone on a land-line will produce much better fidelity.)

Ideally, the above equipment should be set up and ready to use at any time in the team room, and this should be replicated at the Product Owner's side. While the quality may not compare with a more sophisticated system, it more than compensates with its simplicity, low cost, and convenience, and it provides the most important visual information: Who is speaking, their expression and body language, and whether people are paying attention. And perhaps most importantly, you are reminded that your colleague is not just a disembodied voice on the end of the line, but a real, live human being!

If the team itself is split between multiple locations, it is strongly recommended to equip each team-member with a webcam and a comfortable, high-quality headset with microphone. This allows for quick, one-to-one audio-video communications at any time, without people even leaving their seats. In addition, there should ideally also be an "always-on" videoconference between the team's locations: a high-resolution wide-angle webcam and large-screen plasma display in each of the team work areas, with continuous Skype video streaming between the two. This serves as a "window" between the two rooms, and because it is always on, it enables instantaneous multi-person conversation and collaboration.

In addition to videoconferencing capability, it is important to also have some type of desktop-sharing software with virtual whiteboard capabilities. Many teams also find it useful to use a low-cost digital tablet for diagramming on this virtual whiteboard.

Finally, for the key Scrum Meetings – Sprint Planning, Product Backlog Grooming, Sprint Review, and Sprint Retrospective – it's helpful to have simultaneous videoconferencing and whiteboarding capability. The following diagram shows a conference room with an ad-hoc setup for doing this, with two projectors side-by-side (one projector displaying the Skype video feed from the other location, and the second projector displaying the shared desktop or virtual whiteboard), plus a high-quality conference phone on a land-line.

Offshore teams may feel uncomfortable asking for these investments in quality communication for fear of being perceived as burdensome or demanding, but when one considers the "big picture," it is hard to justify not making this investment:


The Pioneer team in Bangalore had been feeling frustrated for some time about the difficulty of long-distance meetings with their Product Owner, Steve. Everything was done by conference call and email, and communication was really quite difficult. The conference phone was not very good – it was just a cheap desk phone with a "conference" button – and the sound quality was very unclear. Everyone was constantly interrupting each other by accident, and sometimes there were long pauses from Steve that made the team wonder whether perhaps he perhaps had them on mute and was typing emails – either that, or he was unhappy with them, and did not feel comfortable saying so – they just were not sure. The communication was always a struggle, and the team felt like it was always difficult to express themselves, there were frequent misunderstandings, and this eventually resulted in the team building functionality that was not quite what Steve wanted. The team's ScrumMaster, Sanjay, resolved to do something about the situation.

The first step was upgrading the technology they were working with. The team felt confident that if they could make the four key meetings of each Sprint visual, it would really improve the quality of their communication with Steve. Sanjay gathered the team and led a brainstorming session to come up with a "shopping list."

Wide-Angle Webcam x 2$150[for the team plus Steve]
High-Quality Conference Phone $300[for the team]
Digital Tablet x 2$150[for the team plus Steve]
GoToMeeting for 1 year$150[shared]

Sanjay took this list to his department manager, Vikram.

"Vikram, we're having some serious communications issues with our customer Steve, and the team and I feel that we need to upgrade our communication tools. I need your approval to spend $750 on the following items."

Vikram studied the list.

"Unfortunately, that's rather a lot of money for us to spend on things that aren't really necessities. I don't think I can approve this."

Sanjay thought for a moment, then took out a sheet of paper and a pen.

"Vikram, think of it this way. How much does the team cost the company? Let's include salary, benefits, rent, electricity, equipment, everything. It's about $33,000 per person per year, and we have 6 people on the team. So the total is…"

[writing] 6 x $33,000 = ~$200,000

"So for this $750 purchase to make sense financially, it has to improve our effectiveness by $750 / $200,000. This comes to 0.4%. This means that it will pay for itself with even a tiny improvement in our effectiveness. And if better communication with the customer improves our effectiveness even more – let's say by just 10% or 20% -- then this could be the single best investment we make all year!