This document discusses strategies for running effective meetings with geographically dispersed teams. It notes that many agile teams are not co-located, facing challenges like communication barriers, cultural differences due to remote work, and incompatible time zones. Suggested strategies include over-communicating via video conferencing, building rapport between team members, and establishing core hours for daily stand-up meetings. While co-location enables easier collaboration, dispersed teams can still coordinate effectively using technology and following agile practices like daily scrums and sprints.

1. ITERATION 2 – Team C
Assignment Due Date: 08/19/17
Deborah Kiefiuk, M.Ed., PMP
For the User Stories:
 As the product owner, I want to understand techniques for how to best manage teams
in two different geographic locations.
 As a product owner, I want to learn how to run effective virtual meetings for my SCRUM
team.
HOW TO DRIVE EFFECTIVE MEETINGS WHEN WORKING WITH
GEOGRAPHICALLY DISPERSED TEAMS
Abstract
This article will discuss challenges and strategies when working with geographically dispersed
teams. Suggestions and methods to improve your team’s success in running effective meetings
will also be explored when colocation is not possible.
Introduction
Co-location is when the team is all situated in the same work room, and any other organization
than that would lead to a team that is geographically distributed or dispersed. For instance,
teams may be “near-located”, which means that team members are within an easily reachable
distance of each other such that everyone could meet up in-person every day, if necessary.
Other teams may be “far-located”, where at least one team member is far enough away that
he/she would need to take a flight to meet with other team members. Discipline Agile Delivery
notes that, even when team members are in cubicles or separate offices, the team is
distributed, which means that the team will face challenges that may not be present in co-
located teams [1].
In the figure below, we see that most agile teams are not co-located, and 38% of teams are
actually considered far-located [1].

2. source: disciplinedagiledelivery.com[1]
Contents
1.0 Scrum Sprints and the Daily Scrum Meeting
1.1 Agile Experiences with Geographic Distribution
1.2 Benefits of Geographically Distributed Teams
2.0 Challenges of Geographically Distributed Teams and Strategies
2.1 When Colocation is Not Possible: Technology as a Solution
3.0 Driving Productive Daily Scrums for Geographically Dispersed Teams
3.1 Daily Scrum
3.2 Daily Scrum Guidelines
3.3 Daily Scrum Guidelines for Geographically Dispersed Teams
4.0 Best Practices for Effective Scrum Meetings
1.0 Scrum Sprints and the Daily Scrum Meeting
Scrum is a framework that allows for consistency in performance. Since there is a focus on
collaboration and communication over excessive document, meetings will be important.
According to the Agile/Scrum Alliance, “an iteration, in the context of an Agile project, is a
timebox during which development takes place, the duration of which:

3.  May vary from project to project, usually between 1 and 4 weeks
 Is in most cases fixed for the duration of a given project” [8]
Figure 1. The Scrum Sprint [9]
Scrum Sprint
Sprints are iterations that can last anywhere from 1 to 4 weeks. Once determining the time
frame, the average being 2-weeks, this period of time should be the length for every iteration.
Within each sprint there are 4 key meetings, which can also be called Celebrations, described as
follows:
 Release Planning for the prioritization and release of backlog items based on value

4.  Daily Scrum or Stand Up meetings for 15 minutes to allow for continuous daily feedback
 Review Meeting where there is a demo of the workable product to showcase to all
stakeholders
 Retrospective Meeting where the Scrum team only meets to discuss the scrum process
to make improvements, learn from mistakes and reset to start the next sprint.
1.1 Agile Experiences with Geographic Distribution
Teams are able to achieve success and experience failure at various levels of geographic
distribution, as shown below [1].
1.2 Benefits of Geographically Distributed Teams
Here are possible benefits of having geographically distributed teams.
 Finding high-skilled talent: because you are not limiting your team to people who are
local, you are more likely to source high-skilled employees or find individuals who fit the
skill profile the team needs. This is possible because you’re looking within a broader
geographic talent pool [2].

5.  Attracting talent: you are able not only to find more talented people by expanding the
pool of potential employees but also to make the company/team more appealing by
allowing for flexibility in where members are stationed.
 Cost-effective: one way this benefit might manifest is if the team uses resources from
countries with lower costs of labor [2]. It might also be much more costly to find a space
in which to co-locate everyone and it’s more cost-effective to have team members
geographically separate and working remotely.
 Quicker to produce: if a globally distributed team were to use a “follow the sun”
method, one sub-team would do their work during the day and then hand the work off
to a team a few time zones away when the first team leaves [1]. Let’s say that an 8-hour
day is standard, it’s possible then that, with distributed sub-teams, a team may be able
to get 8+ hours of work done in a day by combining the working hours of geographically
separate teams. This would allow the team to complete tasks more effectively and be
quicker to produce work.
1.3 Challenges of Geographically Distributed Teams and Strategies
 Communication: communication among teams of any sort can be difficult, but this
challenge is particularly prominent for distributed teams. This is because geographically
distributed teams often find it harder to meet in-person, which is a very efficient way of
communicating and working through issues. Things often get communicated more
quickly during in-person stand-up meetings and much of communicating is nonverbal.
Obviously, teams that are not in the same physical location do not have the benefit of
regular face-to-face meetings, which means that there is more room for
miscommunication [3].
Strategy: There are many technological tools to help geographically dispersed teams
collaborate in rather simple and cost-effective ways. The Human Computer Interaction
Institute claims that the use of a “visualization tool made a significant difference,
improving not only individual performance, but also collaboration.” [3] Luckily, there are
many such tools that facilitate this visual interaction, such as Google Hangouts or Skype.
These tools also allow users to share screens so that it is easy for team members to view
work together.
When using these video conferencing tools, it helps if someone like the Product Owner
checks before the meeting to make sure that all the tools are working as expected and
that any documents to be shared, such as an agenda or a piece of work to look at, are
properly dispersed or already pulled up on the screen. These tips help to allow any
conferencing to go smoothly. It also doesn’t hurt to have quick recaps of certain

6. important meetings that are sent out afterwards just to ensure that everyone is aligned
and on the same page.
It is important to note that video conferencing is not always the right tool, and Product
Owners should be mindful of choosing the right tools for communication. For instance,
something like Slack, a real-time messaging application, might be a good way to
communicate minor news instantly to the team, but the message recipients don’t
necessarily have to stop their work to respond right away.
As we will discuss later on in this article, there are also regular meetings built into the
SCRUM process that help facilitate communication among the team.
 Cultural Differences: cultures can differ dramatically in terms of values, work style, etc.
These differences can impact how the team works together. For instance, ProductBoard
describes how topics that might be natural from an American’s perspective, like sports
or pop culture, might not be as easy a conversation topic for someone with a different
cultural experience. There are also norms that come into play in terms of how people
behave with their colleagues and superiors that might differ across different cultures
[6]. It is important to note that cultural differences can also exist between different
regions of a country. Many people in the United States might say, for instance, that the
East Coast and West Coast have pretty distinctive cultures.
Strategy: It is important to build a positive team culture that is focused on collaboration
and respect.
In general, the Product Owner should look for opportunities to build rapport on the
team. During a kickoff or introductory meeting, it might help for everyone to take some
time to describe his/her work style and preferences. One thing that new employees at
Atlassian do is post an “intro blog” where they describe some things about themselves
professionally but also personally (hobbies, interests, family, etc.). According to the
company, this practice “really helps bridge the gap between offices” [5].
To build rapport and help bridge potential cultural gaps, it also helps to encourage 1:1
video conferencing sessions between team members. This allows the team to get to
know each other and share knowledge in a more casual environment. Whenever it is
possible and makes sense given other constraints, it is also beneficial to have team
members spend some time in other offices to experience a different culture [5].
 Time Differences: there can difficulty for geographically distributed teams, especially if
they cover various time zones, to find an appropriate time to access each other and
communication tools. This challenge becomes exacerbated as the time difference

7. between group members increases. According to Agile Connection, “teams that cannot
establish overlapping hours will likely have a lower average velocity.” [3]
Strategy: This is a tough problem that many dispersed teams face. One of the most
important things is to ensure that the team can attend the stand-ups. This means that
the teams has to ensure that they have the proper communication tools and that core
hours are established. Ideally, the team can find a workable time for everyone.
Sometimes, when teams are twelve hours apart for instance, the teams may have to
alternate who has to stay late/get in early to attend the meetings [3].
It also helps to have “developer to developer handshakes,” which means that the
development team should communicate all the important changes made during their
working hours to the teams in other locations. Another good practice is to have team
members jot down status notes at the end of their day, so that they can share with
others the work he/she completed during the day, build status, and any issues that
arose and whether or not those issues were resolved [7]. These practices help to
prevent the duplication of time-consuming work and also ensure that everyone is in the
loop with important work being done and changes being made.
 Space Constraints: this is typically thought of as an issue that impacts collocated teams
working in the same office space, but it also affects geographically distributed teams as
well. For instance, the space from which the various team members are working from
could be an environment that is not conducive to communication and collaboration. For
instance, someone could always be working out of a loud coffee shop that makes it
difficult for him/her to hear and be heard. Similarly, there could be a large team of six
people that all have to crowd around a single monitor to meet with a remote member.
This setup may make it hard for everyone to see the screen and follow along with what
is being shared or presented, thereby making it difficult for everyone to be an active
participant [3].
Strategy: It’s important to create spaces that foster effective collaboration. Those
spaces should be free from distractions and should be equipped with all the tools
needed to communicate. For instance, to foster 1:1 communication among team
members, one could install chat or VOIP connections on team members’ computers to
allow for that ease of working together. For group meetings, there should be a meeting
room space that is readily available so that the team can remain “agile” and quickly
gather to discuss pressing issues that may arise [3].
 Low Visibility and Transparency: because there are more communication barriers with
geographically dispersed teams than there are with collocated teams, dispersed teams
can often low visibility and transparency in terms of their work. This can be problematic

8. because the final product is a convergence of the work that is being done in various
locations, and the likelihood of unpleasant surprises can be higher when there is not as
much light shone on the work that all the dispersed teams are doing [4].
Strategy: Over-communicate, over-communicate, over-communicate! It helps for
everyone on the SCRUM team to over-communicate about his/her work, but it also falls
on the SCRUM Master, Product Owner, and team leads to regularly check in and have a
pulse on what’s occurring. For the Product Owner in particular, because he/she guides
the vision of the project, it is important that he/she communicate any changes or
updates to that vision with all dispersed teams. Many companies have an internal wiki
or board of some sort where everyone can easily post these updates [6].
2.1 When Colocation is Not Possible: Technology as a Solution
Agile is adaptive, not predictive. There is less planning upfront and much of the energy comes
from new ideas from the interactive meetings. Driving effective meetings with a disciplined
agenda, does help increase the pace and quality of the work the teams perform. There should
also be impromptu conversations with the teams when performing their work, for which
reason, having everyone on the team in a collocated site is most beneficial.
Having a shared space or colocation, enables the team to know more about what is going on
around them, hear conversations or what is referenced as osmotic communication. Sitting
together in a shared workspace helps the team to understand others progress. It helps to keep
out of other meetings when collocated. [10]
In this company, the teams have 2 colocated areas, one on the east coast and another on the
west coast. As the team grows, they know they need to find solutions to generate effective
communication when they hire teams who will work from home or when the company decides
to go global.
Here are some recommendations for altering the colocation to benefit virtual teams:
 Skype or some form of instant message for the teams to chat
 Live video conferencing calls with the use of video cams for a personal touch
 If possible, video camof the collocated room onsite to allow others who work from
home feel like they are also there in the room with the team
 Phone conversations and text messaging
 Use of the Agile software tool is where teamwork is displayed and allows for
asynchronous communications
 Video clips through YouTube can also be a means to convey conversations and exchange
dialog
3.0 Driving Productive Daily Scrums for Geographically Dispersed Teams

9. The Daily Scrum which is to last no longer than 15 minutes, gets the team to come together,
and collaboratively guides the team to deliver working software. The continued
communication, robust dialogue, and interactions of the 15 minute Stand-Up helps to keep the
project on task. When the team is dispersed, having this valuable meeting can be more
challenging but possible.
Status meetings are not collaborative, one person presenting to an outside group. Presenting
work to other groups takes times, there may be other workgroups, and many channels of
communication resulting in a lot of time, resulting in 20% less work [10].
3.1 Daily Scrum
This is a time where developers communicate with each other, a developer activity, where
others should sit and listen. Three questions are asked: What did I do yesterday, what am I
doing today, what is getting in my way. The last question is for the Scrum Master to help
provide support and breakdown barriers. These questions can still be asked and the 15 minute
Daily Scrum and technology to get the team at a convenient time if not located too far apart by
time zone could be possible.
3.2 Daily Scrum Guidelines
 Self-Organizing – team stands in circle and discusses the 3 questions.
 15 Minutes – The team is to drive the meeting based on the 3 questions.
 Activity ends when the timebox finishes.
 How is the team interacting? Clues about the developers are thinking. If looking
towards the Scrum Master, may need more coaching on being self-organized.
 Typically in the beginning of the day.
o Geographic time zone differences would dictate when this time would be best.
o Technology suggestions—
o 1 Daily Stand-Up for each team is an approach
o Work to get the time zone aligned with the team
3.3 Daily Scrum Guidelines for Geographically Dispersed Teams
 East Coast and West Coast in the State have only a 3 hour difference. Plan to have the
meeting via virtual conference call at 9:30 AM PST which would be 12:30 PM EST.
o Allow the team to determine the best time collaboratively.
o Have the collocated teams self-organize and stand near the White Board
o Have a virtual meeting for others to view the White Board which can also be
noted in the shared Agile software system dashboard as a technology solution.
 If there are separate teams, it is suggested that each team have their own meetings.
o One Scrum Master per team
o One product owner for teams who are working on the same product

10.  The time zone differences for globally dispersed teams works best when the teams are
in one time zone. When the time zone goes beyond the 8-hour day and the teams do
not have a convenient time to meet, globally dispersed teams will need to devise the
best strategy to overcome this challenge as expressed earlier in this article in section
2.0.
After the Daily Scrum, the Scrum Master can help the team improve their activity performance.
Unlike going around to each person and asking what they are doing, can confuse the role, and
makes the team think they are being managed, when the key is to ensure the team is “self-
organized.”
4.0 Best Practices for Effective Meetings
Best Practices for Below are additional suggestions for the Daily Scrum and the other key
meetings to serve as a useful guide when working with geographically dispersed teams:
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.

11.  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 non-Agile
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
 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 screen-sharing
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

12. customers are representative of different markets.
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 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.
Distributed
Daily Scrum
Meetings
 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

13. 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.
o 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 Advertising. Advertise for collaboration.
o 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.

14. 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

15. 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, high-quality
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.
 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.

16. o 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.
o 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.
o 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.
o 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.
End-of-Sprint
Reviews
 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

17. 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.
Retrospectives
 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 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

18. 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.
[11] Reference: https://www.scrumalliance.org/community/articles/2013/july/managing-distributed-
teams Managing DistributedTeams - July31, 2013 byGauravdeepKaberwal
References
1. http://www.disciplinedagiledelivery.com/agility-at-scale/geographically-distributed-
agile-teams/
2. https://www.scrumalliance.org/community/articles/2013/august/distributed-teams
3. https://www.agileconnection.com/article/five-agile-challenges-distributed-teams
4. http://www.cigniti.com/blog/4-crucial-challenges-for-agile-testing-in-distributed-teams/
5. https://www.atlassian.com/agile/remote-teams
6. https://blog.productboard.com/the-5-challenges-of-distributed-teams-and-13-tips-for-
overcoming-them-60b20ffa4abb
7. http://worldcomp-proceedings.com/proc/p2015/SER2336.pdf
8. https://www.agilealliance.org/glossary/iteration/
9. The Scrum Sprint. https://www.scrumalliance.org/scrum/files/37/37e49f73-4f96-4d83-
bce4-beab40a52f57_600_579.jpg
10. Reference: Doug Rose, PMP, CSM – “Agile at Work: Driving Productive Agile Meetings”
Lynda.com
11. https://www.scrumalliance.org/community/articles/2013/july/managing-distributed-
teams. Managing Distributed Teams; July 31, 2013 by Gauravdeep Kaberwal