Distributed Scrum

Author: Raúl García Cardoso
1
THE DISTRIBUTED SCRUM
ENABLING COMMUNICATION
The biggest challenges center around human issues, starting with communication. So how do we ensure
that communications are effectives?
The modes of communication can be placed on a “richness” scale, which looks something like this:
The great strength of email 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, but the big disadvantage is that
often needs much more time and effort intensive.
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.
- The group itself 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) phone numbers and IM usernames need
to be placed on a wiki or other shared location, along with acceptable outsideof- offices hours to
phone with urgent questions, as well as a photo of the person.

2
Enabling easier telephone communication is an important step, but it is not enough. All of the key Scrum
meetings should be conducted visually. The problems 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.”
BUILDING TRUST
The other key enabler – or constraint – for distributed projects is how much trust there is between the
Product Owner and the team.
One of the most critical steps for the success of a distributed Scrum project is for the Product Owner and
team to come together in person at the beginning and spend quality time sharing key project
information and building a relationship with each other. This is particularly important at the beginning of
a major project. This conversation will also provide more “subtle” information and understanding; for
example, about the values, attitudes, and mindset of the Product Owner and team members.
To be really useful, this project kickoff must include more than just workplace interaction; the Product
Owner and team should plan informal outings away from the office, to give them the opportunity to
interact not just as co-workers but as people.
In addition to the human bonding, the in-person visit by the Product Owner can achieve other goals as
well. First, it lay the groundwork for bridging some of the cultural differences between the two
locations. For example, in the business culture
One final benefit of the Product Owner traveling to the team’s location is for him or her to experience
first-hand some of the challenges the team experiences working in their location.
it is also important that the entire group collocates again every 3-4 months, or after logical milestones
have been achieved. This time together is used to re-emphasize the “big picture” vision and goals, kick
off the forthcoming release, discuss any major issues or upcoming decisions with their colleagues, and
generally re-sync the two locations with each other. This provides them with a better understand the
real context of their work, and goes a long way towards reinforcing a common goal and “one-team”
mindset.
The second part of building a relationship of trust is developing openness and honesty between the
players. Teams are often fearful about being open with the Product Owner, especially if that person is
the customer; the team worries that if they raise a difficulty or concern, the customer will be upset or

3
disappointed, and may even complain to management. As a result, many teams invest a significant
amount of effort in trying to create the appearance that everything is going well.
Indeed, the less well things are going, the more effort has to be invested in maintaining this appearance
– effort which, ironically, would be much better spent trying to solve the problem. Teams are often
afraid to even ask questions, concerned that their uncertainty will be perceived as incompetence – and
as a result, questions go unasked and the team makes assumptions, produces the wrong thing, and
ultimately creates the very perception they were trying all along to avoid!
So how does one avoid this syndrome? The Product Owner must communicate to the team in no
uncertain terms that he or she wants to hear good news as well as bad, that nobody will be punished for
honesty, and that the only “dumb” question is the question that goes unasked.
Then after “talking the talk,” the Product Owner must “walk the walk” – he or she needs to constantly
press the team to ask questions and raise concerns, and when the team does bring up problems (which
will happen tentatively at first), respond in as positive and solutions-oriented a way as possible.
To establish a foundation of trust at the beginning of a long-distance working relationship, it can be very
helpful to have an open and direct conversation about what everyone is committing to, and what each
expects the other to do. This could simply take the form of a conversation, or it could come in the form
of a “working agreement” between the team and the Product Owner.
Some examples of such commitments among real-world Scrum Teams are:
- We commit to be honest with each other. If we have a concern, a doubt, a worry, or if we see a
problem, we commit to surface it to each other immediately.
- If we are unhappy about something that has happened, or something that the other has done,
we commit to surface this immediately to each other.
- We commit not to escalate a problem to upper management without first trying to work it out
with each other. If an escalation does become necessary, we commit to letting each other know
in advance, so it doesn’t catch anyone by surprise.
- We recognize that people make mistakes and have misunderstandings, and that the important
thing is to find and fix the mistake or misunderstandings as quickly as we can. For this reason,
we commit to each other that there will be no retribution for surfacing a problem or a concern,
a mistake or misunderstanding, or for speaking honestly.
DISTRIBUTED SCRUM PRACTICES
Sprints
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.
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

4
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.
The Product Owner
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. 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, 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” require an even more active and tenacious commitment to openness and
inspect-and-adapt.
If the Product Owner is in one location and the team is in the other, the ScrumMaster should be located
where the team is. 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.
The Team
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 collocating 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.
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 common dysfunction when the teams itself is split between two locations and are not properly
bonded is that “one team” actually operates as two teams and may give rise to mistrust and conflict.

5
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
For teams that are split between multiple locations, it is very important that all team members have the
same development environment and 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 findingand-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.
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
Sprint Planning Meeting
One of the practical conflicts in distributed Scrum is the timezone overlap. 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.
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;

6
Daily Scrum Meeting
The ideal is to hold the Daily Scrum Meeting live via webcam each day, at a working hour that overlaps
for both teams. If the team is collocated 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. 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 conference call each day at an hour is an inconvenient for one side or the other, it’s very
important to rotate the burden of the inconvenience from one side to the other every week or
two.
- 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 or record the meeting, and send an
email them to a team-member in the other location, to read aloud at the start of their Daily
Scrum meeting.
Sprint Review
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.
Sprint Retrospective
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.
Artifacts
In a distributed Scrum project, more written artifacts will typically be used. 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

7
misunderstandings sooner. The thinking should be driven by the dictum “try the simplest thing that
could possibly work, and inspect and adapt”.
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 team’s time zones) 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 time zones, it is important that the Scrum
of Scrums meeting time be rotated.
- 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.

Distributed Scrum

More Related Content

What's hot (20)

Similar to Distributed Scrum (20)

Recently uploaded (20)

Distributed Scrum