Agile 2008 Conference
Practical Considerations for Distributed Agile Projects
Jane M. Robarts
ThoughtWorks Canada
janerobarts@gmail.com
Abstract
As a member of project teams both onshore and
offshore, I have learned many lessons about the
challenges specific to distributed agile projects. If I
could relive my last four years as a project manager at
ThoughtWorks, there would be so many simple, small
things that I would do differently. This report
discusses those lessons as items that must be
considered as part of the planning and execution of
such projects.
1. Introduction
If I could relive my last four years as a project
manager there would be so many simple, small things
that I would do differently. During this time, I spent
a large amount of time on distributed agile projects.
My experience has shown me that there are a lot of
additional things to consider on such projects; knowing
these up front can have a significant impact on the
project’s success.
This report focuses on three ThoughtWorks projects
from this period. Specific matters should be
considered when weighing the value of distributing a
project. Extra thought needs to go into planning a
distributed agile project. And different methods may be
used when improving a distributed project. These are
all discussed within the context of my personal and my
teammates’ experiences.
2. Project Backgrounds
The first project, Project Mammoth was an 80-
person engagement distributed between the US and
India. Both locations had developers, business
analysts, and quality analysts working on the
assignment. Subject matter experts and product
owners were located in the US. This project was long-
running, composed of multiple releases over several
years. Team members included both ThoughtWorks
978-0-7695-3321-6/08 $25.00 © 2008 IEEE
DOI 10.1109/Agile.2008.57
and client employees. I was the offshore project
manager and, at the time, was a resident of India.
The second project, Project Dragon, was one of
ThoughtWorks’ early ventures in China. It was
distributed between a client site in Hong Kong and the
ThoughtWorks office in mainland China. I was a
member of the team early in the project, providing
expertise to get the project up and running. The project
involved approximately 20 individuals from
ThoughtWorks. I spent the early days of this project in
China, before going on to Hong Kong and the client’s
offices.
Project Cub, the third project was for a US client. It
was the team’s first attempt at agile delivery and
involved an offshore (outsourcing) vendor in India.
This team had both vendor and client employees
working in the US, and vendor employees in India.
There were about 15 team members working on both
maintenance and new features for an in-house system.
For this project, I was located in the US acting as an
advisor and coach to the delivery team.
In all cases, cost was one of the deciding factors for
distributing the projects. An outsourcing organization
was used for Project Cub since the client did not have
its own offshore component.
As a Canadian on all these projects, I was a
foreigner regardless of which region I was working in.
I was, however, one of many foreigners on each
project. All teams were multi-national, having
members from at least four different countries, with a
broad mix represented in each region.
3. Communication Factors
Agile projects expect a high level of interaction
between the customer and the development team.
Face-to-face communication is valued as the best way
to communicate between all delivery team members.
Distributed agile projects obviously face challenges in
this regard. Although not a replacement, we have used
several different techniques to compensate for the lack
of face to face discussions.
327
3.1. Visits and Rotations
When permanent face-to-face communication is not
available, we have found that the best alternative is to
plan for rotations through each site on a regular basis.
For Project Dragon, we were fortunate to be able to get
the entire delivery team together in China for the first
week to kick off the project. China was chosen to host
this kickoff since the majority of the team was located
there. Fewer people were required to travel, cutting
down on visa applications and travel costs. This face-
to-face kickoff gave us an opportunity to meet each
other, establish a rapport, and understand the project
together. By the time the team separated to their
different locations, they all knew each other, were
comfortable phoning each other, and felt like part of
the same team.
The client team was unable to attend the kickoff in
China. They went to visit our China office several
weeks into the project. Prior to the visit, there had
been certain individuals that the client had used as his
go-to people. Immediately after meeting the team face-
to-face, the client became much more trusting, much
more engaged and much more willing to work with the
entire team.
On Project Mammoth, we did not have the
opportunity to bring everyone together because it
would have been much too costly. Instead, we set up
and budgeted for a schedule of exchanges from India to
the US and vice versa. At the start of the release, we
sent a team lead and some of our senior
developer/architects over to the US to plan the release
with the product owners and client. These team
members were well trusted by the Indian team – so
although not everyone on the Indian team had an
opportunity to participate in person, they all felt that
they were well represented, that their concerns were
heard, and that they could contribute via their
representatives. The whole team (US and India) found
that the release was much more successful due to the
investment made in travel at that point.
Throughout the release, we scheduled visits for our
US product managers and team leads to the Indian
office. The idea of this was to provide easy transfer of
domain knowledge to business analysts, developers,
and quality analysts in India. An amazing by-product
was that visitors to the Indian office invariably came
away with a better understanding of the environment.
After visiting the office, they often started scheduling
calls at different times, found ways to limit the number
of calls and, most significantly, changed their tone of
communication. Their awareness of the commitment
and dedication of the Indian team increased, and they
understood the personal sacrifices everyone was
making for the project. A reciprocal understanding also
328
developed from the Indian team members towards the
US team, having now met some of them in person.
As a final method of ensuring the team was
transferring knowledge and behaving as one large
team, we arranged for members of the delivery team to
rotate between the US and India for several months.
Some members of the Indian team worked in the US,
while US team members worked in India. Not only
were these team members able to share their
knowledge of the application and development
practices, but they also provided cultural context to the
other team and were able to provide remote
introductions to teammates.
When planning for project visits and rotations, I
found it was not only important to budget and time
these carefully, but it was also important to understand
the different visa requirements for citizens of different
countries. We found that visas for Indians to the US
took extra time and planning. One of our greatest
surprises came from Project Dragon, this being one of
our earlier projects in China. It turns out there is a limit
on how many Hong Kong visas a Chinese company
can apply for annually. Realizing this earlier in the
project would have given us an opportunity to plan our
visits and rotations more strategically.
3.2. Sharing Progress
One of the most frequently-asked questions on a
distributed Agile project is, “What has the other part of
the team been working on?” On a co-located project,
information is normally communicated during a daily
standup and, at a higher level, the iteration planning
meetings and showcases. With a distributed agile team,
I have experienced a few different ways to successfully
communicate progress and activities.
On Project Dragon, where everyone was working in
the same time zone, we were fortunate to be able to
hold a conference call standup. The teams in the
different locations found it a better use to hold their
own stand up meeting, with the joint one held every
second day. This provided them with enough
information from the other part of the team to continue
working without spending unnecessary time on phone
calls.
As a general rule, if the team is too large to hold a
conference call standup, then some sort of daily
handoff is necessary. When the conference call
becomes too long, team members stop attending or
participants lose focus during the call. In India on
Project Mammoth, with over 60 people on the project
site at any time, a standup was impossible. The
leadership team did find it necessary to hold a daily
handoff phone call at the end of the Indian workday.
To allow Indian team leads to have some personal time
in the evenings, the team rotated participation in these
calls, each covering off for another. Late in the
afternoon, the team lead who would not be attending
would prepare his or her updates, questions, etc and
then share that information with a team lead who
would be speaking on his behalf. This had the added
benefit of providing coverage when team leads were on
vacation or out of the office as much of their
knowledge and responsibilities had already been
shared with others.
3.3. Getting the Message Across – Writing
More
One of the biggest challenges I have experienced
with communication on distributed projects is ensuring
that important messages are properly communicated to
the team members in the other location.
As a member of the offshore team in India, I often
had to send reports and updates to our stakeholders
onshore. Because I was often unavailable when these
reports were read by stakeholders, it was important that
messages were conveyed clearly with little room for
interpretation. When creating these reports, I would
try to take on the persona of the most difficult
stakeholder; after adding an item to the report, I would
ask myself, “What is the first question he is going to
ask?” and ensure that the answer to that question was
highlighted in the report as well. Early on, a lot of this
was guessing, but over time as I began to understand
his motivations (budget and customer satisfaction) it
became easier for me to assume that persona and read
the reports through his eyes.
Most distributed projects schedule conference calls
to pass on important messages to the distributed team –
such as a change in budget, organizational changes, or
items that may impact the project. One of the most
valuable techniques I learned came from a US
colleague on my project. He always ensured that when
delivering a message verbally he also included a
written version of the message, usually as a
PowerPoint. Often, we would not even use the
PowerPoint during the conference call, but it was an
artifact that could later be read to clarify the message
with team members who could not hear the call clearly,
were not present at the time, or required clarification
on the exact messaging. Creating a written form of the
message prior to a conference call also had the benefit
of providing the messenger with an opportunity to
collect and organize his thoughts. We took this
technique a step further and made sure that all project
artifacts, wikis, and tracking tools were up-to-date
prior to a status call. This reduced the number of
questions asked during calls and allowed us to focus
329
the discussion on specific issues during our limited
phone time.
3.4. Communicating Requirements – Writing
Less
In contrast to ensuring that messaging, progress
updates, and issues are well documented and written
out, it has been my experience that relying too heavily
on written requirements as a means of communicating
business needs can lead to extra work or confusion. A
user story is supposed to be a starting point for a
conversation, a nuance that can get lost on distributed
agile projects.
When working in the US on Project Cub, the US
analysts went through considerable effort to construct a
user story template, write detailed narratives, and
document all acceptance criteria. The painstaking
effort was extremely thorough and time-consuming for
the first two iterations. Still, with each user story sent
to the offshore team there was a series of questions
asked that took several days to completely answer.
(With the time difference, there was often a 24-hour
turnaround.) The onshore team later realized that the
team in India was struggling to understand the US
business.
The team explored other techniques to provide the
context required for the user stories. Through a video
conference, one of the onshore analysts took the
offshore team through the higher vision of the
application to give them some context of what they
were working on. Until that time, the team had only
seen requirements story by story and could not
understand the direction being taken. On other projects,
I have seen different techniques used to describe
requirements. One team had a local installation of the
application being replaced, and another team had video
recorded several domain sessions delivered by subject
matter experts. These were available when on-
boarding new team members or when tackling a new
part of the domain. I have also seen wireframes and
lo-fi prototypes used effectively to communicate
requirements.
4. Anticipating the Overhead
There are many reasons to distribute an Agile
project. As with my three examples, staffing and cost
commonly drive the decision – staffing may not be
available in one location, offshore resources are often
less expensive than onshore ones. When weighing the
cost benefits of a distributed agile project, one must
also consider the significant overhead that does not
exist on co-located projects and which is often
overlooked when planning distributed work.
4.1. Hardware and Infrastructure Overhead
On my first project between India and the US,
Project Mammoth, there was a 12-hour time difference
between the two. Everyone had to adjust their
schedules. We had initially assumed that the Indian
team could use desktop computers at the
ThoughtWorks. It quickly became apparent that the
Indian team – in particular the business analysts and
team leads – needed laptops so they could work from
home, Emails needed to be answered in evenings and
conference calls were scheduled at odd hours to help us
maintain the level of communication required for agile
projects.
Although not within the project’s budget, we
arranged to supply laptops for all who needed them.
While a desktop computer was completely adequate for
a co-located project where everyone worked from the
office (and was in fact more powerful than the laptops
available), it was insufficient for a distributed project.
Additional hardware (such as laptops and cell phones)
is necessary to provide people the flexibility they need
to do their work on international schedules. The costs
for this should be accounted for in initial planning.
Providing the team with laptops illustrated two
additional points that need to be considered when
planning distributed agile projects. Living in North
America, I am used to very rapid procurement cycles.
I can usually order hardware and receive it within a
matter of days. I can also simply go to an electronics
shop, pick up what I need, and begin using it
immediately.
Different countries have different procurement
cycles and even different legislative requirements for
office hardware. The laptops we ordered in India took
several weeks longer to deliver than I was expecting,
and when they arrived they were locked in a room until
they had been legally bonded to the company. It was
incredibly frustrating for the entire team to be able to
see stacks of brand new computers sitting unused in a
room for a few weeks. Understanding these
requirements and the time it will take to procure
specific hardware has become something I look at on
all projects and build into my plan early in the project.
The second lesson I learned when ThoughtWorks
provided the team with laptops was that I had
overestimated infrastructure available to team
members. While team members now had laptops so
they could work in the evenings to discuss issues with
the client in the US, some were actually having to go to
internet cafes or places with wireless access to do this
because their homes did not have internet. Again a
330
budgetary lesson – consider the costs of providing
team members with the tools they will need to work
from remote locations, such as internet installation at
home, headsets, and VOIP credits to call landlines.
4.2. Planning Work, Schedules and
Contingency
I have learned to plan for more disruptions to
schedules on distributed agile projects, usually through
additional contingency. Expect a project may take
longer than estimated, and expect shifts in velocity
from time to time.
All countries have different public holidays. The
impact of these can be significant on a distributed agile
project if not accounted for. I experienced this at the
outset on Project Dragon when Hong Kong had a
public holiday. It was early in the project – a time
when the team in China had a lot of questions for the
client in Hong Kong, was still trying to understand the
domain, and expected a lot of feedback in a very short
timeframe. All of a sudden, the client was unavailable
while the team was still expected to be productive in
our China office. While this was only a brief
interruption, at such a critical point in the project its
disruption was greatly magnified.
Beyond public holidays, understanding and
anticipating vacation schedules is also key to planning
for the overhead on a distributed agile project. In
North America, many people plan vacations for the
summer months. As a project manager, I know to
expect and plan for this. While working on Project
Mammoth in India, I found that many team members
scheduled their vacations between April and June, a
time when many weddings are held but not a time
during which Westerners would anticipate many
absences. Our well-oiled distributed agile machine
broke down when this happened.
We had built a team that had an excellent balance of
skills and knowledge spread over two regions, and as
long as everyone was at work, it worked at a steady
pace. Suddenly, there were uncommunicated and
substantial changes in people’s availability in India that
upset the normal ratio of roles across the project.
Different bottlenecks would appear when different
team populations were away. While analysts in the US
were still writing stories and SMEs were acceptance
testing, defects were building up and specific stories
were not being picked up. The Indian teams which had
been resolving the majority of defects were largely out
on vacation. Similarly, developers in India having
specific expertise were temporarily unavailable to pair
with those less familiar, resulting in certain stories
waiting in the queue despite their business or tactical
priority
Building a team calendar that incorporates all public
holidays as well as timings of different customs has
helped me better plan for the extra duration that may
be required for a distributed agile project. It also gives
the team visibility into where they may have to plan a
bit in advance. Examples are ensuring that all
information has been gathered from a subject matter
expert before that office has a public holiday, planning
for changes in velocity due to vacations, scheduling
more technical tasks at certain periods, and
understanding that there will be fluctuations in the
level of work completed by different locations. I have
had to ensure I do not create a team calendar in
isolation – I involve individuals who would know
specifics about culture and customs, such as a member
from human resources or members of other project
teams.
There were events that I could not plan for that also
impacted the team. I have learned that distributed agile
projects often require a bit more contingency in their
budgets. One week, the team in the US was snowed in.
Most people could not make it to work and operations
shut down. Three weeks later in India, there was a
power outage affecting the team there. Both were
unplanned events, and we had not thought through
what one team would do when the other was
unavailable. These were two separate events happening
in two different locations; however each region felt the
impact, doubling the cost.
One of the most costly types of overhead I have
seen on distributed agile projects is the personal
sacrifice and investment team members must make
when different time zones are involved. This is
amplified as the time zones get further and further
apart. Agile requires a much higher level of
communication than traditional software projects.
While working on both projects between India and the
US, I found myself and other team members attending
calls late at night and early in the morning to sync up
with people in the other region. In India, I would often
be at work by 8am to speak to the team in the US
before they left for the day, and then speaking to them
again at 8pm before going home at night.
The team in India also adjusted their work
schedules to allow for more overlap with their
counterparts and clients in the US, starting their day at
10am and staying later to be available when the US
team started work. While on a distributed project in the
US, it was not uncommon for me to be on a conference
call for an iteration planning meeting at 9pm. The
personal cost is high due to different working hours.
Distributed agile projects can affect the amount if time
team members can spend with their families, their
331
commitment to extra-curricular activities, etc. When
living in India, I remember the day the US changed
their clocks ahead for daylight saving time – our team
all celebrated because we were able to go home an
hour earlier each day.
Before embarking on any distributed agile project, I
now ensure that all team members understand the
different work schedule they may need to assume, the
level of communication that will be required with the
other team, and the availability they may be expected
to have.
5. Building a Common Understanding
(‘Sure, We Do Agile’)
When I worked with Project Cub, there was one
thing we forgot to consider: the time it would take to
agree on agile terms and practices. When working on a
co-located team, this agreement evolves over time and
comes naturally through discussion.
We had assumed that the team in India was
practicing agile the same way we were planning on
doing it in the US. It was several days into the first
iteration before we realized that each location had a
different version of ‘agile’. As a member of the US
team, I had little visibility into the day-to-day
operations of the team in India. To build a common
understanding of the practices we were using, we
started by having each team prepare a presentation on
‘a day in the life’ of their team. This became a starting
point for discussions about what the teams were doing
differently and how we wanted to change things. For
example, the US team was trying to practice test-driven
development, whereas the India team was having a
team member write the unit tests.
Once we had acknowledged that there were
differences in terminology and implementation of
practices, the team was open to exploring the different
techniques locations were using and selected the
practices they wanted to use. We set up a wiki page to
capture a glossary of terms, books we were
referencing, and how we were using different practices.
When starting a distributed project, I no longer
make the assumption everyone will understand the
same flavor of agile. Though not unique to distributed
projects, the problem of diverging methodology is
exacerbated by distance. It is harder to know what
people are doing so it may take longer to realize
different teams have different understandings of the
same terms. Any project involving new team members
requires scheduled time to ensure all participants agree
on and understand the agile practices that will be used
on that project. I get the team to share different
templates and artifacts with each other from prior
projects, we then select as a group the ones we will use
for our project.

6. Conclusions
There is a lot more to consider when embarking on
a distributed agile project than simple cost savings.
Careful consideration must be taken to ensure activities
like travel, contingency, and personal commitment are
thought through and planned for. Agile’s fundamental
principles of face-to-face communication and close
collaboration are hampered on a distributed project.
These deficits must be consciously addressed through
activities such as more formalized communication,
practices discussions, and different means of
expressing requirements.

7. Acknowledgements
I would like to thank all my ThoughtWorks
teammates everywhere who have shared their lessons,
gone through some tough times with me, and had fun
along the way. Thanks all offshore individuals for
your hospitality and openness when I visited. Specific
thanks to Mark Rickmeier for bottomless energy and
great ideas, Andy Yates for shared experiences, and
Angela Martin for encouragement, and Martin
Andersen for being my constant sounding board.

332