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/


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


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.


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,


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


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


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


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


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.


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.


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


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.


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


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%


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


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.


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.


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.


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%


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(


22/26


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%


24/26

"!ile not an agilespecifc tool% Microsot


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


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(

managing distributed teams_scrum

Documents