Mastering The Agile Method For
Distributed Teams
A Handbook For Achieving Success With Distributed Agile Teams
Created by:
Silvana Gaia, Technical Solutions Consultant
José Gramaglia, Program Manager
www.belatrixsf.com | blog.belatrixsf.com - USA | Argentina | Peru
+1 (617) 608 - 1413 (international line) | Page 1
Contents
Distributed Development Teams Face A Multitude Of
Challenges
Step 1: Build Your Team
Step 2: Getting Started And Distributing Workloads
Recap On Story Points
The Fibonacci Sequence
The Importance Of Poker In Your Sprint Planning
Rules Of Poker Planning
The Simple Secret To Distributed Planning Poker
Step 3: Day-to-Day Management Of Distributed Agile Teams
The Typical Artifacts To Sustain Distributed Agile Projects
Product Backlog
Sprint Backlog
Burndown Chart
Code Reviews
Sprint Reviews
Key Takeaways: In Many Cases Simple Solutions Will Ensure
Distributed Agile Success
Related Research
www.belatrixsf.com | blog.belatrixsf.com - USA | Argentina | Peru
+1 (617) 608 - 1413 (international line) | Page 2
Distributed Development Teams Face A Multitude Of
Challenges
With the right knowledge and the right set of skills, Agile distributed teams
will become an integral part of your development capabilities. However
working with Agile teams distributed around the world is anything but easy.
The key challenges such teams typically face are:
• Communication. Software projects require a significant amount of
communication, and even more when using Agile methodologies. It is
probably the number one challenge that distributed Agile teams face,
and needs to be addressed proactively.
• Leadership. Leaders are key to any successful project, but it becomes
much harder to spread an organization´s culture and values to people in
distributed teams.
• Culture. Cultural differences can play havoc in distributed teams. It is
essential to develop empathy with other cultures and understand
individual sensitivities and motivations. For example, countries within
Latin America sometimes differ significantly with regard to their culture
and typical organizational structure.
In order to overcome these challenges it is necessary to examine several
key factors including the team size, team composition, and the workload
distribution of the team. We will address each of these in turn.
Step 1: Build Your Team
There are two main factors to take into consideration when building your
team:
• Team size. The team size will depend on the specific project scope,
however typically it ranges from 5 to 12 members. These members will
typically include one Scrum Master, development engineers, quality
Mastering the Agile Method for
Distributed Teams
Whitepaper |
Mastering the Agile Method for
Distributed Teams
Whitepaper |
| Page 3
assurance (QA) engineers, and UX designer(s). A good rule of thumb
is to add 1 QA for every two developers which is the sweet-spot for
productivity.
• Personality traits. Some engineers aren’t a natural fit for distributed Agile.
Specialized human resource teams can help with creating a framework
for psychological insights on which to base your recruitment of engineers.
This helps ensure they are well-suited to these kind of projects. In turn
this will contribute to a stable team, helping to lower attrition.
Characteristics To Look For A Good Fit For Distributed Agile
Step 2: Getting Started And Distributing Workloads
Maintaining even workloads across the team is a critical component, but can
quickly become complex. A quick overview of an Agile team in action:
1. Start working with “Sprint 0”. During Sprint 0 the project is deconstructed
into story points, sizing pieces of work according to the complexity.
2. The team self organizes, assigning tasks depending on seniority and
velocity, and planning to achieve viable software delivery at the end of
the Sprint.
3. Using the Agile iterative approach, at the end of each Sprint validate
the team member’s delivery time rates to calibrate the plan for the next
Sprint.
4. At the end of the Sprint, all of the story points are measured and velocity
calculated. The goal is to balance the workload for the team so all Sprint
goals can be achieved.
www.belatrixsf.com | blog.belatrixsf.com - USA | Argentina | Peru
+1 (617) 608 - 1413 (international line)
| Page 4
Whitepaper |
Recap On Story Points
User stories allow us to estimate the complexity of various story points- with
the goal being to get an overview of the complexity of the project, but also to
track the team velocity in a consistent way. As a result it is possible to gain an
approximate measure of the complexity or size of the project. By calculating
the team velocity and project size, it is possible to know how much time,
effort or resources should be assigned to a particular project.
The result is a high level estimation- it is assumed to be erroneous. But it is
better to be almost right, than completely wrong. It is simply an approach
that will allow us to decide whether the project makes sense, considering the
benefits it would provide to the organization and the investment it would
require.
The Fibonacci Sequence Helps With Sizing
Although it is hard, there are some widely used tools and methods which
help with sizing user stories. One of the most common methods is using
the Fibonacci Sequence as
a series of possible values.
The idea behind using this
sequence is to provide easy
differentiation between a
small user story and one
than could be double or
triple in size or complexity.
But at the same time it is
possible to jump quickly to
higher numbers, avoiding
www.belatrixsf.com | blog.belatrixsf.com - USA | Argentina | Peru
+1 (617) 608 - 1413 (international line)
Mastering the Agile Method for
Distributed Teams
| Page 5
Whitepaper |
useless discussion about whether a “big user story” is a little bigger or a little
smaller.
Ultimately it is about trying to estimate volumes. For example you can
probably do a good job estimating how many caps of water you need to fill
a small bucket, but it´s tough to estimate how many caps of water you need
to fill the building you are sitting in.
The Importance Of Poker In Your Sprint Planning
Creating accurate estimations of the size of the user story is a frequent
challenge. The problem is that many individuals will simply repeat what
more senior team members have stated. In Agile there isn’t time to give
everyone the space to outline their thoughts in detail for every user story.
Poker Planning is therefore a tool which forces everyone on the team to
make their best effort on providing an accurate sizing.
Rules Of Poker Planning
The rules of Poker Planning are simple:
1. A common understanding of what the values of the Fibonacci
sequence mean. What does a value of 1, 2, 3, 5, 8, 13 etc mean? This is
the basic step before starting the use of story points.
2. The team takes one user story, and reviews its requirements. Then the
team will take some time to think individually about the implications this
user story has.
3. All the team members simultaneously show the number or size that
they have selected.
The benefit of Poker Planning is that everyone in the team has the same
opportunities to express themselves, but also the same responsibility of
providing an accurate estimation. If there is agreement, then that number
can simply be assigned to the user story. But if there is a big difference in
the selected sizes, then identify who has selected the smaller and the larger
numbers and give them the opportunity of stating to others why they think
it is that simple or complex. In many cases this will provide fresh information
which enables everyone to review their estimations.
The rule is to move quickly when there is agreement, but take some time
for discussion when there is disagreement. A second round of voting for the
same user story can be completed to ensure all the team members are on
the same page. After that move onto the next user story.
The Simple Secret To Distributed Planning Poker
The simple secret to Planning Poker in distributed teams is to continue to
ensure that votes are not influenced by other teammates. Therefore a platform
is required. The good news is that there are many electronic platforms that
www.belatrixsf.com | blog.belatrixsf.com - USA | Argentina | Peru
+1 (617) 608 - 1413 (international line)
Mastering the Agile Method for
Distributed Teams
| Page 6
Whitepaper |
can facilitate this process. Planningpoker.com is one of the most popular free
tools available.
Step 3: Day-to-Day Management Of Distributed Agile Teams
The on-going day-to-day management of distributed Agile teams can be
challenging, particularly with regard to the communication between team
members. Best practices for successful management include:
1. A similar timezone helps tremendously. For distributed Agile, ideally
make sure your offices are located in a time zone that maximizes team
collaboration and efficiency for optimal delivery.
2. Ensure everyone has immediate access to communication tools.
Building on the time zone advantage, actively use communication tools
for audio and instant messaging. There are numerous VOIP solutions
available, minimizing the need for significant investments.
3. Video conferencing and screen sharing will help efficiency. Make sure to
have frequent face-to-face interactions by tapping into videoconferencing
tools like Skype, Webex, Google Hangouts, Team Viewer, and Join.me.
Also, screen sharing is a great way to help connect people, so make sure
team members can simply and easily share their screens with each other
at the touch of a button.
4. Email is rarely the best option. Try to avoid relying on email as a
communication tool as this typically slows down communication.
The Typical Artifacts To Sustain Distributed Agile Projects
To manage the artifacts needed to enable working in a Scrum project, such
as the product backlog and the sprint backlog, use a collaboration portal to
support storing Scrum artifacts. This is particularly important for distributed
teams where 100% transparency is required. To achieve this, together with
real-time feedback and visibility throughout the development process,
use Agile project management tools like JIRA with Green Hopper, Rally,
VersionOne, Mingle or PivotalTracker.
www.belatrixsf.com | blog.belatrixsf.com - USA | Argentina | Peru
+1 (617) 608 - 1413 (international line)
Mastering the Agile Method for
Distributed Teams
| Page 7
Whitepaper |
In many cases for distributed Agile teams, the typical artifacts remain the
same as for collocated teams. However in some cases these will differ, or
specific artifacts gain additional importance, such as the burndown chart.
The following section provides an outline of the typical artifacts.
Product Backlog
The product backlog is an ordered list of requirements that is maintained for
a product. The items are ordered based on considerations like risk, business
value for the company, dependencies, and milestones. The product backlog
is what will be delivered, ordered into the sequence in which it should be
delivered. It is open and editable by anyone, but the Product Owner is
ultimately responsible for ordering the items on the backlog for the team
to choose. For distributed teams it is essential to use a virtual task board so
that all members have clear visibility into the current status and progress of
the team.
Items are estimated in hours or story points. These estimates help the Product
Owner estimate the timeline and may influence the ordering of backlog
items. The size (i.e. estimated complexity or effort) of each backlog item is,
however, determined by the team, which contributes by sizing items, either
in story points or in estimated hours.
Sprint Backlog
The sprint backlog is a subset of the product backlog, and is the list of work
the team must address during the next sprint. The list is derived by selecting
product backlog items from the top of the product backlog until the team
feels it has enough work to fill the sprint. This is done by the team asking “Can
we also do this?” and adding product backlog items to the sprint backlog.
The team should keep in mind its past performance assessing its capacity
for the new sprint, and use this as a guideline of how much “effort” they can
complete.
The product backlog items are broken down into tasks by the team. Tasks
on the sprint backlog are never assigned; rather, tasks are signed up for by
the team members as needed according to the set priority and the team
member skills. This promotes self-organization of the development team.
The sprint backlog is the property of the team, and all included estimates are
provided by the team. Often an accompanying task board is used to see and
change the state of the tasks of the current sprint, like “to do”, “in progress”
and “done”. Similar to the product backlog, for distributed teams, a virtual
product backlog is required so that all team members have visibility.
Once a sprint backlog is committed, no additional functionality can be added
to the sprint backlog except by the team. Once a sprint has been delivered,
the product backlog is analyzed and reprioritized if necessary, and the next
set of functionality is selected for the next sprint.
www.belatrixsf.com | blog.belatrixsf.com - USA | Argentina | Peru
+1 (617) 608 - 1413 (international line)
Mastering the Agile Method for
Distributed Teams
| Page 8
Whitepaper |
Burndown Chart
Another important artifact is the burndown chart, which is especially
important in Agile distributed teams because of the visibility it offers on how
the sprint workload is being achieved in one, or through several teams. The
sprint burndown chart is a publicly displayed chart showing remaining work
in the sprint backlog. Updated every day, it gives a simple view of the sprint
progress. It also provides quick visualizations for reference.
The basics of a burndown chart are:
1. On planning day, all the estimates are added in hours, which gives us
a total value. This is marked on the y axis. The Sprint end date is marked
on the x axis. A red line is drawn, joining these two points. This red line
indicates the ideal of hours of work achieved per day, to ensure all sprint
stories will be completed. At the end of each day, the developers log their
hours. This is the blue line, always increasing.
2. When the developers log their hours, they must recalculate the
remaining hours. This is the green line. This becomes a habit, and almost
without realizing, developers are doing daily planning, which is an updated
estimation. This updated estimation is reflected in the yellow line, which
results from adding logged hours plus remaining hours. The ideal value
would be a horizontal yellow line. When the yellow line increases, it is
warning us that issues are taking longer than expected, and that provides
us a warning on what might be the outcome of a sprint.
3. Charts can be done by person, by team, or by location. This is a very
quick and realistic way to know how teams are doing with their workload.
Code Reviews
How can we assure the quality of the code delivered through teams across
various locations? The answer is to do code reviews with video and screen
sharing to increase the richness of the experience. Specific tools like Crucible,
Gerrit or Code Collaborator of Smart Bear, will help here. Code comments
are very important for team interaction. JIRA, for example, provides Crucible,
which is a helpful plug-in that tracks comments and relates them to a
particular ticket and also relates them to the specific piece of code being
delivered.
Code reviews are mostly done peer-to-peer, but sometimes can also be
done in groups, which is an excellent way to spread and extend the expertise
concentrated in one site or in one person to the rest of the group.
Sprint Reviews
A fundamental moment of a sprint is the sprint review, called the “Demo”
because it is the moment when the team demonstrates what has been
accomplished during sprint. This stage is particularly important for showing
key stakeholders and sponsors of the project what has been achieved.
www.belatrixsf.com | blog.belatrixsf.com - USA | Argentina | Peru
+1 (617) 608 - 1413 (international line)
Mastering the Agile Method for
Distributed Teams
| Page 9
Whitepaper |
Typically a desktop sharing tool will be used here (such as GoToMeeting or
Join.me). Again, a desktop sharing tool helps bring together people who are
not physically sitting together.
Key Takeaways: In Many Cases Simple Solutions Will
Ensure Distributed Agile Success
This report has outlined some of the challenges with distributed Agile
teams, but also highlighted some key ways in which these challenges can
be overcome. In many cases, there are simple solutions which can have
a dramatic impact. For example, if you are having difficulty with quality
assurance, simply get the local QA team to talk through the test cases with
the distributed team members to help them understand the specific issues.
The Scrum Master will play a vital role in ensuring the distributed team works
well together - for example, setting the conditions for easy communication,
and visibly sharing the progress of the team.
Many of the best practices for working with Scrum, such as Poker Planning,
will work well in distributed teams, but you may need to modify them to your
specific environment (such as by using an online tool) to ensure the best
practice remains effective.
Related Research
www.belatrixsf.com | blog.belatrixsf.com - USA | Argentina | Peru
+1 (617) 608 - 1413 (international line)
Mastering the Agile Method for
Distributed Teams
FIVE Best Practices
To Build Your
Nearshore
Innovation Team
Effectively creating
your software
development team will
make the difference
between success and
failure.
Use BDD to make
your Software
Development
Project More
Succesful
In this Whitepaper
you’ll learn how you
can take advantage of
its many benefits.
Scrum Master:
Adding value to
Agile Software
Products
Roundtable about
best practices for
Scrum Masters to dri-
ve value and how they
work effectively with
CTOs and CIOs.
WHITEPAPER
WHITEPAPER
WEBINAR