Managing Distributed Teams

Today businesses are shifting to emerging economies (Russia, China, India, the
Philippines, etc.) due to reduced business operations cost and an easily available
workforce. If I put it more precisely, tomorrow's business will be more virtual and
distributed, with "distributed" as its key element. Thus the need for better managing
such teams, using the right tools and processes, is becoming increasingly critical for
any enterprise company.
Here are some reasons for the shift and need for having distributed Agile teams:

Globally distributed teams reduce costs.

They can reach the market more quickly with a "follow the sun" model.

Distributed teams expand access to new markets.

Acquisitions as a result of consolidation results in companies working together to

integrate their businesses.

Expansion can aid innovation and thought leadership.

Telecommuting gives options for communicating with teams effectively.

Collaboration tools -- improved tools for distributed communications and serverbased, multiuser tools for product development -- are removing barriers, and more
teams view distributed collaboration as an alternative.

Handling distributed Agile teams

Distributed teams heighten the need for clear, timely communication between sites. You
might be thinking of increases in complexity due to more time zones, language barriers,
and cultural differences getting in the way.
Questions can include these:

Are distributed teams difficult to manage?

Are they failing to meet some expectations?

Are they having trouble working as a team?

Is team morale a problem?

Agile can't fix every problem, but it can bring them out into the open, where the team
can evaluate and correct them. Agile puts challenges under a magnifying glass. As the
images under the glass grow larger, they scream for attention, and your team's
performance will improve after it addresses the challenges and corrects dysfunctions.
The key challenging areas that need to be addressed for distributed team management
are as follows:

Communication is the core issue among the distributed teams.

Different time zones and conflicting working hours impact communication and
collaboration.

Cultural and language differences impact communication and collaboration.

An effective tool chain is needed for requirements repositories, SCM,

management, build and deployment setup, defect tracking, and project management
tools.

Three XP practices that are particularly valuable: TDD, CI, and test automation

Scheduling differences at the team level for various activities becomes more
challenging with increasing levels of distribution.

Time dynamics have positive and negative impacts on distributed teams.

Improper and inappropriate telephone and video setup impacts communication

and creates problems.
o

Not providing access to calls, not set up for telephone calls in meetings,
difficulty identifying an unseen speaker, need to encourage participants, limiting
the conversation using round-robin technique, importance of mute, checking for
any agreement or disagreement

How Agile helps address these challenges within all the Scrum ceremonies

Self-managing distributed cheat-sheet table

Preparing for
Sprint Planning
Product owner needs to understand the capacity and look for
opportunities to create cross-functional teams within similar time
zones.

Team composition: Teams of more than 9 people should consider

geographic closeness and proper distribution of skills as well as team
size so as to build self-organizing teams.

Individual Scrum teams should aim to have the lowest distribution

level possible, encouraging feature teams over component teams.

Disaggregate the higher-priority features: Distributed team

members, PO, and ScrumMaster develop more than one feature to
address a single solution that can fit within a sprint.

Single backlog for multiple teams: Different skill sets in the team
are needed to deliver user stories that are available across each
distributed location.

Separate backlog for multiple teams: Scrum teams work

independently from one another and have their own individual sprint
backlogs, but the sprint dates are the same, marking their
interdependencies and risks in the sprint preplanning sessions or in a
daily Scrum of Scrums.

Release planning: The number of sprints to map out and use with a
"look-ahead planning technique" will depend on sprint length,
dependencies, and the needs of the teams involved.

Sprint length: Teams that work on a set of related products should

synchronize their sprint lengths and start dates to cater to their
interdependencies.

Sprint velocity: Although it is difficult to estimate the velocity in

projects with multiple teams, they should always estimate the stories
they will work on, because teams have different scales.

Manage dependencies within the teams: Agile teams will not try to
account for every possible dependency at the start of the project but will
look ahead two or three sprints to ensure that teams are ready to deal
with dependencies, using the INVEST model.

Risks: During the release plan, the PO will want to identify the risks
associated with the project and teams, and, when possible, the
mitigation plan for each of them.

Coordinate multiple product owners of different teams: Product

owners meet regularly to discuss product backlogs, dependencies, and
links between and boundaries between user stories of different teams.

Use Agile project management tools: It is mandatory to have

enterprise tools to manage teams and their work related to the sprint and
for overall governance of the product.

Invest in smarter development: Test automation and continuous

integration help Agile teams complete user stories within a sprint,

working together or for distributed teams.

Coordinating Agile and non-Agile teams: Making sure the nonAgile team is aware of the priorities of the Agile teams and keeping
dependencies visible can help to prevent blockers between the teams.

Face-to-face collaboration: The SM should reduce the amount time

spent each day on project setup tasks, which will extend the duration of
the project startup tasks and enhance the trust and relationships needed
in distributed development efforts.

Sprint planning meeting: Product owners need to coordinate the

priorities between the product backlogs of different teams, considering
their dependencies between the projects, features, and stories before
giving the commitment.

First level of sprint planning: The PO and SM will use a screensharing tool to display the vision, sprint goal, user story, the estimates
the team provided, and the acceptance conditions for the user story.

Dealing with incomplete stories: The PO takes the impact of

dependencies into consideration when reprioritizing the product backlog
due to which team did not complete items during the sprint.

Checking estimates from preplanning teams: In scaled distributed

environments, where teams send representatives to help with
preplanning, it is important that teams who are going to be doing the
work revisit the estimates.

Reviewing changes based on stakeholder feedback: The team

would review changes made since the preplanning meeting, and the PO
would confirm the priorities of the product backlog.

Engaging stakeholders: At enterprise-level environments, to

address the diversity of data by the Scrum team, the PO can help
identify which customers are representative of different markets.

Sprint Planning

The second half of sprint planning

Deciding how to get the work done: Creating the sprint backlog -- the PO
reviews the highest-priority items in the product backlog with the team and

helps the team to take a guess at how much work they can do within the
sprint.

Identifying tasks: The PO gives the team time to think about the
tasks needed to complete the work items during the sprint planning
meeting. Teams run planning meeting discussion among all the
stakeholders to get maximum clarity on the tasks.

Gaining commitment: With a distributed team, team members who

are sensing that other team members have unspoken issues need to
take responsibility for drawing the SM's attention to the issues; because
of this, the SM needs to rely on the whole team to take responsibility for
ensuring good communication.
o

Distributed
Daily Scrum
Meetings

Note: No one should interpret silence as agreement. Team

members should phrase questions in a way that they need a verbal
response to improve the understanding within the team.

Release plan check or update: Enterprise Scrum teams often begin

providing tasks for high-priority user stories before the sprint planning
meeting. All team members discuss the tasks because it helps with
communication for distributed and scaled teams and provides
opportunities to find better ways of completing the user stories. Silence
on a teleconference is not a commitment.

Using the 3 questions effectively: The PO and SM should highlight

the importance of the three questions in front of the team members so
they understand their purpose.

Answering the 3 questions: Team members should communicate

information that brings value to others on the team. They should also try
to identify team members who can help them resolve their issues.

Coordinating the team on a daily basis: Priorities can change

daily. The daily Scrum meeting provides a daily synchronization point for
the team and allows members to revise their plans regularly.

Committing to the team: Team members are making a verbal

commitment to their team when they state what they are going to do
today, creating an opportunity for the rest of the team to confirm they met
their commitments yesterday.

Verifying progress: Tasks not opening and closing regularly are an

early sign the team may be going off track. Team members not showing
regular progress may be facing outside distractions the SM should
reduce or remove.

Resolving blockers: The SM should create a list of blockers and

assign them to team members or managers. The SM should also ensure
the team is burning through the blocker list.

Daily Scrum logistics: Conducting the daily Scrums when team

members are in the same time zone and speak the same language is
much simpler than for a team with members spread in multiple countries
and time zones, having many different languages and cultures.

Daily Scrum logistics - ways of communicating during the daily

Scrum: Having face-to-face daily Scrum meetings gives the team the
highest level of collaboration possible.
o

Teleconference meeting: Distributed teams with overlapping

work hours should use a teleconference call to the same phone
number every day to hold their daily Scrum meetings.

Videoconference meeting: The main advantage of this

approach is that team members get to see one another, so there is
less nonverbal communication loss.

Approach to handling time zone issues: Distributed teams can use

four different methods to deal with distributed daily Scrums where the
team has members with no overlap in their work hours, as follows: Daily
Scrums through documentation, liaison approach, alternating meeting
times, and share the pain.

Precautions to be taken while conducting distributed Scrum

meeting - Increased distraction: Background noise can be distracting
on a teleconference, so teams should chose a quiet room to conduct the
meeting.

Keeping the team engaged: Possibly the best way to stay engaged
and to make sure that others on the team stay engaged is: awareness.
Build awareness of what the team is working on.

o
o

Advertising. Advertise for collaboration.

Attack blockers. The team and SM should strive to fix all
blockers within one hour of the daily Scrum.

Facilitating the meeting: In a distributed environment, as individuals

come into the call, they will identify who they are. The SM calls each
person and asks for their response. They may respond in the order they
arrived at the teleconference or the SM may choose to call on each
person.

Taking daily Scrum notes: This helps the distributed team members
overcome language problems, plan, and learn. Chat Tools and Wiki help
distributed teams do daily Scrums.

Scrum of Scrum: These can solve distributed team roadblocks,

future dependencies, commitments to other team members, issues with
integration, and other points that impact one another.

Collaboration
within a Sprint

Scrum Teams should follow continuous integration, test

automation, and test-driven development practice to foster
distributed collaboration during the sprint and help teams complete user
stories within a sprint.

Documentation helps to overcome distance: Because of language

barriers, distributed teams often need more written documentation than
co-located teams.

Using the right tools: In a distributed environment, right tools and

effective practices can help team members communicate more
effectively.

Valuing the whole team: The SM should focus on an "us" versus a

"them" attitude in the distributed team, due to more delays in
communications and fewer opportunities to work together.

Transparency: Distributed Agile teams should use project

management tools to identify tasks that are open, in progress, and
completed so everyone is aware of the current status.

Handling new requests in the middle of a sprint: In distributed

Scrum, it becomes mandatory that the team commits to sending

requests through the product owner(s), who will decide the priority of the
request in the product backlog.

Backlog grooming -- shortening the sprint: Shorter sprint lengths

make the distributed team more responsive to stakeholders. They also
allow the team to adapt to change more rapidly.

Dealing with defects: Distributed teams may want to consider

creating a user story with a certain number of story points in the sprint to
deal with the problems, or they can set a priority for the maintenance
tasks as per the customer log, or create a subteam to focus only on
handling these issues during the Sprint, or -- depending on the skill set
of the technical support team -- make the necessary code changes.

Disruptions at the team member level -- handling stories the

team cannot complete during the sprint: Before working toward the
solution, the team first needs to identify the work they need to do to
complete the story through meetings between team members or with the
product owner.

Handling blockers during the sprint: In the large-scale enterprise

transitioning to agile, the SM needs to hear from distributed Scrum team
members who are facing blockers and dealing directly with inhibitors will
help increase the velocity of the team over time, as well as the velocity of
other teams as they transition to Scrum.

Responding to questions during the sprint: For enterprise product

development, the PO should look for ways to match representative
stakeholders with the teams' working hours and to be available during
that time as well. For applications the team is developing for a specific
client, the product owner may not have the flexibility to choose
stakeholder representatives available during the full working day of the
client.

Sharing time zone challenges: One approach to help manage such

cases is to make sure that distributed teams in different time zones are
fully self-sufficient and the team spreads the work to minimize
dependencies.

Continuous integration: This is the key to delivering stable, highquality code consistently and quickly, which results in reducing time to

market for any distributed Agile team.

Report any build failures to the team: Allows the distributed team
to know the current state of the code in the integration branch of the
source control system, generating a notification email for build success
or failure.

Reduce the risk of integrating code: Continuous integration

ensures that a build runs regularly and allows the distributed team to
identify integration issues earlier when they are less costly to fix. This
practice helps the team identify design problems and avoid introducing
defects in scenarios we did not cover. These smaller testable
deliverables allow the team members testing the feature to start their
work in parallel with the development.

Establish greater confidence in the product: When developers are

doing the unit testing of their code, they should also create automated
unit tests as continuous integration certifies every build, developers can
make changes with more confidence, and the entire team can remain in
sync with the latest build.

Reduce the time to find integration issues: Developers receive the

build status by email, so they can see and fix problems. The next time
the build runs, the build status changes from fail to pass automatically.

Improve the efficiency of the team: Distributed teams' efficiency

can be improved by automating once and then reusing as much as
possible. This removes human error, provides consistency, and frees up
people to do higher-value work.

Builds can run at different frequencies: Setting up the hourly build

helps the distributed team know about a failure closer to the time of the
code integration, and team members can take action on it earlier.

Test automation: To streamline the testing and help the distributed

team get as much done as possible within a two-week sprint, teams
should automate time-consuming manual processes where possible.

Dedicated automation teams: The developers in distributed teams

should tell what is ready to be automated to allow testers to closely
couple with the product.

End-of-Sprint
Reviews

Test-driven development: Developers write unit tests, the small

tests that fail first. Testers work with developers to ensure that any later
tests do not repeat the work the developers have already done.
o

Provide documentation and working examples of code:

Developers are writing their unit tests and providing documentation
and working samples for the code they are testing. This allows other
team members to gain a quick understanding of the code when they
need to work with it.

Help reduce the time to fix defects: The developer may be

able to create a unit test specific to the case that is causing the
problem and fixing the area where the problem is occurring. The
developer can save the time needed to create a full build, start the
application, get to the right place, and test the fix manually.

Help improve code quality and provide a safety net for

changes: An early defect detection process helps developers
improve the code knowing the existing set of tests will detect any
problems. Developers can think of code in small units that they write,
test independently, and integrate later.

Help team members work together and collaborate: When

teams are evolving from a traditional development model to Agile, it
is a huge attitude shift to adopt TDD.

Help teams move away from big up-front designs: Break

down a feature into smaller testable chunks and create small teams
to start working on some code right away. This code can be small
prototypes that act as tracer bullets through slices of functionality.

Communicate effectively: Team members who are most able to

communicate effectively with the team, PO, SM, and stakeholders
should present, so that they can represent the team in front of the
customer.

Fluent speaker: Another approach is to record the demonstration

before the meeting to allow the developers to create the recording at
their own pace in the language of the meeting, or to have a fluent
speaker speak over the recorded demonstration.

Scheduling for teams with overlapping work hours: Make sure all
team members of the distributed team, regardless of the time zone, can
complete their work and prepare for the demo within overlapping work
hours.

Scheduling for teams with no overlapping work hours alternate

meeting time: The distributed team holds one sprint review meeting
during the normal workday for part of the Scrum team and holds the
other sprint review meeting during the normal work hours of the other
part of the Scrum team.

Things to be followed by distributed teams in sprint review

meetings -- keeping track of the stakeholder comments: During the
sprint meeting, the distributed team needs to capture these comments
so the product owner and the development team can decide which ones
they will act on.

Demos may provide a false sense of completion: Add a DRAFT

watermark on any screenshots or to use data that is clearly not real, to
avoid a false sense of completion to the stakeholders.

Remote demonstrations -- network delays and poor

performance: Distributed teams should test their tools ahead of time to
be sure the distributed meeting will run smoothly, without network poor
performance. The team can also consider making the recordings
available for download before the demonstration meeting and discussing
them through a teleconference.

Services may vary by location: Set up a single machine with a

standard configuration that everyone uses during the demonstration
meeting. Before the start of the meeting, distributed team members can
access the machine (remotely or locally) to bookmark links, set up
scripts, and do a quick dry run of their presentation.

Effective and overlapping retrospective meeting timings: To be

effective and timely, distributed teams should call joint retrospectives as
soon as possible after having their own team meeting. Depending on the
number of teams involved in a joint retrospective, teams may want to
limit the number of participants from each Scrum team to keep the

Retrospectives

meeting productive.

Hold joint retrospectives: The distributed teams working together

will conduct their individual sprint retrospectives at the end of each sprint
and then will conduct a joint retrospective. The benefit of this approach is
that it promotes communication between the various teams involved in a
project.

Conduct milestone-based larger retrospectives: Distributed team

members should reflect and comment on release quality and capability.
The team defines and records the various milestones within the project
to improve on or continue in future releases.

Build trust: The SM needs to develop a sense of trust and honesty

within the team, which in turn will lead to a wider degree of openness.

Reduce effects of distance: The facilitator of a distributed

retrospective needs to understand the cultural differences in the team.
The SM needs to understand how different cultures interact when they
want to change something or have issues they want to talk about that
can help the facilitator encourage participation from all team members.

Set expectations: The facilitator, for distributed teams, should talk to

the team ahead of the first retrospective and explain the expectations for
the retrospective.

Understand the team members' personalities: Teams have a

different combination of personalities, and the facilitator of the
retrospective needs to understand the personalities of team members to
lead the meeting effectively.

Respect cultural differences: The SM needs to make sure cultural

difference should not be taken lightly during the retrospective meeting in
distributed teams.

Ask for comments before the retrospective meeting -- what went

well and what can we improve? Ask the team for comments about
issues or problems they noticed since the previous Sprint retrospective
and summarize them for team discussion. The result is still an action
plan and a list of behaviors the team needs to change or continue in the
period until the next retrospective.

Provide questions to focus the discussion: In a distributed setup,

team members respond to a set of questions developed or selected by
the team. The purpose is to focus on a few issues and address them
effectively instead of trying to address a lot of issues and address them
poorly.

Discuss reported issues: During the retrospective, the team

reviews the reported issues and, if others feel strongly enough, the team
addresses them, creates action plans, and logs them as actions they will
revisit in later sprint retrospectives to evaluate their success.

Release retrospectives: The team talks about the project, then

defines and records the milestones in the project, like initial training,
team formation, stand-up meetings, start of development, middle of
release, deployment, etc.

Conclusion
Distributed teams need to go for mandatory training to run into full-fledged Agile teams,
so that they can better understand the potential impact of making the change. Although
the project teams learn from adjusting to distributed Agile teams, it becomes more
important for them to understand and adhere to Scrum, rather than immediately thinking
that Scrum needs to be changed.
I believe that collaboration becomes highly important in distributed teams as they are
collectively responsible for delivering on their commitments. One important key to
success in managing distributed teams is to have a high commitment level from all team
members, and the best way to get that is to give them ownership over how they will
work.
Another key to embracing a self-managed distributed team is valuing the entire team
and not having an "us versus them" atmosphere between different Scrum teams on the
project. The best ways to build relationships within teams is to find ways to share the
pain of being a distributed team; to get to know each other as people; and to foster
frequent, quality communications between team members.
Another way to introspect distributed team management is to use sprint retrospectives
to see what the teams are doing and whether their methods of communicating are

working for them. When they need to adjust, they should do so as quickly as possible.
I must say the teams with members distributed across sites can enhance code
ownership and improve the autonomy essential to team self-organization. Automated
communication of product and sprint backlogs throughout the organization, combined
with upward reporting of teams' status to management, can tightly align and knit the
distributed teams together. - See more at:
https://www.scrumalliance.org/community/articles/2013/july/managing-distributedteams.aspx#sthash.Ee4lMaQq.dpuf

Distributed Teams
There are many different experiences and pieces of advice with regard to distributed
teams, and most deal with how to get the communication to work in the best possible
way within the given parameters. Active use of electronic aids such as Skype,
Communicator, SharePoint, etc., are often recommended to ensure good
communication across borders and time zones, and to remove some of the
disadvantages associated with having a distributed team.
There is a common perception that the co-located team is better positioned to ensure
good communication and deliver more efficiently than distributed teams. But in a world
where global collaboration becomes increasingly common, teams often consists of
people from different parts of the world working together as distributed teams. And with
this, it is interesting to note that while there are some clear challenges with having a
distributed team, there can also be some advantages.
A distributed team can be cost-effective. This can be manifested in the form of reduced
travel costs and the use of resources from countries with lower labor costs. Traveling
can be replaced with efficient work, and the reduced travel load in itself can be a
motivating factor for many.
A distributed team can also provide access to higher skills, because you do not have to
limit your resource search to a specific area.
In some cases, having a distributed team also enables some team members to sit
together with customers in multiple locations. Some also claim that distributed teams
are more focused on information sharing within the team -- but then again it can also
make the communication more formal, with the advantages and disadvantages this may
cause.
But there are obviously some definite challenges with having distributed teams. One of
the most important lessons is to not manage a distributed team as if it were co-located.
It is crucial to be aware of this and to address the obstacles that the team will have to
deal with in terms of communication and cooperation.
Many development practices (e.g., from Extreme Programming) stipulate rules for
teamwork, and it is important not to ignore such practices just because we have a
distributed team. If your current situation makes it impossible to follow a defined
practice, you should either modify or replace it with something that works better within
the given situation. The key is to make sure that you are aware of the purpose of the
practice, and make sure that an alternative or replacement provides the same benefit.
For example, pair programming can be replaced or simulated by performing code
reviews. User stories can be written out in even greater detail to make up for some of
what you'll be missing if you cannot have the same degree of conversation within the
team during a planning session. Dont get me wrong -- I would never state that this is a
good substitute for conversation, but I use this example to show that, even in cases

where we can't follow the very core beliefs of the Agile Manifesto (interactions over
tools), we should still make some effort to improve the situation.
Another challenge with distributed teams is that we often fall for the convenience of
assigning tasks based on the team's spread. This can result in specializations within the
geographic locations, and so we create dependencies between these locations. This
could greatly reduce the team's ability to complete a function within an iteration.
Actually, studies show that such negative effects increase with the size of the team. 1
Some would argue that it can be impossible to avoid such situations. Sometimes all the
experts within a specific field are in just one of the locations, and therefore it's not
appropriate to allocate this expertise to the other locations. Such discussions will always
be based on the different experiences of different people, which may not be directly
comparable.
A person who claims that ensuring competence distribution across locations makes
sense probably is quite right in the circumstances he or she experiences. Maybe much
was to be gained from having a cross-functional team just because in the given case
there were many dependencies across tasks. Or because the duration of the delivery
was so far out that investment in training and transferring skills was actually quite
reasonable.
A person who claims the opposite, who simply does not see the point in having a crossfunctional team, will also have experiences that support this. Maybe it was a short
enough delivery duration that it didn't pay to drive knowledge transfer. Maybe there were
more people at a given location with the same skills and therefore they were not so
dependent on one individual. Perhaps the dependencies across tasks were so small
that it worked just fine to have different expertise in various locations.
Most people, regardless of experience, will agree that there will always be an advantage
to having a cross-functional team. The intention behind this principle of Scrum is that
you should avoid dependencies on individuals and make good decisions based on
discussions among several people who have expertise in an area.
But ultimately it must be taken case by case, and you must observe and evaluate what
makes the most sense in the given situation.
In a global setting, language itself is another challenge within distributed teams, as are
different working hours (time zones) and especially cultural differences. In Scandinavia,
many people believe that we are more practiced at enhancing collaboration and that our
style is more inclusive compared with, for example, the U.S. Meanwhile, a leader in the
U.S. might find it easier to confront employees whose performance is inadequate, which
many executives in, for instance, Norway are reluctant to do. In Asia you are keen not to
lose face; in Saudi Arabia, it is disrespectful to sit with legs crossed and show the soles
of the feet; in Russia, an inclusive leadership style is perceived as a weak leadership
style.

There are countless examples of cultural differences, but what does this mean in the
context of securing communication within a distributed team?
Despite all these cultural differences, we humans are very similar when it comes to
relationships with others. It's primarily about building trust by respecting others, with
words and actions that are in relation to each other.
All functional teams should be based on these principles and, therefore, establishing
these principles is perhaps the most important thing one can do to ensure that team
members have the opportunity to build this basic trust in each other.

Confidence exists at several levels in a distributed team

Trust is built through interaction and communication. A developer who takes
responsibility for a task and delivers it well inspires confidence in others. A ScrumMaster
who protects the team has the confidence of the team. A product owner who dares trust
that the team will use its technical expertise to deliver in the best possible way will
create mutual trust and increased commitment from the team.
But confidence also means accountability. If the team feels that others do not deliver as
expected and that this is not handled and solved, you've got a situation that could be
damaging to both motivation and efficiency. Accountability can also be seen in that a
product owner sets expectations that the team delivers on, according to what they have
committed to for a sprint.
To lay the foundation for mutual trust and cooperation, it's often recommend that
distributed teams gather physically at the start of a new project. This helps team
members get to know each other, which forms an excellent basis for continuing dialogue
and cooperation. It also provides a good opportunity for the team to establish a common
set of rules for collaboration and communication. (This is something every new team
should do at its inception, regardless of whether the team members meet physically or
not.)
In 2003, a study of global IT teams revealed that key factors for successful distributed
teams included a set of common goals, open dialogue, attention to building
interpersonal relationships, and making sure that someone was responsible as a
facilitator to support collaboration and communication. 2
What is interesting in this context is that this study addressed all types of IT projects, not
only those based on the Agile framework.
By using the Scrum framework, a team should, theoretically, have very good conditions
to ensure a focus on these key factors. The daily Scrum encourages regular dialogue
and communication between among team members, the team sets out common goals
for each iteration, and the ScrumMaster acts as facilitator.

This is in no way an attempt to argue that the Scrum itself is the solution, but the
principles that the framework is built on will help keep a focus on the key factors that, as
experience shows, are important for efficient distributed teams. Again, back to the
eternal mantra that should form the basis for all Agile development: Understand the
intent of the framework and established practices, base them in reality, and make
adjustments so that one can achieve the intention.

Conclusion
In distributed teams with different nationalities, it is wise to be aware that people have
experiences and expectations based on other traditions. Generally speaking, it is often
also wise to be open to other ways of doing things. But the basic expectations of trust
and cooperation are largely the same, regardless of borders and frontiers. A very good
rule of thumb is to always have more questions than we have answers. Acquire more
information while avoiding coming across as arrogant and as having all the answers.
The information you'll gain will support broader and more informed decisions and assist
everyone in making the right decisions.
When it comes to having a distributed team, then, it's primarily about building trust and
having mutual respect for each other, along with a common focus on communication
and as close a collaboration as possible.
It's difficult to give one-size-fits-all advice, but I hope the areas discussed form good
suggestions as to what can and should be focused on when working with distributed
teams. In practice, the world is such that no project or team is equal, and you have to do
assessments and make decisions based on the assumptions that apply to the
appropriate team. In its simplest form, it's about communicating, observing, and
reacting.

Resources
1
Craig Larman and Bas Vodde, Scaling Lean & Agile Development. Addison-Wesley
Professional, 2008.
2
Dr. Niki Panteli, lecturer in Information Systems, School of Management, University of
Bath. (Link to survey: http://www.ariadne.ac.uk/issue43/panteli)
- See more at: https://www.scrumalliance.org/community/articles/2013/august/distributedteams#sthash.cwLlNA7M.dpuf

12 Best Practices for Distributed

Development Teams Using Agile and
Scrum Methodologies
With todays technologies and collaboration tools, software development
projects are no longer impeded by distance between team members. In
the past, businesses sought offshore development solutions strictly for
cost savings, as companies with limited IT budgets could build
applications for less using resources in locations with a lower cost of
living. Today, they are starting to realize the true value of being able to
assemble teams of experts anywhere in the world.
Distributed Development, a project delivery model in which work is done
across multiple worksites, is rapidly becoming a common approach.
Within a distributed development model, team members physically
located in different placesbuildings, cities, countries, or continents
work collaboratively to complete project deliverables. With the right
approach, a distributed development team can avoid or overcome
common challenges and become a high performing team that enjoys
working together to deliver business value.
However, the distributed development team model can still be
challenging if the right people, processes, and tools are not in place.
Additionally, distributed development teams will struggle to produce
results if they are not operating from the same set of principles or have a
shared understanding of project goals. Based on my experience, the
following are best practices for distributed development teams,
particularly those utilizing agile and scrum methodologies. Some of the
success criteria can also be relevant to teams that work in the same
location, but play a bigger role in distributed teams.

1) Adopt a hybrid approach with local and remote team

members
When possible, the project manager, architect, and other lead roles
should be onsite or local to the client so they can interface directly with
key stakeholders. Not only does this reduce the risk of misunderstanding
business needs and technical requirements, but it also provides project
owners and stakeholders the convenience of local contacts combined with
lower cost resources.

2) Designate a leader at each worksite

At any worksite with a team of three or more members, someone should
serve as the lead. This person could be a lead developer, project
manager, scrum master, or any other team member who demonstrates
leadership abilities. The onsite lead will provide the team with direction
and support through face-to-face interaction. They will also serve as a
single point of contact and represent the needs of the local team so that
the entire team doesnt get pulled into every meeting, email thread, or
instant message conversation. In this way, the lead will streamline
communication and ensure the team has the support and guidance they
need to keep focused and stay on track.

3) Distribute work equally and assign ownership to every

individual
Work should be assigned based on skill, capacity, and overall release or
sprint goals. Work assignments should not be based on location. Ideally,
all team members are able to perform a variety of tasks (analysis, design,
development, and test) so that work can be re-distributed if needed to
complete all items in the sprint backlog. It is also important to make sure
each team member is given ownership of a feature or component of the
solution so everyone on the team feels accountable for the success of the
project regardless of their location.

4) Adhere to engineering best practices and development

standards
The team should have a common understanding and agreement on the
best practices and standards they will adopt and follow. This includes
development procedures, code standards and styles, patterns, and other
best practices that result in an extensible, quality product. These best
practices and standards may be at the industry-level or ones that the
team defines for themselves. When everyone is operating under the same
standards, there is a better chance that code merges and integrations will
be successful and have fewer defects.

5) Respect time zone and cultural differences

When team members are spread across time zones, everyone will need to
compromise on when daily standups and other team meetings are held.
The times should be as consistent as possible. This will allow team
members to plan family obligations and other non-work commitments and
have a sense of consistency in their schedule.
Additionally, when team members come from different cultural
backgrounds, it is important to respect each others holidays. Everyone on
the team should not have to follow the holiday schedule of the corporate
headquarters or primary office team. Schedules and resource availability
should take into account the global holiday schedule.

6) Use of online tools for agile artifacts

The use of online tools is very important for keeping a distributed team
informed and organized. There are many good tools out there for creating
and maintaining product backlogs, organizing and planning sprints,
managing task boards, monitoring burn-down, and tracking bugs and
other work items. The use of common productivity apps (Excel, OneNote)
in a shared environment, such as SharePoint, can do the job too.

While not an agile-specific tool, Microsoft OneNote is a great application

for sharing information amongst a distributed team. When a OneNote file
is posted to a shared location, all team members can access and
contribute to it. My teams use OneNote to document development
standards, project procedures, best practices, and other helpful
information. The project notebook evolves as team members add new
content or augment existing content to keep it useful and relevant.

7) Adapt communication methods to remote teams

Real-time communication between distributed team members is critical to
getting work done and building relationships. Many online meeting and
instant messaging tools have video and voice features that allow
distributed team members to hear and see each other. During standups
and other team meetings, my team uses web cams and the video
capability in our online meeting tool. We also use the voice feature in
Skype to talk to each other at various times during the day when we have
questions or ideas to share with one another. Email should not be a
distributed teams primary communication channel as intent can be lost
and those involved in the discussion cannot ask clarifying questions or
confirm their understanding without having to wait for a response.
However, email is good for recapping discussions and sharing decisions
with all who need to be informed. Whatever tools you choose, the team
should not only have access to them; they should use them frequently
throughout the day.

8) Arrange face-to-face interaction

Distributed development teams should plan get-togethers in person 1-2
times per year at minimum. Project kick-off and on-boarding phases are a
good time for in-person gatherings, as well as key milestone planning
events. The team should also plan non-work related social activities to get
to know each other personally. When team members are working, use
web cams and the video capability in online communication tools to bring
the team together.

9) Cultivate commitment to product and delivery quality

Creating a set of shared goals at both the milestone and iteration level
can drive buy-in and commitment from the team. I recommend no more
than four goals; any more can cause the team to be overwhelmed and
unfocused. I also believe it is important to have a mix of product-related
(what the team is delivering) and delivery-related (how the team
delivers) goals. During release and sprint planning events, the team
should identify action items aligned to each goal to ensure the goal is
met. Everyone on the team should be assigned at least one of those
action items to foster equal commitment toward the goals. The scrum
master or team lead should then hold regular checkpoints to see where
the team is at with the action items and gauge overall progress toward
the goals.

10) Allow for proper on-boarding and training

If travel to the corporate headquarters or some other primary facility for
training and other ramp-up activities is not feasible for new team
members, then a structured on-boarding and training plan will help
ensure they are properly set-up and trained. Create an on-boarding plan
outlining exactly what training they need to complete, what tools they
need, and what resources they need to access. Distributed teams should
also institute on-going coaching and mentoring between senior resources
and the junior or mid-level resources. This ensures the less experienced
team members are getting the support and guidance they need, and
development standards and best practices are consistently adopted
across the team.

11) Frequent demos and retrospectives

Distributed team members should share progress and showcase their
work on a regular basis to build trust and confidence with their
stakeholders and others within the distributed team. For example, they
can build working prototypes to supplement design plans, conduct

frequent code reviews with peers and other subject matter experts, and
facilitate live demos during the sprint review. Distributed development
teams should also carve out time after each sprint or some other
consistent cadence to review communication practices, tool usage, and
other project protocol. It is important that all teams do this, but even
more so for distributed teams.

12) Put it in writing

Project documents and written forms of communication are necessary for
distributed teams to effectively communicate with other team members
and stakeholders. Simply designed docs, brief meeting notes, and other
forms of documentation help ensure intent is understood, decisions are
clear and not forgotten, and information is shared and accessible to all
team members. Establishing good documentation practices in a
distributed team helps to prevent delays and missteps during the
implementation, fostering alignment around what the team is doing.
The list of success factors for distributed teams runs longer than what has
been covered here. By having the right processes and tools, mutually
agreed upon standards and practices, and commitment from all team
members to follow them, distributed teams can be just as cohesive and
collaborative as teams that work under the same roof. Personally, I find
working in a distributed software development team model even more
rewarding due to the additional challenges that come with being in
different geographical locations. When a distributed team is able to
achieve their goals and delivery business value on a regular basis, it
reinforces best practices and keys to success.