Mastering The Agile Method For Distributed Teams

A Handbook For Achieving Success With Distributed Agile Teams.
About Jack Berlin

About Belatrix Software - About Prizm Share
Team Distributed Distributed Team Sprint Agile USA Argentina Peru
A Handbook For Achieving Success With Distributed Agile Teams.
About Jack Berlin

About Belatrix Software - About Prizm Share
Team Distributed Distributed Team Sprint Agile USA Argentina Peru
<p>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
</p>