Download - Managing Distributed Teams_Scrum
-
7/25/2019 Managing Distributed Teams_Scrum
1/26
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 availableworforce. If I put it more precisely, tomorrow!s business will be more virtual anddistributed, with "distributed" as its ey element. Thus the need for better managingsuch teams, using the right tools and processes, is becoming increasingly critical forany enterprise company.#ere are some reasons for the shift and need for having distributed $gile teams%
&lobally distributed teams reduce costs.
They can reach the maret more 'uicly with a "follow the sun" model.
istributed teams epand access to new marets.
$c'uisitions as a result of consolidation results in companies woring together to
integrate their businesses.
*pansion can aid innovation and thought leadership.
Telecommuting gives options for communicating with teams effectively.
Collaboration tools ++ improved tools for distributed communications and server+based, multiuser tools for product development ++ are removing barriers, and more
teams view distributed collaboration as an alternative.
Handling distributed Agile teamsistributed teams heighten the need for clear, timely communication between sites. oumight be thining of increases in compleity due to more time -ones, language barriers,and cultural differences getting in the way.
uestions can include these%
$re distributed teams difficult to manage/
$re they failing to meet some epectations/
$re they having trouble woring as a team/
Is team morale a problem/
-
7/25/2019 Managing Distributed Teams_Scrum
2/26
$gile can!t fi every problem, but it can bring them out into the open, where the teamcan evaluate and correct them. $gile puts challenges under a magnifying glass. $s theimages under the glass grow larger, they scream for attention, and your team!sperformance will improve after it addresses the challenges and corrects dysfunctions.
The ey challenging areas that need to be addressed for distributed team managementare as follows%
Communication is the core issue among the distributed teams.
ifferent time -ones and conflicting woring hours impact communication and
collaboration.
Cultural and language differences impact communication and collaboration.
$n effective tool chain is needed for re'uirements repositories, 0C1,management, build and deployment setup, defect tracing, and pro2ect management
tools.
Three 3P practices that are particularly valuable% T, CI, and test automation
0cheduling 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 4ot providing access to calls, not set up for telephone calls in meetings,
difficulty identifying an unseen speaer, need to encourage participants, limiting
the conversation using round+robin techni'ue, importance of mute, checing for
any agreement or disagreement
How Agile helps address these challenges within all the Scrum ceremonies
-
7/25/2019 Managing Distributed Teams_Scrum
3/26
Self-managing distributed cheat-sheet tablePreparing forSprint Planning Product owner needs to understand the capacity and loo for
opportunities to create cross-functional teamswithin similar time
zones.
Team composition: Teams of more than 5 people should consider
geographic closeness and proper distribution of sills as well as team
si-e so as to build self+organi-ing teams.
Individual 0crum teams should aim to have thelowest distributionlevel possible, encouraging feature teams over component teams.
Disaggregate the higher-priorit features: istributed team
members, P6, and 0crum1aster develop more than one feature to
address a single solution that can fit within a sprint.
-
7/25/2019 Managing Distributed Teams_Scrum
4/26
Single bac!log for multiple teams: ifferent sill sets in the team
are needed to deliver user stories that are available across each
distributed location.
Separate bac!log for multiple teams:0crum teams wor
independently from one another and have their own individual sprint
baclogs, but the sprint dates are the same, maring their
interdependencies and riss in the sprint preplanning sessions or in a
daily 0crum of 0crums.
"elease planning: The number of sprints to map out and use with a
"loo+ahead planning techni'ue" will depend on sprint length,
dependencies, and the needs of the teams involved.
Sprint length: Teams that wor on a set of related products shouldsynchroni-e their sprint lengths and start dates to cater to their
interdependencies.
Sprint velocit:$lthough it is difficult to estimate the velocity in
pro2ects with multiple teams, they should always estimate the stories
they will wor on, because teams have different scales.
#anage dependencies within the teams:$gile teams will not try to
account for every possible dependency at the start of the pro2ect but will
loo ahead two or three sprints to ensure that teams are ready to dealwith dependencies, using the I47*0T model.
"is!s:uring the release plan, the P6 will want to identify the riss
associated with the pro2ect and teams, and, when possible, the
mitigation plan for each of them.
$oordinate multiple product owners of different teams: Product
owners meet regularly to discuss product baclogs, dependencies, and
lins between and boundaries between user stories of different teams.
%se Agile pro&ect management tools: It is mandatory to have
enterprise tools to manage teams and their wor related to the sprint and
for overall governance of the product.
'nvest in smarter development: Test automation and continuous
integration help $gile teams complete user stories within a sprint,
-
7/25/2019 Managing Distributed Teams_Scrum
5/26
woring together or for distributed teams.
$oordinating Agile and non-Agile teams: 1aing sure the non+
$gile team is aware of the priorities of the $gile teams and eeping
dependencies visible can help to prevent blocers between the teams.
(ace-to-face collaboration: The 01 should reduce the amount time
spent each day on pro2ect setup tass, which will etend the duration of
the pro2ect startup tass 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 baclogs of different teams, considering
their dependencies between the pro2ects, features, and stories beforegiving the commitment.
(irst level of sprint planning: The P6 and 01 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 P6 taes the impact of
dependencies into consideration when reprioriti-ing the product baclog
due to which team did not complete items during the sprint.
$hec!ing 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
wor revisit the estimates.
"eviewing changes based on sta!eholder feedbac!: The team
would review changes made since the preplanning meeting, and the P6
would confirm the priorities of the product baclog.
)ngaging sta!eholders:$t enterprise+level environments, toaddress the diversity of data by the 0crum team, the P6 can help
identify which customers are representative of different marets.
The second half of sprint planning
Deciding how to get the wor! done:Creating the sprint baclog ++ the P6reviews the highest+priority items in the product baclog with the team and
-
7/25/2019 Managing Distributed Teams_Scrum
6/26
helps the team to tae a guess at how much wor they can do within thesprint.
'dentifing tas!s:The P6 gives the team time to thin about the
tass needed to complete the wor items during the sprint planning
meeting. Teams run planning meeting discussion among all thestaeholders to get maimum clarity on the tass.
*aining commitment: 8ith a distributed team, team members who
are sensing that other team members have unspoen issues need to
tae responsibility for drawing the 01!s attention to the issues9 because
of this, the 01 needs to rely on the whole team to tae responsibility for
ensuring good communication.
o +ote:4o one should interpret silence as agreement. Team
members should phrase 'uestions in a way that they need a verbalresponse to improve the understanding within the team.
"elease plan chec! or update: *nterprise 0crum teams often begin
providing tass for high+priority user stories before the sprint planning
meeting. $ll team members discuss the tass 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.
DistributedDail Scrum#eetings
%sing the , uestions effectivel: The P6 and 01 should highlight
the importance of the three 'uestions in front of the team members so
they understand their purpose.
Answering the , uestions: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.
$oordinating the team on a dail basis:Priorities can change
daily. The daily 0crum meeting provides a daily synchroni-ation point forthe team and allows members to revise their plans regularly.
$ommitting to the team: Team members are maing 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.
-
7/25/2019 Managing Distributed Teams_Scrum
7/26
erifing progress:Tass not opening and closing regularly are an
early sign the team may be going off trac. Team members not showing
regular progress may be facing outside distractions the 01 should
reduce or remove.
"esolving bloc!ers:The 01 should create a list of blocers and
assign them to team members or managers. The 01 should also ensure
the team is burning through the blocer list.
Dail Scrum logistics:Conducting the daily 0crums when team
members are in the same time -one and spea the same language is
much simpler than for a team with members spread in multiple countries
and time -ones, having many different languages and cultures.
Dail Scrum logistics - was of communicating during the dailScrum:#aving face+to+face daily 0crum meetings gives the team the
highest level of collaboration possible.
o Teleconference meeting:istributed teams with overlapping
wor hours should use a teleconference call to the same phone
number every day to hold their daily 0crum meetings.
o ideoconference 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: istributed teams can use
four different methods to deal with distributed daily 0crums where the
team has members with no overlap in their wor hours, as follows% Daily
Scrums through documentation, liaison approach, alternating meeting
times, and share the pain.
Precautions to be ta!en while conducting distributed Scrum
meeting - 'ncreased distraction: :acground noise can be distracting
on a teleconference, so teams should chose a 'uiet room to conduct the
meeting.
/eeping the team engaged: Possibly the best way to stay engaged
and to mae sure that others on the team stay engaged is% awareness.
:uild awareness of what the team is woring on.
-
7/25/2019 Managing Distributed Teams_Scrum
8/26
o Advertising.$dvertise for collaboration.
o Attac! bloc!ers. The team and 01 should strive to fi all
blocers within one hour of the daily 0crum.
(acilitating the meeting: In a distributed environment, as individuals
come into the call, they will identify who they are. The 01 calls each
person and ass for their response. They may respond in the order they
arrived at the teleconference or the 01 may choose to call on each
person.
Ta!ing dail Scrum notes:This helps the distributed team members
overcome language problems, plan, and learn. Chat Tools and 8ii help
distributed teams do daily 0crums.
Scrum of Scrum:These can solve distributed team roadblocs,
future dependencies, commitments to other team members, issues with
integration, and other points that impact one another.
$ollaborationwithin a Sprint Scrum Teams shouldfollow continuous integration0 test
automation0 and test-driven development practiceto foster
distributed collaboration during the sprint and help teams complete user
stories within a sprint.
Documentation helps to overcome distance::ecause of language
barriers, distributed teams often need more written documentation than
co+located teams.
%sing the right tools:In a distributed environment, right tools and
effective practices can help team members communicate more
effectively.
aluing the whole team: The 01 should focus on an "us" versus a
"them" attitude in the distributed team, due to more delays incommunications and fewer opportunities to wor together.
Transparenc:istributed $gile teams should use pro2ect
management tools to identify tass that are open, in progress, and
completed so everyone is aware of the current status.
Handling new reuests in the middle of a sprint: In distributed
-
7/25/2019 Managing Distributed Teams_Scrum
9/26
0crum, it becomes mandatory that the team commits to sending
re'uests through the product owner(s), who will decide the priority of the
re'uest in the product baclog.
1ac!log grooming -- shortening the sprint: 0horter sprint lengths
mae the distributed team more responsive to staeholders. They also
allow the team to adapt to change more rapidly.
Dealing with defects: istributed 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
tass as per the customer log, or create a subteam to focus only on
handling these issues during the 0print, or ++ depending on the sill set
of the technical support team ++ mae the necessary code changes.
Disruptions at the team member level -- handling stories the
team cannot complete during the sprint::efore woring toward the
solution, the team first needs to identify the wor they need to do to
complete the story through meetings between team members or with the
product owner.
Handling bloc!ers during the sprint: In the large+scale enterprise
transitioning to agile, the 01 needs to hear from distributed 0crum team
members who are facing blocers and dealing directly with inhibitors will
help increase the velocity of the team over time, as well as the velocity ofother teams as they transition to 0crum.
"esponding to uestions during the sprint: ;or enterprise product
development, the P6 should loo for ways to match representative
staeholders with the teams! woring hours and to be available during
that time as well. ;or applications the team is developing for a specific
client, the product owner may not have the fleibility to choose
staeholder representatives available during the full woring day of the
client.
Sharing time zone challenges: 6ne approach to help manage such
cases is to mae sure that distributed teams in different time -ones are
fully self+sufficient and the team spreads the wor to minimi-e
dependencies.
$ontinuous integration: This is the ey to delivering stable, high+
'uality code consistently and 'uicly, which results in reducing time to
-
7/25/2019 Managing Distributed Teams_Scrum
10/26
maret for any distributed $gile team.
"eport an build failures to the team:$llows the distributed team
to now the current state of the code in the integration branch of the
source control system, generating a notification email for build success
or failure.
"educe the ris! 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 fi. 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
wor in parallel with the development.
)stablish greater confidence in the product:8hen developers are
doing the unit testing of their code, they should also create automated
unit tests as continuous integration certifies every build, developers can
mae changes with more confidence, and the entire team can remain in
sync with the latest build.
"educe the time to find integration issues:evelopers receive the
build status by email, so they can see and fi problems. The net time
the build runs, the build status changes from fail to pass automatically.
'mprove the efficienc of the team:istributed 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 wor.
1uilds can run at different freuencies:0etting up the hourly build
helps the distributed team now about a failure closer to the time of the
code integration, and team members can tae action on it earlier.
Test automation:To streamline the testing and help the distributed
team get as much done as possible within a two+wee 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.
-
7/25/2019 Managing Distributed Teams_Scrum
11/26
Test-driven development:evelopers write unit tests, the small
tests that fail first. Testers wor with developers to ensure that any later
tests do not repeat the wor the developers have already done.
o Provide documentation and wor!ing e2amples of code:
evelopers are writing their unit tests and providing documentation
and woring samples for the code they are testing. This allows other
team members to gain a 'uic understanding of the code when they
need to wor with it.
o Help reduce the time to fi2 defects: The developer may be
able to create a unit test specific to the case that is causing the
problem and fiing 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 fi manually.
o Help improve code ualit and provide a safet net for
changes:$n early defect detection process helps developers
improve the code nowing the eisting set of tests will detect any
problems. evelopers can thin of code in small units that they write,
test independently, and integrate later.
o Help team members wor! together and collaborate: 8hen
teams are evolving from a traditional development model to $gile, it
is a huge attitude shift to adopt T.
o Help teams move awa from big up-front designs: :rea
down a feature into smaller testable chuns and create small teams
to start woring on some code right away. This code can be small
prototypes that act as tracer bullets through slices of functionality.
)nd-of-Sprint"eviews $ommunicate effectivel: Team members who are most able to
communicate effectively with the team, P6, 01, and staeholders
should present, so that they can represent the team in front of thecustomer.
(luent spea!er:$nother 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
speaer spea over the recorded demonstration.
-
7/25/2019 Managing Distributed Teams_Scrum
12/26
Scheduling for teams with overlapping wor! hours:1ae sure all
team members of the distributed team, regardless of the time -one, can
complete their wor and prepare for the demo within overlapping wor
hours.
Scheduling for teams with no overlapping wor! hours alternate
meeting time: The distributed team holds one sprint review meeting
during the normal worday for part of the 0crum team and holds the
other sprint review meeting during the normal wor hours of the other
part of the 0crum team.
Things to be followed b distributed teams in sprint review
meetings -- !eeping trac! of the sta!eholder comments: uring the
sprint meeting, the distributed team needs to capture these comments
so the product owner and the development team can decide which onesthey will act on.
Demos maprovide a false sense of completion:$dd a R$;T
watermar on any screenshots or to use data that is clearly not real, to
avoid a false sense of completion to the staeholders.
"emote demonstrations --networ! delas and poor
performance: istributed teams should test their tools ahead of time to
be sure the distributed meeting will run smoothly, without networ poor
performance. The team can also consider maing the recordingsavailable for download before the demonstration meeting and discussing
them through a teleconference.
Services ma var b location: 0et up a single machine with a
standard configuration that everyone uses during the demonstration
meeting. :efore the start of the meeting, distributed team members can
access the machine (remotely or locally) to boomar lins, set up
scripts, and do a 'uic dry run of their presentation.
"etrospectives )ffective and overlapping retrospective meeting timings: To be
effective and timely, distributed teams should call 2oint retrospectives as
soon as possible after having their own team meeting. epending on the
number of teams involved in a 2oint retrospective, teams may want to
limit the number of participants from each 0crum team to eep the
-
7/25/2019 Managing Distributed Teams_Scrum
13/26
meeting productive.
Hold &oint retrospectives:The distributed teams woring together
will conduct their individual sprint retrospectives at the end of each sprint
and then will conduct a 2oint retrospective. The benefit of this approach is
that it promotes communication between the various teams involved in a
pro2ect.
$onduct milestone-based larger retrospectives:istributed team
members should reflect and comment on release 'uality and capability.
The team defines and records the various milestones within the pro2ect
to improve on or continue in future releases.
1uild trust: The 01 needs to develop a sense of trust and honesty
within the team, which in turn will lead to a wider degree of openness.
"educe effects of distance:The facilitator of a distributed
retrospective needs to understand the cultural differences in the team.
The 01 needs to understand how different cultures interact when they
want to change something or have issues they want to tal about that
can help the facilitator encourage participation from all team members.
Set e2pectations:The facilitator, for distributed teams, should tal to
the team ahead of the first retrospective and eplain the epectations for
the retrospective.
%nderstand the team members3 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.
"espect cultural differences:The 01 needs to mae sure cultural
difference should not be taen lightly during the retrospective meeting in
distributed teams.
As! for comments before the retrospective meeting -- what went
well and what can we improve4$s the team for comments about
issues or problems they noticed since the previous 0print retrospective
and summari-e 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 net retrospective.
-
7/25/2019 Managing Distributed Teams_Scrum
14/26
Provide uestions to focus the discussion:In a distributed setup,
team members respond to a set of 'uestions 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:uring 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.
"elease retrospectives: The team tals about the pro2ect, then
defines and records the milestones in the pro2ect, lie initial training,
team formation, stand+up meetings, start of development, middle of
release, deployment, etc.
$onclusion
istributed teams need to go for mandatory training to run into full+fledged $gile teams,
so that they can better understand the potential impact of maing the change. $lthough
the pro2ect teams learn from ad2usting to distributed $gile teams, it becomes more
important for them to understand and adhere to 0crum, rather than immediately thining
that 0crum needs to be changed.
I believe that collaboration becomes highly important in distributed teams as they are
collectively responsible for delivering on their commitments. 6ne important ey 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
wor.
$nother ey to embracing a self+managed distributed team is valuing the entire team
and not having an "us versus them" atmosphere between different 0crum teams on thepro2ect. The best ways to build relationships within teams is to find ways to share the
pain of being a distributed team9 to get to now each other as people9 and to foster
fre'uent, 'uality communications between team members.
$nother 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
-
7/25/2019 Managing Distributed Teams_Scrum
15/26
woring for them. 8hen they need to ad2ust, they should do so as 'uicly as possible.
I must say the teams with members distributed across sites can enhance code
ownership and improve the autonomy essential to team self+organi-ation. $utomated
communication of product and sprint baclogs throughout the organi-ation, combined
with upward reporting of teams! status to management, can tightly align and nit thedistributed teams together. + 0ee more at%
https%
-
7/25/2019 Managing Distributed Teams_Scrum
16/26
Distributed Teams
There are many different eperiences and pieces of advice with regard to distributedteams, and most deal with how to get the communication to wor in the best possibleway within the given parameters. $ctive use of electronic aids such as 0ype,
Communicator, 0harePoint, etc., are often recommended to ensure goodcommunication across borders and time -ones, and to remove some of thedisadvantages associated with having a distributed team.
There is a common perception that the co+located team is better positioned to ensuregood communication and deliver more efficiently than distributed teams. :ut in a worldwhere global collaboration becomes increasingly common, teams often consists ofpeople from different parts of the world woring together as distributed teams. $nd withthis, it is interesting to note that while there are some clear challenges with having adistributed team, there can also be some advantages.
$ distributed team can be cost+effective. This can be manifested in the form of reducedtravel costs and the use of resources from countries with lower labor costs. Travelingcan be replaced with efficient wor, and the reduced travel load in itself can be amotivating factor for many.
$ distributed team can also provide access to higher sills, because you do not have tolimit your resource search to a specific area.
In some cases, having a distributed team also enables some team members to sittogether with customers in multiple locations. 0ome also claim that distributed teamsare more focused on information sharing within the team ++ but then again it can also
mae the communication more formal, with the advantages and disadvantages this maycause.
:ut there are obviously some definite challenges with having distributed teams. 6ne ofthe 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 todeal with in terms of communication and cooperation.
1any development practices (e.g., from *treme Programming) stipulate rules forteamwor, and it is important not to ignore such practices 2ust because we have adistributed team. If your current situation maes it impossible to follow a defined
practice, you should either modify or replace it with something that wors better withinthe given situation. The ey is to mae sure that you are aware of the purpose of thepractice, and mae sure that an alternative or replacement provides the same benefit.;or eample, pair programming can be replaced or simulated by performing codereviews. ser stories can be written out in even greater detail to mae up for some ofwhat you!ll be missing if you cannot have the same degree of conversation within theteam during a planning session. onDt get me wrong ++ I would never state that this is agood substitute for conversation, but I use this eample to show that, even in cases
-
7/25/2019 Managing Distributed Teams_Scrum
17/26
where we can!t follow the very core beliefs of the $gile 1anifesto (interactions overtools), we should still mae some effort to improve the situation.
$nother challenge with distributed teams is that we often fall for the convenience ofassigning tass based on the team!s spread. This can result in speciali-ations within the
geographic locations, and so we create dependencies between these locations. Thiscould greatly reduce the team!s ability to complete a function within an iteration.$ctually, studies show that such negative effects increase with the si-e of the team.?
0ome would argue that it can be impossible to avoid such situations. 0ometimes all theeperts within a specific field are in 2ust one of the locations, and therefore it!s notappropriate to allocate this epertise to the other locations. 0uch discussions will alwaysbe based on the different eperiences of different people, which may not be directlycomparable.
$ person who claims that ensuring competence distribution across locations maes
sense probably is 'uite right in the circumstances he or she eperiences. 1aybe muchwas to be gained from having a cross+functional team 2ust because in the given casethere were many dependencies across tass. 6r because the duration of the deliverywas so far out that investment in training and transferring sills was actually 'uitereasonable.
$ person who claims the opposite, who simply does not see the point in having a cross+functional team, will also have eperiences that support this. 1aybe it was a shortenough delivery duration that it didn!t pay to drive nowledge transfer. 1aybe there weremore people at a given location with the same sills and therefore they were not sodependent on one individual. Perhaps the dependencies across tass were so small
that it wored 2ust fine to have different epertise in various locations.
1ost people, regardless of eperience, will agree that there will always be an advantageto having a cross+functional team. The intention behind this principle of 0crum is thatyou should avoid dependencies on individuals and mae good decisions based ondiscussions among several people who have epertise in an area.
:ut ultimately it must be taen case by case, and you must observe and evaluate whatmaes the most sense in the given situation.
In a global setting, language itself is another challenge within distributed teams, as aredifferent woring hours (time -ones) and especially cultural differences. In 0candinavia,many people believe that we are more practiced at enhancing collaboration and that ourstyle is more inclusive compared with, for eample, the .0. 1eanwhile, a leader in the.0. might find it easier to confront employees whose performance is inade'uate, whichmany eecutives in, for instance, 4orway are reluctant to do. In $sia you are een not tolose face9 in 0audi $rabia, it is disrespectful to sit with legs crossed and show the solesof the feet9 in Russia, an inclusive leadership style is perceived as a wea leadershipstyle.
-
7/25/2019 Managing Distributed Teams_Scrum
18/26
There are countless eamples of cultural differences, but what does this mean in thecontet of securing communication within a distributed team/
espite all these cultural differences, we humans are very similar when it comes torelationships with others. It!s primarily about building trust by respecting others, with
words and actions that are in relation to each other.
$ll functional teams should be based on these principles and, therefore, establishingthese principles is perhaps the most important thing one can do to ensure that teammembers have the opportunity to build this basic trust in each other.
Confdence exists at several levels in a distributed team
Trust is built through interaction and communication. $ developer who taesresponsibility for a tas and delivers it well inspires confidence in others. $ 0crum1asterwho protects the team has the confidence of the team. $ product owner who dares trustthat the team will use its technical epertise to deliver in the best possible way willcreate mutual trust and increased commitment from the team.
:ut confidence also means accountability. If the team feels that others do not deliver asepected and that this is not handled and solved, you!ve got a situation that could bedamaging to both motivation and efficiency. $ccountability can also be seen in that aproduct owner sets epectations that the team delivers on, according to what they havecommitted to for a sprint.
To lay the foundation for mutual trust and cooperation, it!s often recommend thatdistributed teams gather physically at the start of a new pro2ect. This helps teammembers get to now each other, which forms an ecellent basis for continuing dialogueand cooperation. It also provides a good opportunity for the team to establish a commonset of rules for collaboration and communication. (This is something every new teamshould do at its inception, regardless of whether the team members meet physically ornot.)
In =>>@, a study of global IT teams revealed that ey factors for successful distributedteams included a set of common goals, open dialogue, attention to buildinginterpersonal relationships, and maing sure that someone was responsible as afacilitator to support collaboration and communication.=
8hat is interesting in this contet is that this study addressed all types of IT pro2ects, notonly those based on the $gile framewor.
:y using the 0crum framewor, a team should, theoretically, have very good conditionsto ensure a focus on these ey factors. The daily 0crum encourages regular dialogueand communication between among team members, the team sets out common goalsfor each iteration, and the 0crum1aster acts as facilitator.
-
7/25/2019 Managing Distributed Teams_Scrum
19/26
This is in no way an attempt to argue that the 0crum itself is the solution, but theprinciples that the framewor is built on will help eep a focus on the ey factors that, aseperience shows, are important for efficient distributed teams. $gain, bac to theeternal mantra that should form the basis for all $gile development% nderstand theintent of the framewor and established practices, base them in reality, and mae
ad2ustments so that one can achieve the intention.
Conclusion
In distributed teams with different nationalities, it is wise to be aware that people haveeperiences and epectations based on other traditions. &enerally speaing, it is oftenalso wise to be open to other ways of doing things. :ut the basic epectations of trustand cooperation are largely the same, regardless of borders and frontiers. $ very good
rule of thumb is to always have more 'uestions than we have answers. $c'uire moreinformation 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 assisteveryone in maing the right decisions.
8hen it comes to having a distributed team, then, it!s primarily about building trust andhaving mutual respect for each other, along with a common focus on communicationand as close a collaboration as possible.
It!s difficult to give one+si-e+fits+all advice, but I hope the areas discussed form goodsuggestions as to what can and should be focused on when woring with distributed
teams. In practice, the world is such that no pro2ect or team is e'ual, and you have to doassessments and mae decisions based on the assumptions that apply to theappropriate team. In its simplest form, it!s about communicating, observing, andreacting.
-
7/25/2019 Managing Distributed Teams_Scrum
20/26
"esources?Craig Earman and :as 7odde, Scaling Lean & Agile Development. $ddison+8esleyProfessional, =>>F.=r. 4ii Panteli, lecturer in Information 0ystems, 0chool of 1anagement, niversity of:ath. (Ein to survey% http%
-
7/25/2019 Managing Distributed Teams_Scrum
21/26
12 Best Practices or Distributed
Development Teams Using Agile and
crum Met!odologies"it! toda#$s tec!nologies and collaboration tools% sot&are development
pro'ects are no longer impeded b# distance bet&een team members( )n
t!e past% businesses soug!t o*s!ore development solutions strictl# or
cost savings% as companies &it! limited )T budgets could build
applications or less using resources in locations &it! a lo&er cost o
living( Toda#% t!e# are starting to reali+e t!e true value o being able to
assemble teams o experts an#&!ere in t!e &orld(
Distributed Development% a pro'ect deliver# model in &!ic! &or, is done
across multiple &or,sites% is rapidl# becoming a common approac!(
"it!in a distributed development model% team members p!#sicall#
located in di*erent places-buildings% cities% countries% or continents-
&or, collaborativel# to complete pro'ect deliverables( "it! t!e rig!t
approac!% a distributed development team can avoid or overcome
common c!allenges and become a !ig! perorming team t!at en'o#s
&or,ing toget!er to deliver business value(
.o&ever% t!e distributed development team model can still be
c!allenging i t!e rig!t people% processes% and tools are not in place(
Additionall#% distributed development teams &ill struggle to produce
results i t!e# are not operating rom t!e same set o principles or !ave a
s!ared understanding o pro'ect goals( Based on m# experience% t!e
ollo&ing are best practices or distributed development teams%
particularl# t!ose utili+ing agile and scrum met!odologies( ome o t!e
success criteria can also be relevant to teams t!at &or, in t!e same
location% but pla# a bigger role in distributed teams(
-
7/25/2019 Managing Distributed Teams_Scrum
22/26
-
7/25/2019 Managing Distributed Teams_Scrum
23/26
5/ Ad!ere to engineering best practices and development
standards
T!e team s!ould !ave a common understanding and agreement on t!e
best practices and standards t!e# &ill adopt and ollo&( T!is includes
development procedures% code standards and st#les% patterns% and ot!er
best practices t!at result in an extensible% ualit# product( T!ese best
practices and standards ma# be at t!e industr#level or ones t!at t!e
team defnes or t!emselves( "!en ever#one is operating under t!e same
standards% t!ere is a better c!ance t!at code merges and integrations &ill
be successul and !ave e&er deects(
6/ 7espect time +one and cultural di*erences
"!en team members are spread across time +ones% ever#one &ill need to
compromise on &!en dail# standups and ot!er team meetings are !eld(
T!e times s!ould be as consistent as possible( T!is &ill allo& team
members to plan amil# obligations and ot!er non&or, commitments and
!ave a sense o consistenc# in t!eir sc!edule(
Additionall#% &!en team members come rom di*erent culturalbac,grounds% it is important to respect eac! ot!er$s !olida#s( 8ver#one on
t!e team s!ould not !ave to ollo& t!e !olida# sc!edule o t!e corporate
!eaduarters or primar# o9ce team( c!edules and resource availabilit#
s!ould ta,e into account t!e :global$ !olida# sc!edule(
;/ Use o online tools or agile artiacts
T!e use o online tools is ver# important or ,eeping a distributed team
inormed and organi+ed( T!ere are man# good tools out t!ere or creating
and maintaining product bac,logs% organi+ing and planning sprints%
managing tas, boards% monitoring burndo&n% and trac,ing bugs and
ot!er &or, items( T!e use o common productivit# apps 48xcel%
-
7/25/2019 Managing Distributed Teams_Scrum
24/26
"!ile not an agilespecifc tool% Microsot
-
7/25/2019 Managing Distributed Teams_Scrum
25/26
@/ Cultivate commitment to product and deliver# ualit#
Creating a set o s!ared goals at bot! t!e milestone and iteration level
can drive bu#in and commitment rom t!e team( ) recommend no more
t!an our goals> an# more can cause t!e team to be over&!elmed and
unocused( ) also believe it is important to !ave a mix o productrelated
4&!at t!e team is delivering/ and deliver#related 4!o& t!e team
delivers/ goals( During release and sprint planning events% t!e team
s!ould identi# action items aligned to eac! goal to ensure t!e goal is
met( 8ver#one on t!e team s!ould be assigned at least one o t!ose
action items to oster eual commitment to&ard t!e goals( T!e scrum
master or team lead s!ould t!en !old regular c!ec,points to see &!ere
t!e team is at &it! t!e action items and gauge overall progress to&ardt!e goals(
1/ Allo& or proper onboarding and training
) travel to t!e corporate !eaduarters or some ot!er primar# acilit# or
training and ot!er rampup activities is not easible or ne& team
members% t!en a structured onboarding and training plan &ill !elp
ensure t!e# are properl# setup and trained( Create an onboarding plan
outlining exactl# &!at training t!e# need to complete% &!at tools t!e#
need% and &!at resources t!e# need to access( Distributed teams s!ould
also institute ongoing coac!ing and mentoring bet&een senior resources
and t!e 'unior or midlevel resources( T!is ensures t!e less experienced
team members are getting t!e support and guidance t!e# need% and
development standards and best practices are consistentl# adopted
across t!e team(
11/ reuent demos and retrospectives
Distributed team members s!ould s!are progress and s!o&case t!eir
&or, on a regular basis to build trust and confdence &it! t!eir
sta,e!olders and ot!ers &it!in t!e distributed team( or example% t!e#
can build &or,ing protot#pes to supplement design plans% conduct
-
7/25/2019 Managing Distributed Teams_Scrum
26/26
reuent code revie&s &it! peers and ot!er sub'ect matter experts% and
acilitate live demos during t!e sprint revie&( Distributed development
teams s!ould also carve out time ater eac! sprint or some ot!er
consistent cadence to revie& communication practices% tool usage% and
ot!er pro'ect protocol( )t is important t!at all teams do t!is% but evenmore so or distributed teams(
12/ Put it in &riting
Pro'ect documents and &ritten orms o communication are necessar# or
distributed teams to e*ectivel# communicate &it! ot!er team members
and sta,e!olders( impl# designed docs% brie meeting notes% and ot!er
orms o documentation !elp ensure intent is understood% decisions areclear and not orgotten% and inormation is s!ared and accessible to all
team members( 8stablis!ing good documentation practices in a
distributed team !elps to prevent dela#s and missteps during t!e
implementation% ostering alignment around &!at t!e team is doing(
T!e list o success actors or distributed teams runs longer t!an &!at !as
been covered !ere( B# !aving t!e rig!t processes and tools% mutuall#
agreed upon standards and practices% and commitment rom all team
members to ollo& t!em% distributed teams can be 'ust as co!esive and
collaborative as teams t!at &or, under t!e same roo( Personall#% ) fnd
&or,ing in a distributed sot&are development team model even more
re&arding due to t!e additional c!allenges t!at come &it! being in
di*erent geograp!ical locations( "!en a distributed team is able to
ac!ieve t!eir goals and deliver# business value on a regular basis% it
reinorces best practices and ,e#s to success(