Distributed AgileDevelopment and the Death of Distance
by Matthew Simons
For many companies, the rapid growth in outsourcing, especially offshore
outsourcing of development work, opens the door to a host of problems
that come with having a far-flung development environment. If you
practice — or want to practice — agile software development, this
Executive Report offers ideas on how to narrow the gap between the home
office and your partners around the globe.
Sourcing and VendorRelationships
Vol. 5, No. 4
About Cutter ConsortiumCutter Consortium’s mission is to foster the debate of, and dialogue on, the business-technology issues challenging enterprises today and to help organizations leverage ITfor competitive advantage and business success. Cutter’s philosophy is that most of theissues managers face are complex enough to merit examination that goes beyond simplepronouncements. The Consortium takes a unique view of the business-technologylandscape, looking beyond the one-dimensional “technology” fix approach so commontoday. We know there are no “silver bullets” in IT and that successful implementationand deployment of a technology is as crucial as the selection of that technology.
To accomplish our mission, we have assembled the world’s preeminent IT consultants —a distinguished group of internationally recognized experts committed to delivering top-level, critical, objective advice. Each of the Consortium’s nine practice areas features ateam of Senior Consultants whose credentials are unmatched by any other serviceprovider. This group of experts provides all the consulting, performs all the researchand writing, develops and presents all the workshops, and fields all the inquiries fromCutter clients.
This is what differentiates Cutter from other analyst and consulting firms and why we sayCutter gives you access to the experts. All of Cutter’s products and services are providedby today’s top thinkers in business and IT. Cutter’s clients tap into this brain trust and arethe beneficiaries of the dialogue and debate our experts engage in at the annual CutterSummit, in the pages of Cutter IT Journal, through the collaborative forecasting of theCutter Business Technology Council, and in our many reports and advisories.
Cutter Consortium’s menu of products and services can be customized to fit yourorganization’s budget. Most importantly, Cutter offers objectivity. Unlike so manyinformation providers, the Consortium has no special ties to vendors and can thereforebe completely forthright and critical. That’s why more than 5,300 global organizationsrely on Cutter for the no-holds-barred advice they need to gain and to maintain acompetitive edge — and for the peace of mind that comes with knowing they arerelying on the best minds in the business for their information, insight, and guidance.
For more information, contact Cutter Consortium at +1 781 648 8700 or [email protected].
Cutter Business Technology Council
Access to the
Experts
Rob Austin Tom DeMarco Christine Davis Lynne Ellyn Jim Highsmith Tim Lister Ken Orr Ed Yourdon
by Matthew Simons
Distributed Agile Developmentand the Death of DistanceSOURCING AND VENDOR RELATIONSHIPSADVISORY SERVICEExecutive Report, Vol. 5, No. 4
Software development teams
around the world have been try-
ing to solve the riddle of distrib-
uted development for years. The
problem is so thorny because soft-
ware development is, at its core,
based on communication. Every
aspect of a project is fundamen-
tally changed the moment that
team members lose the ability to
walk down the hall or meet at the
water cooler to communicate face
to face. Many organizations have
tried, but unfortunately the annals
of software development history
are crammed with sad stories of
distributed projects gone wrong.
Yet its allure remains too powerful
to ignore. With the recent rapid
growth in offshore development
service providers, cost savings
is at the top of any list of drivers
for distributed development.
However, cost is not the only dri-
ver for distribution; in fact some
organizations are finding that the
case for cost savings is not as
strong as the hype suggests [3].
Some of the most common rea-
sons for considering distributed
development include:
� Cost savings (utilizing offshore
teams)
� Schedule compression (bringing
more resources to bear)
� Scale (breaking a large effort into
manageable components)
� Access to technical talent
(specialized technical skills
may not be available locally)
� Proximity to business sponsors
(customers are not always
located near developers)
� Workspace unavailable (when
space is at a premium, large
development teams must
work elsewhere in order to
be together)
� Use of vendors with off-site
development facilities (reduction
in travel costs by allowing vendor
employees to work near their
homes)
� Quality of life (not requiring proj-
ect team members to travel or
relocate means happier teams
that can include seasoned and
mature individuals whose family
commitments do not permit
them to be road warriors)
� 24/7 availability of development
(for support or “follow the sun”
development)
Fortunately, there is a promising
new option for those of you who
are faced with making distributed
development work for your orga-
nizations. Recent developments in
technology have spawned a way
of working, known as agile soft-
ware development, that have
proven very effective at delivering
software. What would happen if
we applied this way of working
to distributed development teams?
The answer to that question
might just mean a major step
forward in our quest to make
reliable distributed development
a reality. This Executive Report
helps provide that answer.
AN AGILE DEVELOPMENTPRIMER1
Agile software development is
an umbrella term that is used to
describe a family of approaches
for software project management
and execution that has evolved
during the past five to 10 years.
The best known of these include
Extreme Programming, Feature-
Driven Development, and
Adaptive Software Development,
but there are a number of others.
The priorities shared by all agile
processes have been described by
the nonprofit AgileAlliance organi-
zation (www.agilealliance.com)
in the following ways:
� Individuals and interactions
over processes and tools
� Working software over compre-
hensive documentation
� Customer collaboration over
contract negotiation
� Responding to change over
following a plan
The priorities in the second half
of each statement are typical of
approaches for software devel-
opment that were formulated in
the era of structured program-
ming. They were driven by the
infamous “cost of change” curve
that showed the rapidly escalating
cost of changing your mind or
finding a problem as the project
progressed (see Figure 1).
However, with the advent and
evolution of object-oriented (OO)
programming languages and
enabling technologies such as
automated testing tools and
frameworks, development teams
have become increasingly able
to cope with change during the
construction of systems. In other
words, the cost of change curve
has become less steep (see
Figure 2).
VOL. 5, NO. 4 www.cutter.com
22 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE
The Sourcing and Vendor Relationships Advisory Service Executive Report is published by Cutter Consortium, 37 Broadway, Suite 1, Arlington,MA 02474-5552, USA; Tel: +1 781 641 9876 or, within North America, +1 800 492 1650, Fax: +1 781 648 1950 or, within North America, +1 800 888 1816,E-mail: [email protected], Web site: www.cutter.com. Group Publisher: Kim Leonard, E-mail: [email protected]. Managing Editor: Rick Saia, E-mail: [email protected]. Production Editor: Pamela Shalit, E-mail: [email protected]. ©2004 by Cutter Consortium. All rights reserved. Unauthorizedreproduction in any form, including photocopying, faxing, and image scanning, is against the law. Reprints make an excellent training tool. Forinformation about reprints and/or back issues of Cutter Consortium publications, call +1 781 648 8700, or e-mail [email protected].
1If you are not familiar with “The New
Methodology” (www.martinfowler.com/
articles/newMethodology.html), this section
provides a brief overview.
Co
st
of
ch
an
ge
Requirements Analysis/design Code Test Integrate/live
Project stage
Figure 1 — The cost of change curve.
Agile methods have capitalized
on this trend through working
practices that maximize the devel-
opment team’s ability to evolve a
system based on the latest infor-
mation of what the system is
supposed to do. Agile practices
center around breaking develop-
ment efforts into manageable
pieces (as short as one to two
weeks between deliverables),
demanding constant customer
participation to steer the develop-
ment effort (working with people
instead of with requirements
documents), and enforcing disci-
plined development practices
(simplicity of design and auto-
mated testing).
Business-unit people like agile
development because it demon-
strates regular visible progress
and enables them to evolve the
system in response to rapidly
changing requirements. It also
allows them to realize incremen-
tal ROI as they go, instead of wait-
ing until the project is finished for
big-bang benefits that might never
materialize.
Development teams like agile
development because it mitigates
many of the risks of software
development (such as “integration
hell” at the end of a long project)
and because there is mounting
anecdotal evidence that experi-
enced agile teams build higher-
quality systems more quickly than
do teams using other methods.
Agile development was initially
envisaged for and applied to
small, colocated teams of devel-
opers and customers. That makes
it useful for many organizations
and teams, but ignores a large
and growing class of software
projects that involve some degree
of distribution.
ARE YOU DISTRIBUTED?
Amid the current hubbub sur-
rounding offshore outsourcing, it
is easy to forget that distributed
development has many forms.
The simplest and most often over-
looked form of distributed devel-
opment is what happens on a
project that outgrows its work-
space and is forced to spread out
into multiple locations within the
same office or at multiple offices
in the same campus or region.
Figure 3, adapted from Managing
the Flow of Technology, shows
that communication falls off
rapidly with physical separation
[1]. People located 100 meters or
more apart have only about a 5%
chance of talking to one another
in a typical week. In other words,
the recommendations in this
report are just as applicable to
your multi-story project as they are
to your multi-continent project.
Continuing upward on the scale of
distribution complexity, we come
to projects with concurrent devel-
opment at several business cen-
ters within the same company.
Outsourcing work to external
organizations further inhibits
communication, as illustrated in
Figure 4 (adapted from [1]).
Offshore distributed projects
belong at the top of the com-
plexity scale because they
must overcome not only the
challenges of distance and of
©2004 CUTTER CONSORTIUM VOL. 5, NO. 4
EXECUTIVE REPORT 33
Co
st
of
ch
an
ge
Time
Figure 2 — The new cost of change curve.
multiple organizations but also of
language, cultural, and temporal
inhibitors.
As you move further up the com-
plexity scale, your risk of experi-
encing one or more of the pitfalls
commonly associated with dis-
tributed projects increases (see
Figure 5). Many teams face such
problems as the following:
� Disconnection on project
requirements. The customer
and the development team can
quite easily develop divergent
understandings of the project
requirements. This can happen
either because the requirements
have changed or because they
were not properly understood in
the first place. Needless to say, if
this goes uncorrected, it causes
great dismay when the long-
awaited software finally arrives.
� Disconnection on project
estimation. Customers, man-
agers, and developers estimate
projects differently, each using
their own amount of leeway
based on personal experiences.
In a distributed project, in which
it is likely that these groups will
never meet in person, the stan-
dard deviation of project esti-
mates can vary quite a bit.
� Decreased visibility into proj-
ect status. It is often difficult for
managers and sponsors of a dis-
tributed project to get an accu-
rate sense of project progress
and status. Many have been
unpleasantly surprised at late
stages of a project to find that
their understanding of “percent-
age complete” was less than
accurate.
� Configuration management.
Bringing it all together for imple-
mentation in the production
VOL. 5, NO. 4 www.cutter.com
44 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE
Lik
elih
oo
d o
f w
eekly
co
mm
un
icati
on
100%
10%
1%
.1%
1 10 100 1,000 10,000
Separation distance (meters)
Figure 3 — Communication probability as a function of distance.
Lik
elih
oo
d o
f w
ee
kly
co
mm
un
ica
tio
n
40%
35%
30%
25%
20%
15%
10%
5%
0 10 20 30 40 50 60 70
Separation distance (meters)
With organizational bond
Without organizational bond
Figure 4 — Communication probability as a function of distance: intragroup and intergroup.
environment is one of the most
difficult parts of any software
project. Many distributed teams
have faced serious or (in some
cases) intractable problems
integrating and deploying the
components in the production
environment.
� Erosion of trust. People build
trust through communication.
As teams get further and further
removed from one another
(spanning time zones, lan-
guages, and cultural divides),
it becomes entirely possible
for each site to develop radically
divergent visions of project inten-
tion, progress, practices, and
status. When these divergent
versions of reality come to light,
it can damage personal and pro-
fessional relationships irrevoca-
bly and make working together
a very unpleasant experience for
both sides.
Controlling the Chaos
Most approaches that are
designed to address the chal-
lenges of distributed development
tended to take decreased com-
munication bandwidth as a given
and have evolved structures and
tactics to manage the risk this
introduces into the process. As
a result, distributed teams have
been living in the world of
requirements specs, component
designs, and long periods of inte-
gration testing (which is often
really a euphemism for “the time
when we come on-site to actually
make it work”).
Additionally, the erosion of trust
caused by decreased personal
contact causes us to adopt con-
trolling behaviors and attempt to
manage delivery risk with legal
contracts. Some contracts for dis-
tributed development projects
contain so much detail that they
start to sound like requirement
specs or project plans in their
own right. They also tend to
penalize customers for changing
their mind. Punishing change goes
against the reality of modern busi-
ness, where responding to market
demand (a very good thing) often
means changing your mind.
And yet despite all of our controls
and protections, often it still
doesn’t work as well as we
had hoped. Projects fail entirely,
underdeliver, or run over budget.
Customers are unhappy, and
everyone blames one another. So
in response, we choose the work
we distribute very carefully. We
keep the difficult, strategic initia-
tives close to home and use off-
site resources for maintenance
work or well-defined projects.
But wouldn’t it be great if you
didn’t have to consider the com-
plexity or strategic importance
of your project when deciding
which work you can do off-site?
Wouldn’t it be great to realize all
the benefits of distributed devel-
opment on your most important,
complex initiatives?
DISTRIBUTED AGILEDEVELOPMENT FOR THE NEXT GENERATIONOF DISTRIBUTED PROJECTS
The way forward for leading IT
organizations lies at the intersec-
tion of agile development and dis-
tributed teams. The principles and
practices of agile software devel-
opment that make it so effective
at delivering complex systems
with rapidly changing require-
ments work to directly address
many of the prime risk areas of
distributed development [4].
Distributed agile development
is a powerful new approach to
software delivery that will allow
©2004 CUTTER CONSORTIUM VOL. 5, NO. 4
EXECUTIVE REPORT 55
Less Complex More Complex
Colocated
development
Team not
seated together
Team on
different floors/
buildings
Noncolocated team
of >1 organization
Team distributed
across time zones
and cultures
Figure 5 — Complexity scale for distributed projects.
global IT organizations to change
the way they think about what
they do and what they can
achieve.
As illustrated in Figure 6, a distrib-
uted agile development approach
is appropriate for a wide band of
enterprise-level projects in the
upper-right quadrant of the plot
of “technical complexity” against
“strategic need.” Distributed agile
development is not right for every
project, but you should seriously
consider applying some of its best
practices for any project in your
portfolio that includes an element
of distribution.
Since agile development was
originally proposed for colocated
teams of customers and develop-
ers, there is not a direct mapping
between practices on distributed
and nondistributed agile develop-
ment teams. The differences in
project-execution practices are
subtle but critical, and there is a
learning curve for all project
participants and sponsors.
However, once you have over-
come the leaning curve, there is
almost no limit to what your orga-
nization can achieve with distrib-
uted agile development. The rest
of this report focuses on how to
develop an organizational compe-
tency for distributed agile soft-
ware development through the
building of a portfolio of success-
ful distributed agile development
projects. The lessons learned and
best practices described here are
based on personal experiences
since 2000 working with and
observing distributed agile devel-
opment teams that range in size
from five to 150 members.
Before You Get Started ...
Don’t be tempted to pick a project
and jump into distributed agile
development headfirst. There are
some fundamental structures,
qualifications, and building blocks
that you must put in place before
you begin. Many of these items
have relatively long lead times, so
it is wise to get them underway
immediately once you have
decided to try distributed agile
development.
Experience with NondistributedAgile Development
Distributed agile development
clearly derives from standard agile
development. Think of it as an
advanced application of the fun-
damental practices employed by
nondistributed agile teams. There
is a learning curve associated with
adopting standard agile develop-
ment — not only in mastering
the practices but also in achieving
the shift in mindset that happens
across the project team, its man-
agers, and sponsors. Mastering
agile development takes practice
and concerted effort over months,
not weeks. While it may be possi-
ble to “go distributed agile” with-
out first “going agile,” it would
certainly be a more difficult and
risky proposition. If your organiza-
tion has not started using agile
development practices locally,
it would be wise to start a few
teams on the path toward on-site
agile even as you begin to lay the
groundwork for distributed agile
development.
Appropriate Off-Site Staff/Partner
In addition to building your own
organization’s knowledge of agile
practices, it will behoove you to
work with an off-site team that
VOL. 5, NO. 4 www.cutter.com
66 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE
Tech
nic
al C
om
ple
xit
y
Project
Risk
Strategic Need
Agile
Distributed
Agile
Figure 6 — Where distributed agile development can work.
has agile experience. If your dis-
tributed project is within your own
organization, introduce on-site
agile development at all project
locations prior to rolling out
distributed agile development. If
you are outsourcing development,
look for a vendor with a track
record of successful agile delivery
or (ideally) experience in applying
agile practices to distributed proj-
ects. Adding the challenge of
learning agile development to
the challenges of executing
distributed development could
be a recipe for disaster.
Openness to Off-Site Development
As you will see in the sections that
follow on best practices, imple-
menting distributed agile develop-
ment can be a radical shift with
far-reaching cultural implications
for many organizations. You will
see, for example, that one of the
fundamental requirements is fre-
quent rotation of staff between the
off-site and on-site locations. Many
organizations are not set up to
support staff members of all
levels traveling or working off-site.
Additionally, organizations may
be sensitive to sending business-
critical data off-site. They may
also not be comfortable providing
access to confidential information
in a location that may not be
subject to the same security
practices as those used at the
home office. Since implementing
distributed agile development will
likely involve partnering with an
external vendor, organizations that
traditionally have not employed
consultants may need to come to
terms with new types of relation-
ships. It is possible that some
employees may view performing
work elsewhere as a threat to
their own positions — especially
if that work has been shifted to
a low-cost development center.
All these considerations must be
managed.
Since every situation is different,
there are no general rules for
promoting distributed agile
development among your staff
members. If anything, this should
be the guiding principle: do not
underestimate the culture shock
that distributed agile development
can create for your organization.
Plan your communication and
rollout carefully so that the on-site
team members will work to sup-
port distributed agile development
and make it succeed. Seek out
and develop advocates at every
level of the organization and
make sure they are involved in
the planning and in the first trial
projects. Once you have built
up a few successes and people
become comfortable with the fact
that they will have “new roles”
rather than “no roles” in the world
of distributed agile development,
momentum and support should
start to swing your way.
Technical and Physical Infrastructure
As previously discussed, most
challenges of distributed devel-
opment can be traced back to
decreased communication
bandwidth. Succeeding with
distributed agile development
requires investment in enabling
technologies and infrastructure.
The items listed below may seem
somewhat incidental. However, if
you are unwilling or unable to
provide your team with an envi-
ronment that is set up to facilitate
communication, you should
seriously question your desire to
adopt distributed agile develop-
ment. Because some of these
items may have long lead times,
it is wise to get them underway
as soon as possible.
� High-availability, high-
bandwidth network connec-
tivity (often virtual private
networks). The network admin-
istrators at each development
site must work out how to
provide fast and reliable two-
way access between all the
machines and resources the
teams will need to share. This
can be complicated when third-
party systems are involved.
Setting this up at a sufficient
level usually takes approximately
three times as long as you would
expect.
� Unlimited telephone connec-
tivity. Any project team member
should be able to pick up the
phone and directly dial any other
team member and talk for any
length of time. This is often an
issue in offshore development
when phones are not enabled
for international dialing.
� High-quality speakerphones.
Often, groups of people will
need to collaborate via phone.
©2004 CUTTER CONSORTIUM VOL. 5, NO. 4
EXECUTIVE REPORT 77
An investment in high-quality
(full duplex) speakerphones
will do wonders to facilitate
this communication. An alter-
native is to set up a conference-
call facility and give all project
team members the ability to
schedule calls.
� Instant messaging (IM).
Experience has shown that
distributed teams often come
to rely on the immediacy and
“availability indicator” features
of IM utilities. Some corporate
IT departments have policies
against the use of these tools.
Alternatives to the big public
messaging clients (such as
locally hosted messaging
servers) exist but take time
to procure and install.
� Project space. Allocating a room
in both locations for the ad hoc
use of the distributed team can
do wonders to facilitate commu-
nication and establish a team
spirit. This room is a place to
post project status, artifacts, and
pictures of the teams. It is also
a place where the conference
phone is always plugged in and
ready to host calls whenever
they become necessary.
Pipeline
Once a distributed agile devel-
opment team gets rolling, it can
develop systems very quickly.
The team can only achieve peak
levels of productivity if the cus-
tomer is able to supply an ade-
quate pipeline of work for the
off-site team. The on-site team,
especially the client’s domain
experts, must be able to stay
ahead of the off-site developers.
Additionally, QA testers need to
be able to provide rapid turn-
around so they do not become
a bottleneck in the development
machine. You should consider this
“throughput” factor when sizing
and staffing your on-site and off-
site teams.
Initial Efforts
To achieve the tantalizing bene-
fits of off-site development, it is
important to take a longer-term
view when developing an organi-
zational capability for distributed
agile development. You would
do well to put on your strategic-
thinking hat when choosing the
first few pieces of work that you
do with off-site teams. As the
capability and confidence of your
teams mature, you will be able to
distribute a greater volume and
variety of work, but it is best to
start carefully. Consider each of
the following project attributes in
order to select something that will
deliver an initial win:
� Project size (number of
people). The optimal team
size for your initial efforts at
distributed agile development
is around 10 to 15 in total
(including all roles at both sites).
Smaller projects often don’t face
the challenges that distributed
agile development is designed
to address and aren’t worth the
overhead required to set up the
distributed team. Larger projects
rapidly become more risky and
difficult given sheer size alone
and demand broad experience
with distributed agile develop-
ment throughout the team from
the outset.
� Project duration. Your project
must run long enough to allow
the team to gel and evolve its
working practices. It also needs
to run long enough to generate
the metrics you can use to
promote wider usage of dis-
tributed agile development.
A project scheduled to run for
three months is probably the
minimum you would want to
choose for your initial efforts.
� Project technologies. Agile
development is significantly
enabled by advanced program-
ming languages such as Java or
.NET. While it is possible to apply
agile practices to projects using
other tools or languages, custom
software development with
modern OO languages is the
best choice for distributed agile
development.
� Project complexity. As dis-
cussed above, distributed agile
development is well suited for
highly complex, highly strategic
(and hence highly risky) proj-
ects. It can also provide some
productivity gains for simpler or
more well-defined projects, but
the practices recommended
here may be a bit over the top
for less complex development.
� Project visibility. If you hope
to use your initial efforts to
help you build the case for
greater usage of distributed
VOL. 5, NO. 4 www.cutter.com
88 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE
agile development in your orga-
nization, you should choose a
project that people will notice.
� Project sponsorship. In addi-
tion to successful execution, the
biggest factor in whether your
initial project leads to wider
adoption of distributed agile
development is probably your
business sponsor. Select a spon-
sor who will remain engaged in
the project and who can easily
realize measurable benefits from
the approach. Once you deliver,
your sponsor will become your
champion throughout the wider
organization.
� Existing versus new develop-
ment. You may want to consider
trying out distributed agile for
follow-on deliveries of existing,
nondistributed projects. It can be
easier to start up a new off-site
team on an established code
base and architecture without
the overhead of solving funda-
mental questions on design and
technical approach. While it is
certainly possible to start from
scratch with distributed agile
development, doing so may not
be the most prudent choice for
your initial efforts.
After successfully delivering your
initial project, keep in mind that
the goals of future projects extend
beyond simple execution. Each
experience will allow your team
to build and evolve the technical
infrastructure, relationships, and
working practices that will enable
future success. As your teams
continue to learn, you will be
able to increase the complexity
of work you choose to distribute.
As the depth and breadth of
your project portfolio grow, your
distributed agile development
delivery model will mature and
become second nature, and
the benefits you gain from it will
continue to increase.
BEST PRACTICES FORESTIMATING DISTRIBUTEDAGILE DEVELOPMENTPROJECTS
A key difference between tradi-
tional and agile project execution
is that estimation and planning is
viewed as a process that occurs
throughout the project rather than
as an event that happens once at
the beginning and perhaps again
at specified intervals. Distributing
the development team does noth-
ing to change the practices used
for estimating an agile project, but
there are some mechanics to con-
sider concerning who does it and
where it happens.
In agile development, it is impor-
tant that the people responsible
for doing the work are also
responsible for estimating the
work. Another characteristic of
agile methods is not relying on
detailed documentation to
capture scope. Therefore agile
projects are usually scoped out
through collaborative workshops
between customers and develop-
ers. In these workshops, items to
be developed are documented
in simple ways, such as in “story
cards” or “features” instead of in
detailed requirement specs or
use cases.
A distributed team presents a
challenge because the develop-
ers often are not colocated with
the customers, which makes car-
rying out collaborative scoping
workshops more difficult. Also,
the lightweight documentation
that agile projects rely on often
lacks sufficient detail to be useful
to people who were not present
for the initial conversations.
The solution to the challenge of
distributed agile project estima-
tion lies in the effective use of
staff rotation and a bit of extra
care in preparing documentation.
Project team members from both
sites should be physically present
at the sessions where high-level
scope items are broken down
for developers to estimate.
Representatives from each site
must be actively engaged in
the conversations that explore
the boundaries of each piece of
functionality.
Warning: don’t be tempted to
skimp and use conference calls
in lieu of face-to-face meetings.
Initial estimation happens at the
start of a project during the critical
period when credibility and rela-
tionships are established and
many of the rules of engagement
are laid down. This “human side”
of the estimation and planning
process just doesn’t happen over
the telephone. Additionally, the
massive transfer of domain
knowledge that happens through
©2004 CUTTER CONSORTIUM VOL. 5, NO. 4
EXECUTIVE REPORT 99
intensive rapid-fire questioning
and answering is severely limited
when you try to do it over the
telephone. Successful transfer
of domain knowledge to ambas-
sadors from the off-site team is
one of the critical factors that
will allow your remote team to
successfully execute distributed
agile development.
Once an initial set of project
functionality has been captured,
the ambassadors can return to
the remote site and guide the
development team through initial
project estimation. Anyone pres-
ent for the initial discussions
should be able to clarify points
or answer questions as the devel-
opers go about estimating. If
the ambassadors are unable to
answer a question, they should
forward it to their friends at the
other site for discussion and
clarification.
After the initial set of features
has been estimated by the devel-
opment team, the list should be
widely circulated for review
(with the proviso that this is
only the initial list and is subject
to change). Customers and
project team members should
check the list for missing items
and probe any items that seem
to carry unexpected estimates
(either much bigger or much
smaller than anticipated). Once
everyone has had a chance to
review and comment and the
estimates have been adjusted
as necessary, you will have an
initial idea of the size of the
project. Now you are ready to
begin putting together the rest
of your team and planning your
releases.
EFFECTIVE TEAM STRUCTURESFOR DISTRIBUTED AGILEDEVELOPMENT
One common model from the
outsourcing world is to have an
on-site project manager managing
a team of off-site developers. This
model just doesn’t fly for distrib-
uted agile development. A new
way of working requires new
roles and ways of interacting.
The following are some team
structures and characteristics that
have proven effective across vari-
ous distributed agile development
projects and may prove useful for
you. As you set up your delivery
team, you should set aside time
to discuss and debate which
roles your team will choose to
use. Make sure everyone on the
team understands and agrees
with the roles before you start
development.
On-Site Team Rolesand Responsibilities
Choosing the right people for your
distributed development teams
can mean the difference between
success and failure. Search for
advocates of distributed agile
development. Evaluate soft skills
(such as proactive communica-
tion and tolerance) with equal
or even greater importance than
pure technical ability. Choose
people who are receptive to
adjusting their working practices
and willing to travel or temporarily
relocate if required. If you can
find people who have existing
relationships with the off-site
team members, this will allow
you to start faster because those
existing relationships will shorten
the trust-building phase of project
startup. If you are doing offshore
development, try to find people
who have experience living in or
working with other cultures or,
at a minimum, have traveled
outside their home countries.
These people are likely to be
more open to and interested in
forming relationships across cul-
tural boundaries, which will make
them more effective communi-
cators and team members.
The following roles and responsi-
bilities often prove effective for
the on-site team on a distributed
agile development project. These
roles do not necessarily have a
one-to-one mapping with individ-
uals; one person may, in some
cases, have more than one role.
� Project manager. In addition to
traditional project management
responsibilities regarding project
planning and progress tracking,
the project manager on a distrib-
uted agile development project
has prime responsibility for
encouraging communication
between the on-site and off-site
teams. He or she should help
the team agree on communica-
tion patterns (discussed below)
and constantly encourage on-site
members to communicate with
the remote site until they get
VOL. 5, NO. 4 www.cutter.com
1100 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE
in the habit of talking many
times a day to their invisible
colleagues. The project manager
also has the responsibility for
creating a “one-team” culture
and ensuring that all the other
recommended practices in this
report are applied at the right
time in the right way.
� Truth. “The Truth” (aka the
product owner) is the customer
representative who is empow-
ered to act as the single point of
contact for all project stakehold-
ers. The Truth is responsible for
prioritizing and managing project
scope. The Truth interfaces with
the development team via the
backlog (the set of yet-to-be-
developed features). The Truth is
the final authority on the priority
of items in the backlog (although
he or she will collect feedback
from a variety of business and
technical sources prior to mak-
ing priority decisions).
� Proxy customer. For large teams
or for teams where stakeholders
cannot be dedicated to the proj-
ect full time, it is necessary to
employ proxy customers in the
form of business analysts. Proxy
customers are responsible for
keeping up to date with shifting
business priorities and clearly
articulating requirements to the
off-site development team. Proxy
customers communicate con-
stantly with the off-site team
members, supporting them by
answering questions as they pro-
ceed through each development
iteration. Often, proxy customers
approve delivered functionality
via testing and are responsible
for showcasing the results of iter-
ations to project stakeholders. To
make distributed agile develop-
ment work, proxy customers
should be willing to travel in per-
son to the remote site and (if the
team is located in a different
time zone) to shift their working
hours on occasion to facilitate
real-time interaction with the
off-site team.
� Developer liaison. Project cir-
cumstances dictate whether you
should consider staffing a devel-
oper at the local site. It has
proven particularly useful when
the off-site team is working on
only one part of a large project
that also involves an on-site
development team. In this situa-
tion, the on-site developer can
advocate for the off-site team
and also brief the off-site team
on critical technical communica-
tion or goings-on at the local site.
Even if development does not
take place at both locations,
some on-site teams prefer to
staff a developer so that they can
communicate with the off-site
team at all levels. Another situa-
tion that may demand an on-site
developer is if the deployment/
testing of the delivered system
requires technical support before
the customer/business analyst
can review and approve it.
� On-site QA. The on-site QA
team ensures that the code writ-
ten by the off-site team works in
a local staging or user accep-
tance testing environment that
duplicates production as closely
as possible. This team will work
closely with the developer liai-
son or on-site development team
to make sure any issues are
communicated and addressed.
� Sponsor. The sponsor must be
positioned to receive communi-
cation and metrics about the
project and to experience key
events in person. It is also bene-
ficial for the sponsor to visit the
remote site to meet the team
and form personal impressions
of the project members and their
working practices. Engaging the
sponsor will allow the sponsor to
form his or her own opinion of
distributed agile development
and communicate it to the wider
enterprise.
Off-Site Team Rolesand Responsibilities
The ideal off-site development
team would be made up of on-
site team members who have
been relocated to another site.
Failing that probably unrealistic
scenario, look for off-site teams
that have at least some familiarity
with your organization or industry,
since this will lessen the domain/
cultural learning curve at the start
of the project. In addition, build
your off-site team with proactive
communicators who are willing to
adjust their working practices to
mesh well with the on-site team.
Make sure the off-site team is
dedicated to your project and has
a common understanding of your
planned approach for project exe-
cution, including the willingness
©2004 CUTTER CONSORTIUM VOL. 5, NO. 4
EXECUTIVE REPORT 1111
to send ambassadors to your site
and accept visitors at its location.
The following roles and responsi-
bilities for the off-site team have
proven effective for distributed
agile development projects. As
with the local team, one project
member sometimes takes on
multiple roles.
� Iteration manager. The iteration
manager at the remote site com-
municates daily with the on-site
project manager to discuss the
risks, issues, and roadblocks that
the teams face at each site. The
iteration manager also collabo-
rates with his or her project
manager counterpart to track
and report project progress to
sponsors. Additionally, the itera-
tion manager has responsibilities
similar to those of the on-site
project manager regarding
encouraging communication,
building a positive culture, and
fostering a one-team attitude.
The overhead of overlapping
project managers is more than
made up for by the degree of
control, visibility, and assurance
that the off-site iteration man-
ager provides to a distributed
agile development team.
� Business analyst. Duplicating
business analysts at the local
and remote sites is a long-term
strategy that can pay major
dividends in distributed agile
development. Although off-site
analysts will often be less experi-
enced in the domain and project
goals at the outset, by working
with the on-site analysts over
time, they will come up to speed
surprisingly quickly and eventu-
ally will be quite able to stand
in as on-site business domain
experts for the majority of ques-
tions from developers. Having
someone locally available to act
as the customer in 80% of the
circumstances will significantly
lower the communication barri-
ers and increase the productivity
of the off-site team. Additionally,
off-site business analysts who
work on a project through sev-
eral releases often become
invaluable system experts when
on-site analysts move on or are
rotated to other projects.
� QA testers. Similar to business
analysis, building up a compe-
tency for functional, regression,
and system testing at the remote
development site is a great way
to accelerate distributed agile
development. The ability to get
rapid feedback from the test
team as soon as code is deliv-
ered, instead of waiting for feed-
back from remote testers, allows
development teams to fix issues
very quickly and increases the
quality of code eventually deliv-
ered to the local team.
� Off-site tech lead. It is advisable
to have one off-site developer
who is specifically not assigned
for work, but instead pair pro-
grams with all members of the
development team. Rotating
among the entire team will give
this person a big-picture view of
everything that is going on and
will enable him or her to serve
as a single point of contact on
the state of the code. This con-
centrated technical knowledge
can be useful at various points
in the project (such as at deploy-
ment time when he or she is
likely to rotate to the local
deployment site to see the
application into production).
� Off-site tech support. One way
to increase the productivity of
agile development teams is to
assign responsibility for the build
system and development envi-
ronment to a build and configu-
ration master. On a distributed
agile development project, this
person is also often responsible
for the communications and sys-
tems infrastructure between the
sites. Because outages in con-
nectivity can bring progress to a
grinding halt, it is worthwhile to
specifically allocate someone to
own the technical infrastructure
of your distributed agile develop-
ment project.
� Single point of contact (SPOC).
To further enhance communica-
tion, some teams have found it
useful to appoint someone to
be the single point of contact
between the off-site and on-site
teams. The SPOC agrees to do
whatever he or she can to
enable the teams to work
together — from tracking down
a person who gets a phone call
to ensuring that people adhere
to the communications practices
the teams agreed to at the outset
of the project.
VOL. 5, NO. 4 www.cutter.com
1122 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE
� Other specialists (as required).
Some projects require special-
ized types of domain or process
knowledge. For example, a
financial services application
may require someone who is a
certified accountant to specify
requirements and test function-
ality. Some applications need to
interface with legacy systems
with poorly documented data
structures and interfaces. Some
organizations have rigorous audit
or go-live processes to which the
off-site team must adhere. When
confronting a special project
consideration, always remember
that the more you can do to
locate or develop that knowl-
edge remotely (through rotation,
recruitment, or training of staff
located there), the more effec-
tive your team will ultimately
become.
Using some or all of these
roles on your project will pro-
vide a solid foundation for dis-
tributed agile development. But
to really make your teams per-
form well, you will also need
some ambassadors.
Ambassadors
The basic challenge of distributed
agile development is how to
transfer complex knowledge
about projects and processes
that is held in the heads of a
group of people in one location
into the heads of a group of peo-
ple in another location. Proven
team structures and disciplined
communication practices will
facilitate this exchange, but for
sheer effectiveness of communi-
cation nothing beats on-site visits.
According to Thomas Allen in his
groundbreaking study on how
technology-based communities
communicate, “Human beings
are the most effective carriers
of information, and the best way
to transfer information between
organizations or social systems is
to physically transfer a human
carrier” [1]. The most effective
distributed agile development
teams typically have about 20% of
team members working outside
of their base location at any point
in time. These ambassadors carry
domain, project, and team infor-
mation between the development
sites via regular visits. There are
two basic types of visits: seeding
visits and maintenance visits.
Seeding Visits
A seeding visit occurs the first
time people from the off-site team
visit the local site or the first time
people from the local site visit the
remote location. Seeding visits
tend to last a bit longer (two
weeks are the minimum) than
maintenance visits to allow for
sufficient team building and for
initial knowledge transfer to
occur. In addition to project-
related activities, the project
managers from each site should
ensure that the teams socialize
at work or in the evenings if
possible.
The first seeding visit usually
occurs when members of the
off-site team (often an iteration
manager, a business analyst, and
a tech lead) arrive at the local site
to help the customer articulate
and document the business
requirements during the early
phases of the project. A seeding
visit in the opposite direction may
also be planned for just prior to,
and that carries through the con-
clusion of, the first development
iteration. This visit would send
customer representatives (often
a project manager and business
analyst) to the remote site to
meet the team members and
be available to them locally for
a short time.
During the seeding visits, the team
members should just plain work
together. Developers should pair
program on code to reach a
common understanding of coding
standards and application archi-
tecture. Business analysts should
also pair up on defining require-
ments and communicating with
project stakeholders. Even project
managers should pair to collabo-
ratively come up with project
plans and progress tracking and
reporting mechanisms. By work-
ing together in person, everyone
will not only put names to faces
but also will get used to one
another’s working styles and learn
whom to go to with the various
questions or concerns that will
arise over the remainder of the
project.
Maintenance Visits
Once the seeding visits have been
completed, you should maintain
©2004 CUTTER CONSORTIUM VOL. 5, NO. 4
EXECUTIVE REPORT 1133
some level of rotation (in both
directions) throughout the course
of the project. These maintenance
visits can be of shorter duration
than the seeding visits. They serve
to keep relationships fresh and to
contribute to the flow of informa-
tion between project sites. The
length of the project will deter-
mine the number of maintenance
visits that will be required, but the
longer you go without a visit from
either side, the greater risk you
incur. A one-week visit in each
direction every six to eight weeks
is probably the minimum work-
able level of cross-pollination.
Longer-Term Ambassadors
Sometimes you will find someone
from the local site who is willing
(or even anxious) to relocate to
the remote location for a longer
period of time. You should
encourage and support this if it
is even remotely feasible, as the
constant presence of a local
team member at the remote site
will significantly boost communi-
cation and aid in knowledge
transfer. Remember, however,
that after too much time has
elapsed (six months is probably
the maximum), the local team
member will have become suffi-
ciently distanced from local
events such that he or she will
begin to lose value as an ambas-
sador to the remote site.
Ambassadors and theCost of Success
It may strike you that this degree
of staff rotation is exceedingly
high and in fact may jeopardize
some of the common benefits
ascribed to distributed develop-
ment (specifically cost savings
when using offshore teams).
While there is certainly overhead
associated with maintaining such
high levels of team rotation, do
not be tempted to skimp on this,
as it has been shown to be one of
the single most important factors
for distributed agile development
project success. Saving a few
dollars doesn’t warrant putting
the delivery of the entire project
at risk.
Additionally, if you view distrib-
uted agile development as a
long-term strategy for your devel-
opment organization, you should
view seeding visits as an invest-
ment for future projects. Once
the team members have largely
gotten to know one another, the
seeding visits become less critical.
Over time, they can be replaced
by less frequent maintenance
visits. Seeding visits will then
be required only for big new proj-
ects or to introduce new team
members to the organization.
Splitting Up the Work
In the simplest (and probably
most common) case, distributed
agile development teams are
structured so that business analy-
sis occurs at the local site and
development occurs off-site.
With a bit of thought, however,
this simple case can be extended
to cover split development teams
across multiple sites. The trick to
successful distribution of teams
working on common code is to
figure out how to not get in each
other’s way.
A best practice for scaling up a
development effort (whether or
not the effort is divided across
multiple sites) is to split it into
independent components that
can be worked on separately.
Getting this right can be quite
a complex chore that requires
collaboration between project
managers, businesspeople, and
technical staff. Don’t be tempted
into splitting teams based on busi-
ness function or resource location
alone, as divisions that are not
represented in the structure of
the underlying code are essen-
tially arbitrary and will not allow
teams to work independently.
If you are considering multisite
development efforts, consult with
your techies to help you choose
which work is sent off-site. Be
prepared to learn that you need to
do some work to restructure the
code so that it is more modular
and cleanly separated.
Another factor to consider when
you are trying to decide which
work to do off-site versus on-site
is the complexity of the domain
and the need for on-site experts.
If you are building software to run
a nuclear power station and you
have only one nuclear engineer
(who will only work from the
local site), you should keep the
“reactor monitoring” functionality
on-site and send the “time and
expense reporting” modules to
the off-site team.
VOL. 5, NO. 4 www.cutter.com
1144 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE
©2004 CUTTER CONSORTIUM VOL. 5, NO. 4
EXECUTIVE REPORT 1155
Access to external systems upon
which your system is dependent
is critical for the development
team. Agile teams can work won-
ders with mocks and stubs (ways
to quickly simulate external sys-
tems), but at some point, you
need real connectivity to ensure
everything will work when the
system goes live. If you cannot
provide adequate access to
dependent systems, you should
consider doing this portion of the
development work on-site, where
those systems are available.
A final item to consider is your
project release schedule and
any requirements for application
support. In one case, when faced
with the need to deliver and sup-
port regular successive releases,
a distributed agile development
team experimented with various
approaches but ultimately found it
best for one team to do both the
development and early-life sup-
port of each release. In this way,
the team could see its work all
the way through the go-live
process and provide rapid
response to eliminate any bugs
found in production. While this
team was busy supporting its
production release, the other
team was building the next
release. Once production was
stable, the on-site team went into
deployment/support mode and
the off-site team took a cut of its
release to begin work on the next
release.
Each project will have its own
unique drivers, but whatever
approach you choose for splitting
up the work should account for
the location and availability of
critical intellectual capital and
should be guided by the desire to
reduce delivery risk and transfer
greater application knowledge
among all participating teams.
DISTRIBUTED AGILEDEVELOPMENTCOMMUNICATION PATTERNS
Compensating for the reduction
of communication that comes
with distance is a critical enabler
of distributed agile development.
In response to this need, the mar-
ket is teeming with high-priced,
technology-based offerings guar-
anteed to improve off-site collab-
oration. Be wary of gizmos and
gadgets that have novelty appeal
but do little to enable and sustain
basic communication on a con-
tinual basis. Build your com-
munications infrastructure out
of simple, low-overhead tools
that provide instant access
(such as telephones) instead
of complicated tools that take
time to configure and need to
be scheduled in advance (such
as videoconferencing).
With so many options available,
it can be difficult to decide which
practices, tools, and technologies
are best for enabling distributed
agile development. The following
have proven useful on numerous
projects and form the beginnings
of a communication-pattern
toolkit for distributed agile
development:
� Communication plan. The
most important tool in your
toolkit isn’t a technology at all;
it is a good old-fashioned plan.
The project managers (from
both the local and remote sites)
should collaborate with one
another and their local teams
to reach consensus on how
the two sides will work together.
The plan should be quite
detailed and include items
such as schedules of ambas-
sador visits; project roles/
responsibilities (including spe-
cial communication-focused
roles such as the SPOC); contact
details for all team members;
chosen communication tech-
nologies; instructions and eti-
quette guidelines for using the
chosen technologies; meeting
schedules; plans for the shifting
of working hours to maximize
real-time overlap (if required);
and details on project docu-
ment repositories and shared
machines. It is important to
ensure that everyone on the
team (and anyone who joins
while the project is in flight) has
reviewed and agreed to follow
the communication plan. It is
advisable to schedule a special
teleconference between the on-
site and off-site teams while the
project is kicking off to discuss
and agree on the communica-
tion plan. The plan should be
reviewed and adjusted as part
of the retrospective that follows
each development iteration.
� Instant messaging. If you
observe colocated teams while
they work, you will notice that
there is almost constant bub-
bling conversation. While the
conversation may not always be
directly related to the work at
hand, it forms an important part
of the communication context of
the project that is largely lost by
distributing the teams. The tech-
nology that has proven most
effective for simulating team
chatter is IM. In addition to pro-
viding an extremely low-cost
means of communication, these
tools provide the critical feature
of visually showing online avail-
ability of teammates in remote
locations. By ensuring that your
entire team has IM accounts
and uses them appropriately
(that is, team members log out
or change their status when
they leave their desks), you can
create a virtual community that
massively increases the level of
communication between your
off-site teams.
� Wikis. A Wiki (see http://wiki.
org/wiki.cgi?WhatIsWiki) is an
easy-to-use technology that facil-
itates the creation and editing of
Web pages. By typing and edit-
ing plain text, Wiki users can
post content that can be imme-
diately viewed by everyone with
access to the Wiki. Medium to
large distributed agile develop-
ment teams (with 10 or more
people) have made great and
productive use of Wikis as both
a lasting record of project com-
munication and a daily collabo-
ration tool. Posting important
project information (such as
team names and numbers,
information about project scope,
and minutes from technical
reviews) on the Wiki instead of
communicating it via e-mail (or
not at all) does wonders to foster
a common view of the project
across multiple sites. It also has
the added benefit of allowing the
team to add new members and
bring them up to speed quickly
as new members can get a great
deal of context by simply reading
the content on the Wiki.
Additionally, many Wikis have
functionality that allows users
to subscribe to certain pages.
Subscribers will receive e-mails
whenever those pages change.
By asking everyone who is
involved with a particular piece
of work (a story card or feature)
to subscribe to the page that
represents that piece of work,
you can create small virtual
teams with essentially zero over-
head. As long as all team mem-
bers agree to update the Wiki
whenever anything substantive
changes, the entire virtual team
will remain updated with the lat-
est developments on each piece
of work. They can follow up via
IM or phone. A final thing to
mention about Wikis is that they
require a bit of management.
Left on their own, they will
evolve organically and may end
up containing a mix of useful
and relevant information as well
as some poorly organized, hard-
to-find, or out-of-date communi-
cation. If you decide to use a
Wiki, you should put some
thought into the general struc-
ture it will use and appoint
someone (the SPOC or project
manager) to monitor content
and reorganize or extend the
Wiki structure when necessary.
You should also specifically
discuss Wiki etiquette and usage
with the team with some fre-
quency. Making the Wiki a desti-
nation of choice for project team
members is a great way to boost
communication and foster a
one-team feeling between physi-
cally separate workgroups.
� E-mail. Despite its ubiquitous
use, e-mail is not a very helpful
tool for distributed agile develop-
ment. E-mail conversations
between two people are much
less efficient and interactive
than a phone call or an IM chat:
e-mails copied to large groups
are copied only to those who
the original sender believed
would be appropriate and often
spawn fragmented or unclear
responses; project announce-
ments sent via e-mail are not
available to people who join
the project after the announce-
ment was circulated; people
are left off distribution lists —
and the list of problems goes
on and on. It would be too
extreme to ban e-mail on a
distributed agile development
project, but it would certainly be
wise to impose strict etiquette
on e-mail usage and try to
encourage team members to
switch to some of the other
communication tools described
here. Some teams have found it
VOL. 5, NO. 4 www.cutter.com
1166 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE
useful to perform a daily review
of outstanding unanswered
e-mails as part of their regular
status meetings (a day spent
waiting for an answer to an
e-mail is often a day completely
wasted). Because people have
become so accustomed to using
it, the shift away from e-mail is a
difficult one and will probably
require significant encourage-
ment and support from project
managers in both locations.
� Phone calls. Despite the avail-
ability of many text-based
alternatives, distributed agile
development teams should con-
tinue to include phone calls in
their communication toolkit.
Regular phone calls serve to
maintain relationships in ways
IM or Wikis never can, as voices
and conversations carry much
more context than plain words
ever will. Teams should be made
aware and taught to think about
issues that are appropriate for
phone and issues where other
channels are sufficient. Ques-
tions of fact or questions with
binary answers are fine for IM
chats while questions of opinion
or questions seeking context are
best left for the phone. If teams
are separated by many time
zones, it is important to agree on
some rules for phone contacts at
the outset and for both sides to
exercise flexibility in being con-
tacted outside of standard work-
ing hours.
Additionally, although most
people talk on the phone nearly
every day, the conversation
usually takes a one-on-one form.
Conference calls, which are
quite useful for some activities
in agile development projects
(such as iteration kickoff meet-
ings or “virtual standups”), are a
very different type of communi-
cation pattern. Do not make the
mistake of thinking that every-
one on the team will do the right
thing to make conference calls
successful. Many distributed
agile development teams have
given specific responsibility to
someone on each side of the
conference call (often the SPOC)
to moderate and maximize the
effectiveness of the conversa-
tion. This person watches body
language at his or her location
and ensures that everyone who
has something to add has a
chance to have their say. This
person also asks for clarification
when it is apparent that some-
thing is unclear.
� Standup meetings. A distin-
guishing characteristic of many
agile development teams is their
daily standup meetings. These
meetings are designed to be
short and to air any issues facing
the team. They also allow people
to coordinate efforts and syn-
chronize with one another
before starting the workday.
Finally, they provide a bit of a
project pulse and publicize prob-
lems and risks early so they can
be dealt with or communicated
more widely instead of coming
as a surprise several weeks later.
These meetings are essential to
agile development, and you
need to find a way to include
them in your distributed devel-
opment practices. Some teams
find it effective to hold daily
virtual standups during a confer-
ence call, which is attended by
all members from all locations.
Other teams hold local standups
and appoint someone to publish
brief notes (on the wiki). That
person is also responsible for
following up with the other
team on any cross-location
issues. Some teams use a hybrid
approach, implementing one or
two virtual standups a week with
on-site standups taking place on
days when no virtual standup is
scheduled.
PROJECT STEERINGAND TRACKING
The iterative nature of agile devel-
opment directly addresses many
of the project tracking and visibil-
ity issues posed by distributed
development. Most of the project
tracking and steering practices of
agile development apply directly
with very little modification other
than making sure to include
the right people in the various
processes, regardless of where
they happen to sit.
Steering
To rightfully be termed agile
development, technical teams
must collaborate with their
customers on a regular basis to
choose what to work on next.
The goal of this collaboration is
to move project planning away
from being a point-in-time event
©2004 CUTTER CONSORTIUM VOL. 5, NO. 4
EXECUTIVE REPORT 1177
and toward more of a continuous
balancing act over the course of
the project. On a normal agile
development project, project
steering takes a multitude of
factors as inputs, including shifting
business priorities, progress to
date, technical risk, schedules,
dates, and availability of key
resources. On a distributed agile
development project, the only real
difference is that there may be
several other factors to consider,
such as the following:
� Does the off-site team have
connectivity to required third-
party systems as is necessary
to begin developing a certain
set of components?
� Should we postpone a particu-
larly tricky or new area of the
system until the next scheduled
ambassador visit to the off-site
location?
� What will the availability of the
off-site team be during this itera-
tion (may be different if the off-
site location has holidays or
festivals that are not synchro-
nized with the on-site team)?
Additionally, it is strongly sug-
gested that members (ideally a
project manager, technical lead,
and business analyst) from the
off-site development team are
present in person for the first few
project-steering sessions. During
these initial sessions, it becomes
very clear which stakeholders are
advocates for which priorities and
how the various customer repre-
sentatives see the project playing
out. After the first couple of steer-
ing sessions, the team should be
able to lay out a rough release
plan that provides a projection
of the course of development
over at least a few months. At this
time, the off-site members can
return to their home base and
participate in future steering ses-
sions via phone, returning for per-
sonal appearances only if major
changes occur.
Tracking
Agile development provides
the capability to track projects
at an extremely detailed level.
This detailed tracking serves to
address many fears about distrib-
uted development that are based
simply on the inability to see the
team working.
As mentioned above, the on-site
and off-site project managers
should agree on a framework for
project tracking at the outset. At a
minimum, this framework needs
to include initial estimates for
each unit of work, refined esti-
mates done at the time the work
is started, and actual time spent
to complete the work. Collecting
and analyzing these three num-
bers will greatly enhance the
project’s ability to measure its
development capacity (as well as
its skill at estimating). It will high-
light problems quickly and allow
for projections going forward that
are vital as inputs into project-
steering activities.
The remainder of the burden of
tracking isn’t the responsibility of
the project managers at all, but
rather of the team itself. Because
agile teams incrementally build
production-ready code, they have
the unique ability to demonstrate
completeness along the way. After
every development iteration, it is
critical to go through the exercise
of showcasing those parts of the
system that have been completed
at the remote site to the local cus-
tomers and stakeholders. These
showcases not only serve to build
trust and confidence in distributed
agile development but also offer
highly effective forums for collect-
ing feedback on the system under
construction and feeding that
information into the project-
steering process (and back to
the off-site team).
You may find that there is a lot of
overhead involved in preparing
for and executing iteration show-
cases, but by being disciplined
about maintaining a regular “plan,
build, showcase, replan” cycle,
you essentially incrementally
achieve system sign-off from your
customers and stakeholders. By
the time you deliver the final sys-
tem, it has essentially been
accepted. If for some reason your
customers are unwilling to review
regular showcases, you should
find a way to simulate this by
holding internal showcases every
couple of weeks. That way, by
the time your customers are ready
to have a look, the process of
deploying and showing off the
system will be silky smooth and
all that much more impressive.
VOL. 5, NO. 4 www.cutter.com
1188 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE
DEVELOPMENT PRACTICESAND TOOLS
The various incarnations of agile
development recommend a
plethora of development practices
designed to enable and facilitate
agile ways of working. Of all the
development practices to choose
from, the following are the four
most critical in distributed agile
development projects:
� Continuous integration. If prac-
ticed with discipline, continuous
integration (the process by which
developers integrate their code
and build the entire system
whenever they have made
changes) should reduce or even
eliminate on-site deployment
risk at the end of a distributed
agile development project. The
value of continuous integration
is that it solves small integration
headaches immediately instead
of trying to solve huge ones at
the end. The key is to make sure
that the automated build system
builds quickly and then tests and
deploys into an environment that
simulates the production envi-
ronment to the highest degree
possible. This practice is so criti-
cal that on a project of any size
(i.e., more than 10 developers)
or with concurrent development
in multiple sites, it is often useful
to make the construction and
maintenance of the build system
a distinct role so that it gets the
attention it deserves.
� Test-driven development.
Faced with reduced communi-
cation bandwidth, distributed
teams must constantly be on
the lookout for ways to reduce
ambiguity in their communica-
tion between sites. Without a
doubt, test cases are the clearest
way to describe requirements
and to document the code that
implements those requirements.
Communicating via test cases
(both between business analysts
and developers and among
developers working on the sys-
tem) is an agile best practice
that is even more beneficial in
a distributed agile development
project environment.
� Collective code ownership.
Teams practicing collective code
ownership allow any developer
to change any piece of code
with impunity — providing all
the test suites pass following the
change. This practice encour-
ages developers to write code
with a high degree of test cov-
erage (to ensure it won’t be
broken by someone down the
line) and greatly improves the
internal quality of the system.
It also allows teams of develop-
ers who are not colocated
(and who may never have met)
to trust one another enough
to work on the same code.
Distributed agile development
between multiple sites would
not be possible without col-
lective code ownership —
especially in light of how
development teams that are
separated by many time zones
would otherwise have to wait a
day for their off-site teammates
to wake up every time they
wanted to touch any code devel-
oped at the other site.
� Agile configuration manage-
ment. Veterans of the software
development game have proba-
bly all had someone tell them
(often wryly) when faced with
a broken system that “it works
on my machine!” The fact is
that as systems increase in com-
plexity from simple executables
to complex, multitier enterprise
systems that integrate with mul-
tiple other systems, the constant
deployment demanded by agile
development becomes an enor-
mous challenge. When you
add the fact that development
will be going on in two locations
that are often quite different in
terms of technical infrastructure,
you begin to appreciate why
successful distributed agile
development teams often
employ someone specifically
to address this problem.
Configuration problems can
bring the critical rapid feedback
cycles of distributed agile devel-
opment to a grinding halt. To
mitigate this risk, you must have
someone on the project whose
job is to understand and manage
the development, test, and
deployment environments at
all project sites.
DEPLOYMENT AND SUPPORT
Depending on how the project
has been progressing, the deploy-
ment phase may turn out to be
somewhat of a nonevent. If the
result of each iteration has been
released into production, then
©2004 CUTTER CONSORTIUM VOL. 5, NO. 4
EXECUTIVE REPORT 1199
when the iterations end, there
are no additional special activities
required to get the system live.
However, if you were unable to
fully practice continuous deploy-
ment, you may still need to install
the system in the production envi-
ronment and perhaps go through
some formal audit or acceptance
testing prior to going live.
This final part of the project is
an excellent time to schedule
a visit to the local site by the
ambassador at the remote site
so that the people who built and
configured the system are also
available in real time to get it
installed and launched. The peo-
ple who should visit are probably
the configuration manager and
one or more of the technical staff,
although you will need to con-
sider your specific project situa-
tion and plan the participation
accordingly.
Once the system is live, you will
arrange for some period of transi-
tion from distributed agile devel-
opment into live support. As a
general rule, teams that are built
for distributed agile development
are not well suited to the chal-
lenges and duties of system sup-
port. These are very different jobs
that require very different skill
sets. Depending on your strategy,
you should select a support
provider and work to transition
the knowledge from the develop-
ment team to the support team.
Transitioning a system that is
developed using distributed agile
development to support isn’t
really much different from transi-
tioning any other system except
that your system should have
cleaner, more fully tested code
and will come with an automated
build and testing system that
should prove very useful to the
support organization.
CULTURE AND MORALE
In addition to all the tangible prac-
tices discussed above, one thing
that the most successful distrib-
uted agile development teams
have in common is a culture of —
for lack of a better word — fun.
Although the decreased personal
interaction can negatively impact
morale, distributed agile develop-
ment also presents team mem-
bers with opportunities to travel
and to work with a new group of
people on solving hard problems.
The best distributed agile develop-
ment project managers work hard
to foster a one-team feeling, often
by posting pictures of the off-site
team and encouraging the sharing
of stories across locations. They
also make sure outbound ambas-
sadors are loaded up with gifts for
the off-site team and look after the
inbound ambassadors that visit
their own site. They help establish
common practices and do not
allow finger-pointing when some-
thing goes wrong. Finally, they
actively encourage communica-
tion until the teams have bonded
enough that they do not need
encouraging.
These culture- and morale-related
considerations are not just nice
to have; they can make the differ-
ence between success and failure
on a distributed agile develop-
ment project. Making distributed
agile development work requires
people to change their working
practices, to travel away from
home, and sometimes to come in
to work early or stay late to maxi-
mize overlap with a remote team.
Things do go wrong, and people
can feel powerless because of
their inability to get involved in
person. Those who are having
fun working together on a happy
team will be willing to give the
extra effort that is required to
make distributed agile develop-
ment succeed.
CONCLUSION
It should now be clear that distrib-
uted agile development has the
potential to help your organization
realize some powerful benefits. It
should also be clear that you must
proceed with care and work hard
at planning and executing a port-
folio of projects to build up your
distributed agile development
competency over a period of
several years. By applying the
lessons learned and best practices
described above, you can lever-
age the hard work of those who
have gone before you and signifi-
cantly increase your chances of
succeeding with distributed agile
development. It will still be hard
work and require fortitude and
determination, but take encour-
agement in the knowledge that it
VOL. 5, NO. 4 www.cutter.com
2200 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE
can indeed be done. As you and
your teams encounter and eventu-
ally overcome challenges that
aren’t even addressed here, you
will contribute to the art and
science that is distributed agile
development, and you will con-
tinue to change the way we live
and work. Good luck!
REFERENCES
1. Allen, Thomas J. Managing
the Flow of Technology. 6th ed.
MIT Press, 1993.
2. Andriole, Steve. “Be Careful
Out There.” Cutter Consortium
Business Technology Trends
and Impacts E-Mail Advisor,
25 September 2003.
3. Mah, Michael. “Offshore
Outsourcing: A Tale of Two Bids.”
Cutter Consortium Business
Technology Trends and Impacts
E-Mail Advisor, 21 August 2003.
4. Simons, Matthew.
“Internationally Agile.”
InformIT. Pearson Education,
15 March 2002.
ABOUT THE AUTHOR
Matthew Simons is a project
manager and distributed agile
development advocate for
ThoughtWorks. For most of the
past 10 years, he has managed
large teams that are using
advanced technologies to
deliver strategic enterprise
systems. He has particular
expertise in adapting agile devel-
opment approaches to large
and/or distributed projects.
Mr. Simons has been involved
with ThoughtWorks’s distributed
agile development teams from
the earliest days. For the first year
of operations of TW-India, he
was based out of Bangalore and
was primarily focused on how
to extend the ThoughtWorks
agile development approach to
support offshore development.
Mr. Simons is currently based in
London, where he continues
to help extend and proliferate
ThoughtWorks’ distributed agile
development model. His most
recent project used a 150-person
development team distributed
among London, Bangalore,
Chicago, San Francisco, and
Calgary to build a point-of-sale
system for a major UK retailer.
He can be reached at mtsimons@
thoughtworks.com.
©2004 CUTTER CONSORTIUM VOL. 5, NO. 4
EXECUTIVE REPORT 2211
Abou
t the
Pra
ctice Sourcing and Vendor
Relationships PracticeCutter Consortium’s Sourcing and Vendor Relationships Practice provides companieswith objective information, advice, and data that enable them to make sense of allsourcing options. Organizations get advice on how to develop, implement, andmanage a sourcing strategy that frees up scarce and expensive resources so theycan concentrate on development projects that are crucial to gaining or maintaininga competitive edge.
The subscription-based component of this service addresses issues such asmaking the outsourcing decision, structuring outsourcing contracts, relationshipmanagement, offshore outsourcing, service levels, and other essentials.
Personalized consulting help is available to enable you to manage sourcing projectsand relationships effectively, negotiate contracts, develop and implement a metricsprogram, write enforceable service-level agreements, create appropriate pricingschemes, choose an application service provider, and more.
Products and Services Available from the Sourcing and VendorRelationships Practice
• The Sourcing and Vendor Relationships Advisory Service• Consulting• Inhouse Workshops• Mentoring• Research Reports
Other Cutter Consortium PracticesCutter Consortium aligns its products and services into the nine practice areasbelow. Each of these practices includes a subscription-based periodical service,plus consulting and training services.
• Agile Project Management• Business Intelligence• Business-IT Strategies• Business Technology Trends and Impacts• Enterprise Architecture• IT Management• Measurement and Benchmarking Strategies• Risk Management and Security• Sourcing and Vendor Relationships
Senior ConsultantTeamEach of the individuals on the CutterConsortium Sourcing and Vendor Relationshipsteam is an expert in outsourcing, offering theexpertise that comes from decades of hands-on, real-world experience. The team includes:
• Eric Buel• Bill Curtis• Carole Edrich• Michael J. Epner• Danny Ertel• Ian Hayes• David Herron• Jonathan Hughes• Wendell Jones• Stuart Kliman• Michael C. Mah• Marty McCaffrey• Eugene G. McGuire• Bart Perkins• William Ulrich• William A. Zucker