AWB - 13 - Agile Distributed Teams

431 Agile White Book – AXA Emerging Markets EMEA-LATAM
Chapter 13
AGILE DISTRIBUTED TEAMS
V1.0

Contents
WHAT I WILL LEARN IN THIS CHAPTER?.................................................................................................................................................................... 434
UNDERSTAND THE CHALLENGE .......................................................................................................................................................................... 435
GET IT RIGHT FROM THE VERY BEGINNING ............................................................................................................................................................. 438
DEFINE GOOD PRACTISES ......................................................................................................................................................438
FOCUS ON VERBAL COMMUNICATION .....................................................................................................................................439
GET THE RIGHT TOOLS ..........................................................................................................................................................440
ESTABLISH THE RIGHT PROCEDURES ........................................................................................................................................442
FOCUS ON THE TEAM........................................................................................................................................................................................ 445
PRODUCT OWNER ...............................................................................................................................................................445
SCRUM MASTER..................................................................................................................................................................446
DEVELOPMENT TEAM ..........................................................................................................................................................446
REINFORCE THE PRACTISES................................................................................................................................................................................ 447
TECHNICAL PRACTISES..........................................................................................................................................................448
DISTRIBUTED GOOD PRACTISES..............................................................................................................................................449
TUNE UP MEETINGS & ACTIVITIES ........................................................................................................................................................................ 450
SPRINTS.............................................................................................................................................................................450
PLANNING MEETING............................................................................................................................................................451
SPRINT REVIEW...................................................................................................................................................................452
SPRINT RETROSPECTIVE ........................................................................................................................................................453
PRODUCT BACKLOG REFINEMENT ..........................................................................................................................................454
DAILY SCRUM MEETING .......................................................................................................................................................455
SCRUM OF SCRUMS .............................................................................................................................................................456
ARTEFACTS.........................................................................................................................................................................457
THE EXPECTED OUTCOME ................................................................................................................................................................................ 458
TAKE AWAY.................................................................................................................................................................................................. 459
CHECKLIST 13.1................................................................................................................................................................................................ 460

Agile Distributed Teams
Being part of a geographically distributed team or
planning to implement one soon offers many
challenges. Agile framework faces this by placing
the focus on many key areas such as close
collaboration and the delivery of high business
value in a sustainable and periodic way.

What I will learn in this chapter?
AGILE DISTRIBUTED TEAMS
I know how to be prepared for a distributed team.
I know the architecture required.
I learnt how to tune-up the Scrum meetings.
I KNOW HOW TO
PREPARE THE
INFRASTRUCTURE
I AM
READY TO
START THE
PROJECT
HOW TO ESTABLISH THE RIGHT
PROCEDURES FOR THE REMOTE
TEAMS
- Meet People
- Tune up Activities & meetings
- Re-enforce practises

UNDERSTAND the challenge
Although the Agile framework is being used increasingly for product development, people are still
worried about adopting it because of various concerns, especially related to using it with
distributed teams. That is also supported by the idea that Scrum is only applicable for small and
collocated teams. Fortunately, the Agile Principles and Practices are the same whether you
work in a distributed environment or not.
As we will see, none of them need to be diminished, discarded, or modified, quite the opposite,
they must be reinforced at the core of the company and Teams.

Don’t forget the 6th principle of the Agile
Manifesto: “The most efficient and effective
method of conveying information to and
within a development team is face-to-face
conversation.”
The more distant the communication, the more difficult is to get good results if no supporting
practises are used.
The higher up the arrow you are, the richer and easier the communication is. We have also
seen that success rate of distributed product development is increased when communication is
structured and clear for all the parts.

Even with close locations, where team members are in the same geographical area and could
easily get together physically, there are many risks, such as:
- People having different priorities.
- Misunderstanding of the requirements.
- Lack of trust.
- Using documentation as a way of conveying information.
- Not having the tools to share the ideas clearly.
People don´t generally have many cultural differences when Teams are nearshore -located in
the same country or in a close place-, but when they are offshore -far away from the main
location-, the story is completely different. Individuals experience additional challenges, such as:
- Cultural differences.
- Time-zone differences.
- Language barriers.
- Lack of bonds.
- Partial communication (i.e. hearing a voice but not seeing a face)
- Placing themselves in lower “levels” of a hierarchy as a result of being in the remote
place.
Infrastructure and other resources are mainly needed in order to provide a great experience for
everyone. Unfortunately, people in those places might feel uncomfortable asking for an
investment in tools or resources to improve the quality of communication. This is mainly as a result
of a misunderstanding of the value obtained from those tools versus its costs.

GET IT RIGHT from the very beginning
DEFINE GOOD PRACTISES
When a team is spread across various locations, a common set of practices has to be
established first in order to achieve the necessary levels of collaboration. It is very
important you emphasis on the areas that improve interaction between people.
As communication is the main key to a successful project, I recommend you to:
- Setup and keep a constant eye on an early communication procedure in the
development cycle, including all the necessary resources.
- Keep doing all Scrum meetings, such as the Daily Scrum, Retrospective, etc.
- Establish a common language between the parties.
- Make an early investment in face-to-face meetings to build the initial sense of Team.
(i.e. having the Product Owner traveling to the offshore place). This is an essential expense
to ensure better early communication.
You will see many factors that influence these recommendations later on this chapter.

FOCUS ON VERBAL COMMUNICATION
Verbal communication in distributed Teams is one of the most important areas to improve. We
have seen that it can be limited as a result of:
- Members not being fluent in the same language.
- Accent and dialect limitations.
- Cultural differences (work ethics, intellectual property, different ideas about commitment,
etc.)
Making communication very concise, clear and giving simple instructions is always something
to work on. Written communication can also be greatly beneficial if it supports a verbal
message.

GET THE RIGHT TOOLS
Even before teams start working on the product, infrastructure should be set up and fully
working in order to achieve predictable results. There are 6 actions that you should prepare well
in advance:
Install webcams, comfortable and high-quality headsets plus microphones on each
PC.
Install an easy-to-use tool to allow people to establish a multi-user web-
conference without leaving their seats.
Setup an always-on videoconference in each team’s location. A high-resolution wide-
angle webcam and large screen is the most appropriate option.
This piece of equipment acts as a window between the two Teams and enables
instantaneous conversations and collaboration. Additional cameras can be installed, for
example, pointing at the Board/Kanban and the Continuous Build/Integration status.
Install a desktop-sharing software with virtual whiteboard capabilities in each
computer and make sure people from the Team are able to create new users without
calling in an expert.
We also recommend you to check some of the available tools such as TelePresence,
LifeSize, Google Hangouts, ReadyTalk, and GoToMeeting. Scrum Teams also benefit
from the use of other tools such as ScrumWorks, Flowdock, Linoit, NoteApp and
PlanningPoker (.com).

Tools that offer a decentralised code management and track bugs and requirements are
also needed (check this with the Scrum Team).
Set up a dedicated room with videoconferencing capabilities in order to support the
required meetings (Daily Scrum, Sprint Planning, etc.).
Organise a face-to-face workshop for the whole Team where you explain how to
use the different tools and don’t forget to re-do it when new members join the Scrum
Team.
Open the checklist “Distributed teams Infrastructure” to review the previous requirements.

Don’t forget to rotate repeating meetings to
accommodate the schedules of all attendees!
ESTABLISH THE RIGHT PROCEDURES
In a distributed environment, adapting is mostly about removing the sense of being
distributed. It is important for you to instruct each person about the additional communication
responsibilities required when working with offshore teams. For that to happen, individuals should
make sure that the following steps are followed:
A communication procedure is defined.
a. Establish core hours
These are those hours where teams overlap/can be bothered. Remember that time
difference can be considerably different in distributed Teams. The goal of the
team should be to create the best possible product and for this to happen, the sub-
teams should be able to work together. When the workday for one sub-team is over,
the other should be able to continue working without about issues. For this to
happen efficiently, both teams must work together, and possibly overlap, to share
work without quality suffering. The most important aspect to remember for all
teams is to respect the time of other teams.
b. Make an agreement on communication channels.
c. Wherever possible, conversations should take place live rather than via email.
Establish a preferred way to document a conversation. We recommend you to
place the outcome in a visible place near the Team´s board

Role’s availability is established.
If you are using Scrum, it is imperative for the Product Owner to communicate to
the Team that it is acceptable to call her if they have quick or urgent questions,
without requiring any pre-scheduling, otherwise members could keep crucial
questions hidden under the carpet for days. This practise should be emphasised to
help remove the burden of sending emails. A good way to reinforce it is by making
the Product Owner’s information available in the following way:
Antonio Fernandez (Product Owner)
Call me if you have questions.
Desk: +34 12345678 mobile: +34-987-654-321
Skype: afernandez@hotmail.com
Office hours: Mon-Fri, 9.30am-7pm Spanish Time
Malta Time= 10.30pm-8pm
For urgent call me on my mobile
Mon-Fri 9:30am-9:30pm
CE Time = 10.30am-10.40pm
A facilitator is chosen on each side.
Having a facilitator in each location is highly recommended when you have
distributed meetings: it makes things run smoother and removes any additional
roadblock before the event happens. In one place the Scrum Master can take it,
while in the other, a Team member or another person with can be designated.

Meetings are planned for longer time-boxes.
Virtual meetings take slightly longer. Everyone should understand it beforehand
and accommodate the times accordingly. A good Scrum Master is creative and
thinks about new ways to get individuals engaged in the meeting, such as using the
Round Robin technique, Pass the (electronic) Pen, etc.

FOCUS on the Team
PRODUCT OWNER
If the Product Owner is in a different geographic location, he should be actively involved and
committed. He should be clearly available and make sure the Team understand that they can call
him and ask questions if needed (review the “Establish the roles´ availability” section).
You should always avoid:
Having a Proxy Product Owner as they will rarely have the depth of domain expertise or
the decision-making authority.
Handling questions to the Product Owner by email unless they support a conversation.
Having the Scrum Master as the person responsible of compiling and emailing questions
to the Product Owner or back to the team. This creates an unnecessary bottleneck.

FOCUS on the Team
SCRUM MASTER
Many of the new responsibilities are related to maintaining the optimal conditions for the
Team and continuously removing the sense of being distributed. The Scrum Master needs
to be creative and think of new ways to enforce the Agile and Scrum principles and values.
Another area is to make sure that all facilities and tools are fully working before a meeting. A
strong emphasis on coordinating everyone in order to remove local and remote roadblocks is also
required.
DEVELOPMENT TEAM
When the team is split between several locations – for example, some members located in
Barcelona and others in the Casablanca, the challenges are often multiplied. In here, the level of
coordination, cooperation, and teamwork that is necessary to deliver working software is
even more demanding.
This is what we love:
- Spend periods of time working side-by-side with each other.
- Being co-located for the entire first two Sprints of the project.
- Defining Team Working Agreements when co-located and having quality time to do a
couple of retrospectives (Check Chapter 7 for more details about Agile Retrospectives).
- Setting our code standards & good development practises, Definition of Done
(DOD), Quality, Coding Conventions, and core hours.
It is good practise to regularly send a team member to travel to the other location to work side-by-
side with their colleagues. Another idea to improve interaction is to organise Brown Bags
session. A Brown Bag is a very short training or seminar taught during lunchtime by one member
to the whole Team about something she recently learnt (technology, tool, etc.). Implementing
these practises could be so much cheaper than its alternative: a low in morale and unproductive
Team.

REINFORCE the practises
Agile Practises in distributed projects are not removed but adjusted to the new reality; all roles,
meetings, and artefacts are always present. The main difference is that they need to be
implemented in a way that overcomes differences between time-zones, geographical locations and
cultures. Technical practises are also needed in order to align people and reduce technical debt.

All the Extreme Programming (XP) Practises
including Continuous Integration and
Deployment are extremely helpful in here.
TECHNICAL PRACTISES
There are a number of practices that are important for the Team´s success. Firstly, all team
members need to have the same development environment (IDE’s, plug-ins, code quality
checking configurations, Continuous Integration, etc.). It removes ambiguities and reduces
problems caused by inconsistencies between the locations. Secondly, all the Extreme
Programming (XP) practises should be widely implemented (check Chapter 11) to ensure good
quality code and alignment. A shared community can be created and maintained by the team in
order to share their selected best practises.
Remember that frequent and small increments are an excellent practise as they are more
manageable than the big ones.
It is vital that the required knowledge, capabilities and skill levels are evenly distributed across
both locations as an imbalance can result in less value produced each Sprint. The following
tools/practises are also something that will make the product development more fluent:
- A shared Continuous Integration server with a visible build status.
- Use of Test-driven development.
- Instant Messaging client available.
- Shared digital whiteboard for design and architecture discussions.
- Team wiki with project standards and personal details.
- Shared bug tracker.
- Team calendar, showing release dates, Sprint dates, holidays, etc.

DISTRIBUTED GOOD PRACTISES
There are 5 good practises that can make your distributed Team shine:
Always search for new ways to remove the sense of being distributed and
find the means to emphasise the Agile Values and Principles.
Minimise the impact of distribution. Effective distributed Agile development is
about finding the right mix of talent at every location.
Distribute Work Evenly. Make sure all team members understand their role and
have fairly equal workloads. A retrospective meeting is a good place to discover and
analyse how load affects them.
Set-up an effective pair programming scheme. Make sure individuals are able
to pair with someone remotely on a daily basis. If this solution isn’t possible, try to
replace pair programming with an equivalent practise.
Be aware of the different cultures and communication styles. Team members
are exposed to different situations during the life cycle of a large distributed project.
Being aware of cultural differences can help everyone understand how they work.
People can have different ideas about authority and that needs to be taken into
account during interactions. For example, it is fine to say “No” in Western countries
even to someone with higher authority. In many Indian and Asian cultures, the
appropriate response in the same situation would be “Yes” because one represents
more authority.

Organise a first and second sprint with
everyone co-located for members to build
trust. This consolidates relationships and
facilitates the huge amount of information
initially conveyed.
TUNE UP meetings & activities
SPRINTS
A shorter sprint (2 weeks) is always recommended as it allows people to increase the number of
feedback loops for the company. One good option is to start with this size and adjust it later.
You can expect lower performance in the first iterations as people require some quality time to get
used to the way they work, distance and tools but it should improve shortly after it.
Remember that trust is one of the main barriers when working remotely. If you are using Scrum
and you build a strong human relationship between all the members (e.g. Product Owner and
Team), issues can be sorted out easily.
Picture is extracted from blog http://jackass-3d-contest.wonderhowto.com/inspiration/trust-fall-0119323/
However, if the trust isn’t there, concerns will accumulate over time and translate into negative
events about the other party. It is tremendously difficult to undo these thoughts about others once
they have taken hold; at that point, the relationship has reached their lowest point, and every
interaction between individuals will be difficult and minimally productive and people will start
spending time documenting interactions rather than building software.

PLANNING MEETING
Another issue in distributed teams is the fact that they have less available time due to lack
of time zone overlap. In order to successfully manage that, you should:
- Split the Planning session into 3 shorter sessions over a couple of days (walk through
items & questions, break down and estimate items, follow up questions and forecast)
- Maintain a reasonable workday If one team stays up too late.
- Make sure Product Backlog Refinement is done regularly and in a convenient way for
everyone.
It is important that the Product Owner clearly explains the product Vision and Scope and make it
available and visible to all the members of the Team.

Remember to plan the Sprint Review for a
time when the entire Team (including
offshore/nearshore people) can participate
and join in on discussions.
SPRINT REVIEW
Sprint Review serves the Product Owner and Team to inspect and adapt what has been
produced in the current Sprint. As adapting is an on-going and slow process, it can take a few
sprints until rework is reduced.
It is a good idea for locals and remote people to demo the features. Take into account that having
just the local team showing everything can create negative feelings for the offshore members.

SPRINT RETROSPECTIVE
A retrospective helps the Team, Product Owner, and the Scrum Master grow, mature and
improve their processes. It is clear that the more distributed the team, the more issues there will
be. As much as you can, try to identify problems as quickly as possible and test a practical
solution during the Sprint. If the Product Owner is remote, having her in person during some
retrospectives is an option that always brings good results. If that is not possible at all, focus on
having a visual retrospective where people can clearly see the other´s facial expressions and
body language during the different phases.
Extracted from the book Agile Retrospectives – Making Good Teams Great - Esther Derby and Diana Larsen

PRODUCT BACKLOG REFINEMENT
In the same way as a non-distributed refinement activity, teams find particularly important to
dedicate time during the Sprint (typically 5-10% of their availability) to improve the Product
Backlog. The structure is the same as the “Full Product Refinement” explained in chapter 6
“Agile Planning” but, as the Team is distributed, the dedicated room explained should be used.

DAILY SCRUM MEETING
If the Team is in a different location than the Product Owner, you should hold the Daily Scrum
meeting live via webcam each day, at a core-working hour (comfortable time for everyone). If
there are no working hours that overlap, you should:
- Organise the meeting at an hour that is inconvenient for one side or the other (if one
side needs to stay 2 more hours, they should be able to come late the day after)
- Allow them to rotate.
- Use Virtual Kanban or Webcam pointing to the board can be used to display progress.
- Have someone write a quick summary and email everyone.
If no overlap is possible, the Daily Scrum meeting should be recorded with a video camera
and emailed to the other Team and played at their next Daily Scrum meeting. This activity should
be repeated in reverse.

SCRUM OF SCRUMS
Scrum of Scrums can be used to synchronise multiple Teams. Each Daily Scrum meeting ends by
designating one member as "ambassador" to participate in a “special” Daily Meeting -called the
Scrum of Scrums- with ambassadors from other teams. Depending on the project context,
ambassadors may be technical contributors or each team's Scrum Master.
The Scrum of Scrums meeting proceeds otherwise as a normal Daily Scrum, informing the
rest of members about progress and detecting impediments. The Scrum of Scrums will track
these items via a backlog of its own, where each item contributes to improving between-team
coordination.
Another technique widely used is having one member visiting another team´s Daily Scrum. In
here, the person acts as an observer only, just taking notes and looking at the progress. This is
particularly useful when you have a team depending on the outcome of another or when the
features produced by a Team might have an impact in another Team.

ARTEFACTS
As we have seen, written artefacts are used as long as they are brief and support live
conversations. Distributed teams generally use electronic Kanban boards, shared Product Backlog
files (i.e. Wiki or a Google docs) with clear conditions of satisfaction attached and pictures in the
form of sketches. Some teams find also useful to have a demo server where the Product
Owner can review functionality on a daily basis. Simplicity must be the objective.
Finally, always remember when you create virtual meetings to include a brief explanation of why it
is needed, the points to be discussed and the outcome expected. You can also include here
something to be read by people before the meeting begins.

THE EXPECTED outcome
After using the advice and tools detailed, you should expect to get:
 A larger pool of people available.
 Teams performing as if they were local and following Agile & Scrum values and
principles.
 A great level of synergies and morale.
 People feeling confident and trusting each other.
 All requirements and decisions flowing instead of being stuck as a result of geographical
distances.

TAKE AWAY
REMEMBER
 IT infrastructure and project management tools need to be fully integrated with overseas offices.
 Focus on improving communication & collaboration as an on-going activity.
 Test-Driven development and Continuous Integration are vital tools.
 Team experienced in Agile methodologies can perform initially better.
DEEPEN YOUR KNOWLEDGE
Agile Distributed Teams – Scaling agile
BENEFITS
 Access to larger pool of great and scarce technical people.
 Cost savings while keeping quality.
 Have different points of view that can make products richer.

Distributed Teams Infrastructure
Checklist 13.1
Version 1.0
DATE: __________
Audience and Context
This checklist will help to person responsible for Agile change to ensure, that infrastructure has the
right set-up for distributed teams.

Task Comments
1. Before the project starts

Webcams were installed on each PC and are
working.

Comfortable and high-quality headsets with
microphones were installed on each PC.

An easy-to-use software or online tool to allow
people establish a multi-user web-conference is
available and users were created.

An always-on videoconference using high-
resolution wide-angle webcam and large screen
between team’s locations were set up.

Additional cameras pointing to the Kanban and
Continuous Build status were set up.

A desktop-sharing software with virtual
whiteboard capabilities was install in each PC.

I made sure that people from the Team would
easily be able to create new users without the
need to call me.
 I installed a decentralised code management.
 I checked with the Team and installed the
required tool to track bugs and requirements.

A dedicated room with videoconferencing
capabilities in order to support the required
meetings was set up following the picture in the
manual.

Task Comments

I organised a face-to-face workshop for
the whole Team on how to use the different
tools and we tried them all.

I created a document and explained the
Team what happened when a new member
joined the Team.

AWB - 13 - Agile Distributed Teams

AWB - 13 - Agile Distributed Teams

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to AWB - 13 - Agile Distributed Teams

Similar to AWB - 13 - Agile Distributed Teams (20)

Recently uploaded

Recently uploaded (20)

AWB - 13 - Agile Distributed Teams