Sourcing and Vendor

Relationships

Vol. 5, No. 4

Distributed Agile
Development 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.

Cutter Business Technology Council

Rob Austin Tom DeMarco Christine Davis Lynne Ellyn Jim Highsmith Tim Lister Ken Orr Ed Yourdon

Access About Cutter Consortium

to the
Experts Cutter Consortium’s mission is to foster the debate of, and dialogue on, the business-
technology issues challenging enterprises today and to help organizations leverage IT
for competitive advantage and business success. Cutter’s philosophy is that most of the
issues managers face are complex enough to merit examination that goes beyond simple
pronouncements. The Consortium takes a unique view of the business-technology
landscape, looking beyond the one-dimensional “technology” fix approach so common
today. We know there are no “silver bullets” in IT and that successful implementation
and 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 a
team of Senior Consultants whose credentials are unmatched by any other service
provider. This group of experts provides all the consulting, performs all the research
and writing, develops and presents all the workshops, and fields all the inquiries from
Cutter clients.

This is what differentiates Cutter from other analyst and consulting firms and why we say
Cutter gives you access to the experts. All of Cutter’s products and services are provided
by today’s top thinkers in business and IT. Cutter’s clients tap into this brain trust and are
the beneficiaries of the dialogue and debate our experts engage in at the annual Cutter
Summit, in the pages of Cutter IT Journal, through the collaborative forecasting of the
Cutter Business Technology Council, and in our many reports and advisories.

Cutter Consortium’s menu of products and services can be customized to fit your
organization’s budget. Most importantly, Cutter offers objectivity. Unlike so many
information providers, the Consortium has no special ties to vendors and can therefore
be completely forthright and critical. That’s why more than 5,300 global organizations
rely on Cutter for the no-holds-barred advice they need to gain and to maintain a
competitive edge — and for the peace of mind that comes with knowing they are
relying 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].
 Distributed Agile Development
and the Death of Distance
SOURCING AND VENDOR RELATIONSHIPS
ADVISORY SERVICE
Executive Report, Vol. 5, No. 4

by Matthew Simons

Software development teams However, cost is not the only dri- n Workspace unavailable (when
around the world have been try- ver for distribution; in fact some space is at a premium, large
ing to solve the riddle of distrib- organizations are finding that the development teams must
uted development for years. The case for cost savings is not as work elsewhere in order to
problem is so thorny because soft- strong as the hype suggests [3]. be together)
ware development is, at its core, Some of the most common rea-
n Use of vendors with off-site
based on communication. Every sons for considering distributed
development facilities (reduction
aspect of a project is fundamen- development include:
in travel costs by allowing vendor
tally changed the moment that
team members lose the ability to n Cost savings (utilizing offshore employees to work near their
teams) homes)
walk down the hall or meet at the
water cooler to communicate face n Schedule compression (bringing n Quality of life (not requiring proj-
to face. Many organizations have more resources to bear) ect team members to travel or
tried, but unfortunately the annals relocate means happier teams
n Scale (breaking a large effort into
of software development history that can include seasoned and
manageable components)
are crammed with sad stories of mature individuals whose family
distributed projects gone wrong. n Access to technical talent commitments do not permit
(specialized technical skills them to be road warriors)
Yet its allure remains too powerful may not be available locally)
to ignore. With the recent rapid n 24/7 availability of development
growth in offshore development n Proximity to business sponsors (for support or “follow the sun”
(customers are not always development)
service providers, cost savings
is at the top of any list of drivers located near developers)
for distributed development.
 2 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE

Fortunately, there is a promising AN AGILE DEVELOPMENT processes have been described by

new option for those of you who PRIMER1 the nonprofit AgileAlliance organi-
are faced with making distributed Agile software development is zation (www.agilealliance.com)
development work for your orga- an umbrella term that is used to in the following ways:
nizations. Recent developments in describe a family of approaches
technology have spawned a way n Individuals and interactions
for software project management over processes and tools
of working, known as agile soft- and execution that has evolved
ware development, that have during the past five to 10 years. n Working software over compre-
proven very effective at delivering The best known of these include hensive documentation
software. What would happen if Extreme Programming, Feature- n Customer collaboration over
we applied this way of working Driven Development, and contract negotiation
to distributed development teams? Adaptive Software Development,
The answer to that question but there are a number of others. n Responding to change over
might just mean a major step The priorities shared by all agile following a plan
forward in our quest to make
reliable distributed development 1If you are not familiar with “The New The priorities in the second half
Methodology” (www.martinfowler.com/ of each statement are typical of
a reality. This Executive Report articles/newMethodology.html), this section
helps provide that answer. provides a brief overview. 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
Cost of change

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
Requirements Analysis/design Code Test Integrate/live construction of systems. In other
words, the cost of change curve
Project stage
has become less steep (see
Figure 1 — The cost of change curve. Figure 2).

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. Unauthorized
reproduction in any form, including photocopying, faxing, and image scanning, is against the law. Reprints make an excellent training tool. For
information about reprints and/or back issues of Cutter Consortium publications, call +1 781 648 8700, or e-mail [email protected].

VOL. 5, NO. 4 www.cutter.com

EXECUTIVE REPORT 3

Agile methods have capitalized

on this trend through working
practices that maximize the devel-
opment team’s ability to evolve a

Cost of change
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
Time
documents), and enforcing disci-
plined development practices Figure 2 — The new cost of change curve.
(simplicity of design and auto-
mated testing).

Business-unit people like agile small, colocated teams of devel- rapidly with physical separation
development because it demon- opers and customers. That makes [1]. People located 100 meters or
strates regular visible progress it useful for many organizations more apart have only about a 5%
and enables them to evolve the and teams, but ignores a large chance of talking to one another
system in response to rapidly and growing class of software in a typical week. In other words,
changing requirements. It also projects that involve some degree the recommendations in this
allows them to realize incremen- of distribution. report are just as applicable to
tal ROI as they go, instead of wait- your multi-story project as they are
ing until the project is finished for ARE YOU DISTRIBUTED? to your multi-continent project.
big-bang benefits that might never
materialize. Amid the current hubbub sur- Continuing upward on the scale of
rounding offshore outsourcing, it distribution complexity, we come
Development teams like agile is easy to forget that distributed to projects with concurrent devel-
development because it mitigates development has many forms. opment at several business cen-
many of the risks of software The simplest and most often over- ters within the same company.
development (such as “integration looked form of distributed devel- Outsourcing work to external
hell” at the end of a long project) opment is what happens on a organizations further inhibits
and because there is mounting project that outgrows its work- communication, as illustrated in
anecdotal evidence that experi- space and is forced to spread out Figure 4 (adapted from [1]).
enced agile teams build higher- into multiple locations within the
quality systems more quickly than same office or at multiple offices Offshore distributed projects
do teams using other methods. in the same campus or region. belong at the top of the com-
Figure 3, adapted from Managing plexity scale because they
Agile development was initially the Flow of Technology, shows must overcome not only the
envisaged for and applied to that communication falls off challenges of distance and of

©2004 CUTTER CONSORTIUM VOL. 5, NO. 4

 4 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE

Likelihood of weekly communication

commonly associated with dis-
100%
tributed projects increases (see
Figure 5). Many teams face such
problems as the following:
10%
n Disconnection on project
requirements. The customer
and the development team can
1%
quite easily develop divergent
understandings of the project
requirements. This can happen
either because the requirements
.1% have changed or because they
1 10 100 1,000 10,000 were not properly understood in
Separation distance (meters) the first place. Needless to say, if
Figure 3 — Communication probability as a function of distance. this goes uncorrected, it causes
great dismay when the long-
awaited software finally arrives.

n Disconnection on project
40% estimation. Customers, man-
Likelihood of weekly communication

agers, and developers estimate

35% projects differently, each using
their own amount of leeway
30% based on personal experiences.
25% In a distributed project, in which
it is likely that these groups will
With organizational bond never meet in person, the stan-
20%
Without organizational bond dard deviation of project esti-
15% mates can vary quite a bit.

10% n Decreased visibility into proj-

ect status. It is often difficult for
5% managers and sponsors of a dis-
tributed project to get an accu-
0 10 20 30 40 50 60 70 rate sense of project progress
and status. Many have been
Separation distance (meters) unpleasantly surprised at late
stages of a project to find that
Figure 4 — Communication probability as a function of distance:
intragroup and intergroup. their understanding of “percent-
age complete” was less than
accurate.
multiple organizations but also of As you move further up the com- n Configuration management.
language, cultural, and temporal plexity scale, your risk of experi- Bringing it all together for imple-
inhibitors. encing one or more of the pitfalls mentation in the production

VOL. 5, NO. 4 www.cutter.com

EXECUTIVE REPORT 5

Less Complex More Complex

Colocated Team not Team on Noncolocated team Team distributed

development seated together different floors/ of >1 organization across time zones
buildings and cultures

Figure 5 — Complexity scale for distributed projects.

environment is one of the most introduces into the process. As in response, we choose the work
difficult parts of any software a result, distributed teams have we distribute very carefully. We
project. Many distributed teams been living in the world of keep the difficult, strategic initia-
have faced serious or (in some requirements specs, component tives close to home and use off-
cases) intractable problems designs, and long periods of inte- site resources for maintenance
integrating and deploying the gration testing (which is often work or well-defined projects.
components in the production really a euphemism for “the time
environment. when we come on-site to actually But wouldn’t it be great if you
make it work”). didn’t have to consider the com-
n Erosion of trust. People build
plexity or strategic importance
trust through communication.
Additionally, the erosion of trust of your project when deciding
As teams get further and further
caused by decreased personal which work you can do off-site?
removed from one another
contact causes us to adopt con- Wouldn’t it be great to realize all
(spanning time zones, lan-
trolling behaviors and attempt to the benefits of distributed devel-
guages, and cultural divides),
manage delivery risk with legal opment on your most important,
it becomes entirely possible
contracts. Some contracts for dis- complex initiatives?
for each site to develop radically
tributed development projects
divergent visions of project inten-
contain so much detail that they DISTRIBUTED AGILE
tion, progress, practices, and DEVELOPMENT FOR
start to sound like requirement
status. When these divergent THE NEXT GENERATION
specs or project plans in their OF DISTRIBUTED PROJECTS
versions of reality come to light,
own right. They also tend to
it can damage personal and pro- The way forward for leading IT
penalize customers for changing
fessional relationships irrevoca- organizations lies at the intersec-
their mind. Punishing change goes
bly and make working together tion of agile development and dis-
against the reality of modern busi-
a very unpleasant experience for tributed teams. The principles and
ness, where responding to market
both sides. practices of agile software devel-
demand (a very good thing) often
means changing your mind. opment that make it so effective
Controlling the Chaos
at delivering complex systems
Most approaches that are And yet despite all of our controls with rapidly changing require-
designed to address the chal- and protections, often it still ments work to directly address
lenges of distributed development doesn’t work as well as we many of the prime risk areas of
tended to take decreased com- had hoped. Projects fail entirely, distributed development [4].
munication bandwidth as a given underdeliver, or run over budget. Distributed agile development
and have evolved structures and Customers are unhappy, and is a powerful new approach to
tactics to manage the risk this everyone blames one another. So software delivery that will allow

©2004 CUTTER CONSORTIUM VOL. 5, NO. 4

 6 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE

that you must put in place before

Technical Complexity

Agile you begin. Many of these items

have relatively long lead times, so
Distributed it is wise to get them underway
Agile immediately once you have
t
r o jec decided to try distributed agile
P isk
R development.

Experience with Nondistributed

Agile Development

Distributed agile development

Strategic Need
clearly derives from standard agile
Figure 6 — Where distributed agile development can work. development. Think of it as an
advanced application of the fun-
damental practices employed by
nondistributed agile teams. There
global IT organizations to change learning curve for all project is a learning curve associated with
the way they think about what participants and sponsors. adopting standard agile develop-
they do and what they can ment — not only in mastering
achieve. However, once you have over-
the practices but also in achieving
come the leaning curve, there is
the shift in mindset that happens
As illustrated in Figure 6, a distrib- almost no limit to what your orga-
across the project team, its man-
uted agile development approach nization can achieve with distrib-
agers, and sponsors. Mastering
is appropriate for a wide band of uted agile development. The rest
agile development takes practice
enterprise-level projects in the of this report focuses on how to
and concerted effort over months,
upper-right quadrant of the plot develop an organizational compe-
not weeks. While it may be possi-
of “technical complexity” against tency for distributed agile soft-
ble to “go distributed agile” with-
“strategic need.” Distributed agile ware development through the
out first “going agile,” it would
development is not right for every building of a portfolio of success-
certainly be a more difficult and
project, but you should seriously ful distributed agile development
risky proposition. If your organiza-
consider applying some of its best projects. The lessons learned and
tion has not started using agile
practices for any project in your best practices described here are
development practices locally,
portfolio that includes an element based on personal experiences
it would be wise to start a few
of distribution. since 2000 working with and
teams on the path toward on-site
observing distributed agile devel-
agile even as you begin to lay the
Since agile development was opment teams that range in size
groundwork for distributed agile
originally proposed for colocated from five to 150 members.
development.
teams of customers and develop-
ers, there is not a direct mapping Before You Get Started ...
between practices on distributed Appropriate Off-Site Staff/Partner
Don’t be tempted to pick a project
and nondistributed agile develop- In addition to building your own
and jump into distributed agile
ment teams. The differences in organization’s knowledge of agile
development headfirst. There are
project-execution practices are practices, it will behoove you to
some fundamental structures,
subtle but critical, and there is a work with an off-site team that
qualifications, and building blocks

VOL. 5, NO. 4 www.cutter.com

EXECUTIVE REPORT 7

has agile experience. If your dis- consultants may need to come to distributed agile development
tributed project is within your own terms with new types of relation- requires investment in enabling
organization, introduce on-site ships. It is possible that some technologies and infrastructure.
agile development at all project employees may view performing The items listed below may seem
locations prior to rolling out work elsewhere as a threat to somewhat incidental. However, if
distributed agile development. If their own positions — especially you are unwilling or unable to
you are outsourcing development, if that work has been shifted to provide your team with an envi-
look for a vendor with a track a low-cost development center. ronment that is set up to facilitate
record of successful agile delivery All these considerations must be communication, you should
or (ideally) experience in applying managed. seriously question your desire to
agile practices to distributed proj- adopt distributed agile develop-
ects. Adding the challenge of Since every situation is different, ment. Because some of these
learning agile development to there are no general rules for items may have long lead times,
the challenges of executing promoting distributed agile it is wise to get them underway
distributed development could development among your staff as soon as possible.
be a recipe for disaster. members. If anything, this should
be the guiding principle: do not n High-availability, high-
underestimate the culture shock bandwidth network connec-
Openness to Off-Site Development
that distributed agile development tivity (often virtual private
As you will see in the sections that can create for your organization. networks). The network admin-
follow on best practices, imple- Plan your communication and istrators at each development
menting distributed agile develop- rollout carefully so that the on-site site must work out how to
ment can be a radical shift with team members will work to sup- provide fast and reliable two-
far-reaching cultural implications port distributed agile development way access between all the
for many organizations. You will and make it succeed. Seek out machines and resources the
see, for example, that one of the and develop advocates at every teams will need to share. This
fundamental requirements is fre- level of the organization and can be complicated when third-
quent rotation of staff between the make sure they are involved in party systems are involved.
off-site and on-site locations. Many the planning and in the first trial Setting this up at a sufficient
organizations are not set up to projects. Once you have built level usually takes approximately
support staff members of all up a few successes and people three times as long as you would
levels traveling or working off-site. become comfortable with the fact expect.
Additionally, organizations may that they will have “new roles” n Unlimited telephone connec-
be sensitive to sending business- rather than “no roles” in the world tivity. Any project team member
critical data off-site. They may of distributed agile development, should be able to pick up the
also not be comfortable providing momentum and support should phone and directly dial any other
access to confidential information start to swing your way. team member and talk for any
in a location that may not be
length of time. This is often an
subject to the same security Technical and Physical Infrastructure issue in offshore development
practices as those used at the
when phones are not enabled
home office. Since implementing As previously discussed, most
for international dialing.
distributed agile development will challenges of distributed devel-
likely involve partnering with an opment can be traced back to n High-quality speakerphones.
external vendor, organizations that decreased communication Often, groups of people will
traditionally have not employed bandwidth. Succeeding with need to collaborate via phone.

©2004 CUTTER CONSORTIUM VOL. 5, NO. 4

 8 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE

An investment in high-quality especially the client’s domain difficult given sheer size alone
(full duplex) speakerphones experts, must be able to stay and demand broad experience
will do wonders to facilitate ahead of the off-site developers. with distributed agile develop-
this communication. An alter- Additionally, QA testers need to ment throughout the team from
native is to set up a conference- be able to provide rapid turn- the outset.
call facility and give all project around so they do not become
n Project duration. Your project
team members the ability to a bottleneck in the development
must run long enough to allow
schedule calls. machine. You should consider this
the team to gel and evolve its
“throughput” factor when sizing
n Instant messaging (IM). working practices. It also needs
and staffing your on-site and off-
Experience has shown that to run long enough to generate
site teams.
distributed teams often come the metrics you can use to
to rely on the immediacy and Initial Efforts promote wider usage of dis-
“availability indicator” features tributed agile development.
of IM utilities. Some corporate To achieve the tantalizing bene- A project scheduled to run for
IT departments have policies fits of off-site development, it is three months is probably the
against the use of these tools. important to take a longer-term minimum you would want to
Alternatives to the big public view when developing an organi- choose for your initial efforts.
messaging clients (such as zational capability for distributed
agile development. You would n Project technologies. Agile
locally hosted messaging
do well to put on your strategic- development is significantly
servers) exist but take time
thinking hat when choosing the enabled by advanced program-
to procure and install.
first few pieces of work that you ming languages such as Java or
n Project space. Allocating a room do with off-site teams. As the .NET. While it is possible to apply
in both locations for the ad hoc capability and confidence of your agile practices to projects using
use of the distributed team can teams mature, you will be able to other tools or languages, custom
do wonders to facilitate commu- distribute a greater volume and software development with
nication and establish a team variety of work, but it is best to modern OO languages is the
spirit. This room is a place to start carefully. Consider each of best choice for distributed agile
post project status, artifacts, and the following project attributes in development.
pictures of the teams. It is also order to select something that will n Project complexity. As dis-
a place where the conference deliver an initial win: cussed above, distributed agile
phone is always plugged in and
development is well suited for
ready to host calls whenever n Project size (number of
highly complex, highly strategic
they become necessary. people). The optimal team
(and hence highly risky) proj-
size for your initial efforts at
ects. It can also provide some
Pipeline distributed agile development
productivity gains for simpler or
is around 10 to 15 in total
Once a distributed agile devel- more well-defined projects, but
(including all roles at both sites).
opment team gets rolling, it can the practices recommended
Smaller projects often don’t face
develop systems very quickly. here may be a bit over the top
the challenges that distributed
The team can only achieve peak for less complex development.
agile development is designed
levels of productivity if the cus- to address and aren’t worth the n Project visibility. If you hope
tomer is able to supply an ade- overhead required to set up the to use your initial efforts to
quate pipeline of work for the distributed team. Larger projects help you build the case for
off-site team. The on-site team, rapidly become more risky and greater usage of distributed

VOL. 5, NO. 4 www.cutter.com

EXECUTIVE REPORT 9

agile development in your orga- able to increase the complexity detailed requirement specs or
nization, you should choose a of work you choose to distribute. use cases.
project that people will notice. As the depth and breadth of
your project portfolio grow, your A distributed team presents a
n Project sponsorship. In addi-
distributed agile development challenge because the develop-
tion to successful execution, the
delivery model will mature and ers often are not colocated with
biggest factor in whether your
become second nature, and the customers, which makes car-
initial project leads to wider
the benefits you gain from it will rying out collaborative scoping
adoption of distributed agile
continue to increase. workshops more difficult. Also,
development is probably your
the lightweight documentation
business sponsor. Select a spon-
BEST PRACTICES FOR that agile projects rely on often
sor who will remain engaged in ESTIMATING DISTRIBUTED lacks sufficient detail to be useful
the project and who can easily AGILE DEVELOPMENT to people who were not present
realize measurable benefits from PROJECTS
for the initial conversations.
the approach. Once you deliver, A key difference between tradi-
your sponsor will become your tional and agile project execution The solution to the challenge of
champion throughout the wider is that estimation and planning is distributed agile project estima-
organization. viewed as a process that occurs tion lies in the effective use of
n Existing versus new develop- throughout the project rather than staff rotation and a bit of extra
ment. You may want to consider as an event that happens once at care in preparing documentation.
trying out distributed agile for the beginning and perhaps again Project team members from both
follow-on deliveries of existing, at specified intervals. Distributing sites should be physically present
nondistributed projects. It can be the development team does noth- at the sessions where high-level
easier to start up a new off-site ing to change the practices used scope items are broken down
team on an established code for estimating an agile project, but for developers to estimate.
base and architecture without there are some mechanics to con- Representatives from each site
the overhead of solving funda- sider concerning who does it and must be actively engaged in
mental questions on design and where it happens. the conversations that explore
technical approach. While it is the boundaries of each piece of
certainly possible to start from In agile development, it is impor- functionality.
scratch with distributed agile tant that the people responsible
development, doing so may not for doing the work are also Warning: don’t be tempted to
be the most prudent choice for responsible for estimating the skimp and use conference calls
your initial efforts. work. Another characteristic of in lieu of face-to-face meetings.
agile methods is not relying on Initial estimation happens at the
After successfully delivering your detailed documentation to start of a project during the critical
initial project, keep in mind that capture scope. Therefore agile period when credibility and rela-
the goals of future projects extend projects are usually scoped out tionships are established and
beyond simple execution. Each through collaborative workshops many of the rules of engagement
experience will allow your team between customers and develop- are laid down. This “human side”
to build and evolve the technical ers. In these workshops, items to of the estimation and planning
infrastructure, relationships, and be developed are documented process just doesn’t happen over
working practices that will enable in simple ways, such as in “story the telephone. Additionally, the
future success. As your teams cards” or “features” instead of in massive transfer of domain
continue to learn, you will be knowledge that happens through

©2004 CUTTER CONSORTIUM VOL. 5, NO. 4

 10 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE

intensive rapid-fire questioning project. Now you are ready to and willing to travel or temporarily
and answering is severely limited begin putting together the rest relocate if required. If you can
when you try to do it over the of your team and planning your find people who have existing
telephone. Successful transfer releases. relationships with the off-site
of domain knowledge to ambas- team members, this will allow
sadors from the off-site team is EFFECTIVE TEAM STRUCTURES you to start faster because those
one of the critical factors that FOR DISTRIBUTED AGILE existing relationships will shorten
DEVELOPMENT
will allow your remote team to the trust-building phase of project
successfully execute distributed One common model from the startup. If you are doing offshore
agile development. outsourcing world is to have an development, try to find people
on-site project manager managing who have experience living in or
Once an initial set of project a team of off-site developers. This working with other cultures or,
functionality has been captured, model just doesn’t fly for distrib- at a minimum, have traveled
the ambassadors can return to uted agile development. A new outside their home countries.
the remote site and guide the way of working requires new These people are likely to be
development team through initial roles and ways of interacting. more open to and interested in
project estimation. Anyone pres- forming relationships across cul-
ent for the initial discussions The following are some team tural boundaries, which will make
should be able to clarify points structures and characteristics that them more effective communi-
or answer questions as the devel- have proven effective across vari- cators and team members.
opers go about estimating. If ous distributed agile development
the ambassadors are unable to projects and may prove useful for The following roles and responsi-
answer a question, they should you. As you set up your delivery bilities often prove effective for
forward it to their friends at the team, you should set aside time the on-site team on a distributed
other site for discussion and to discuss and debate which agile development project. These
clarification. roles your team will choose to roles do not necessarily have a
use. Make sure everyone on the one-to-one mapping with individ-
After the initial set of features team understands and agrees uals; one person may, in some
has been estimated by the devel- with the roles before you start cases, have more than one role.
opment team, the list should be development.
widely circulated for review n Project manager. In addition to
(with the proviso that this is On-Site Team Roles traditional project management
only the initial list and is subject and Responsibilities responsibilities regarding project
to change). Customers and planning and progress tracking,
Choosing the right people for your
project team members should the project manager on a distrib-
distributed development teams
check the list for missing items uted agile development project
can mean the difference between
and probe any items that seem has prime responsibility for
success and failure. Search for
to carry unexpected estimates encouraging communication
advocates of distributed agile
(either much bigger or much between the on-site and off-site
development. Evaluate soft skills
smaller than anticipated). Once teams. He or she should help
(such as proactive communica-
everyone has had a chance to the team agree on communica-
tion and tolerance) with equal
review and comment and the tion patterns (discussed below)
or even greater importance than
estimates have been adjusted and constantly encourage on-site
pure technical ability. Choose
as necessary, you will have an members to communicate with
people who are receptive to
initial idea of the size of the the remote site until they get
adjusting their working practices

VOL. 5, NO. 4 www.cutter.com

EXECUTIVE REPORT 11

in the habit of talking many via testing and are responsible as possible. This team will work
times a day to their invisible for showcasing the results of iter- closely with the developer liai-
colleagues. The project manager ations to project stakeholders. To son or on-site development team
also has the responsibility for make distributed agile develop- to make sure any issues are
creating a “one-team” culture ment work, proxy customers communicated and addressed.
and ensuring that all the other should be willing to travel in per-
n Sponsor. The sponsor must be
recommended practices in this son to the remote site and (if the
positioned to receive communi-
report are applied at the right team is located in a different
cation and metrics about the
time in the right way. time zone) to shift their working
project and to experience key
hours on occasion to facilitate
n Truth. “The Truth” (aka the events in person. It is also bene-
real-time interaction with the
product owner) is the customer ficial for the sponsor to visit the
off-site team.
representative who is empow- remote site to meet the team
ered to act as the single point of n Developer liaison. Project cir- and form personal impressions
contact for all project stakehold- cumstances dictate whether you of the project members and their
ers. The Truth is responsible for should consider staffing a devel- working practices. Engaging the
prioritizing and managing project oper at the local site. It has sponsor will allow the sponsor to
scope. The Truth interfaces with proven particularly useful when form his or her own opinion of
the development team via the the off-site team is working on distributed agile development
backlog (the set of yet-to-be- only one part of a large project and communicate it to the wider
developed features). The Truth is that also involves an on-site enterprise.
the final authority on the priority development team. In this situa-
Off-Site Team Roles
of items in the backlog (although tion, the on-site developer can
and Responsibilities
he or she will collect feedback advocate for the off-site team
from a variety of business and and also brief the off-site team The ideal off-site development
technical sources prior to mak- on critical technical communica- team would be made up of on-
ing priority decisions). tion or goings-on at the local site. site team members who have
Even if development does not been relocated to another site.
n Proxy customer. For large teams
take place at both locations, Failing that probably unrealistic
or for teams where stakeholders
some on-site teams prefer to scenario, look for off-site teams
cannot be dedicated to the proj-
staff a developer so that they can that have at least some familiarity
ect full time, it is necessary to
communicate with the off-site with your organization or industry,
employ proxy customers in the
team at all levels. Another situa- since this will lessen the domain/
form of business analysts. Proxy
tion that may demand an on-site cultural learning curve at the start
customers are responsible for
developer is if the deployment/ of the project. In addition, build
keeping up to date with shifting
testing of the delivered system your off-site team with proactive
business priorities and clearly
requires technical support before communicators who are willing to
articulating requirements to the
the customer/business analyst adjust their working practices to
off-site development team. Proxy
can review and approve it. mesh well with the on-site team.
customers communicate con-
Make sure the off-site team is
stantly with the off-site team n On-site QA. The on-site QA
dedicated to your project and has
members, supporting them by team ensures that the code writ-
a common understanding of your
answering questions as they pro- ten by the off-site team works in
planned approach for project exe-
ceed through each development a local staging or user accep-
cution, including the willingness
iteration. Often, proxy customers tance testing environment that
approve delivered functionality duplicates production as closely

©2004 CUTTER CONSORTIUM VOL. 5, NO. 4

 12 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE

to send ambassadors to your site with the on-site analysts over will enable him or her to serve
and accept visitors at its location. time, they will come up to speed as a single point of contact on
surprisingly quickly and eventu- the state of the code. This con-
The following roles and responsi- ally will be quite able to stand centrated technical knowledge
bilities for the off-site team have in as on-site business domain can be useful at various points
proven effective for distributed experts for the majority of ques- in the project (such as at deploy-
agile development projects. As tions from developers. Having ment time when he or she is
with the local team, one project someone locally available to act likely to rotate to the local
member sometimes takes on as the customer in 80% of the deployment site to see the
multiple roles. circumstances will significantly application into production).
lower the communication barri-
n Iteration manager. The iteration n Off-site tech support. One way
ers and increase the productivity
manager at the remote site com- to increase the productivity of
of the off-site team. Additionally,
municates daily with the on-site agile development teams is to
off-site business analysts who
project manager to discuss the assign responsibility for the build
work on a project through sev-
risks, issues, and roadblocks that system and development envi-
eral releases often become
the teams face at each site. The ronment to a build and configu-
invaluable system experts when
iteration manager also collabo- ration master. On a distributed
on-site analysts move on or are
rates with his or her project agile development project, this
rotated to other projects.
manager counterpart to track person is also often responsible
and report project progress to n QA testers. Similar to business for the communications and sys-
sponsors. Additionally, the itera- analysis, building up a compe- tems infrastructure between the
tion manager has responsibilities tency for functional, regression, sites. Because outages in con-
similar to those of the on-site and system testing at the remote nectivity can bring progress to a
project manager regarding development site is a great way grinding halt, it is worthwhile to
encouraging communication, to accelerate distributed agile specifically allocate someone to
building a positive culture, and development. The ability to get own the technical infrastructure
fostering a one-team attitude. rapid feedback from the test of your distributed agile develop-
The overhead of overlapping team as soon as code is deliv- ment project.
project managers is more than ered, instead of waiting for feed-
n Single point of contact (SPOC).
made up for by the degree of back from remote testers, allows
To further enhance communica-
control, visibility, and assurance development teams to fix issues
tion, some teams have found it
that the off-site iteration man- very quickly and increases the
useful to appoint someone to
ager provides to a distributed quality of code eventually deliv-
be the single point of contact
agile development team. ered to the local team.
between the off-site and on-site
n Business analyst. Duplicating n Off-site tech lead. It is advisable teams. The SPOC agrees to do
business analysts at the local to have one off-site developer whatever he or she can to
and remote sites is a long-term who is specifically not assigned enable the teams to work
strategy that can pay major for work, but instead pair pro- together — from tracking down
dividends in distributed agile grams with all members of the a person who gets a phone call
development. Although off-site development team. Rotating to ensuring that people adhere
analysts will often be less experi- among the entire team will give to the communications practices
enced in the domain and project this person a big-picture view of the teams agreed to at the outset
goals at the outset, by working everything that is going on and of the project.

VOL. 5, NO. 4 www.cutter.com

EXECUTIVE REPORT 13

n Other specialists (as required). sheer effectiveness of communi- manager, a business analyst, and
Some projects require special- cation nothing beats on-site visits. a tech lead) arrive at the local site
ized types of domain or process According to Thomas Allen in his to help the customer articulate
knowledge. For example, a groundbreaking study on how and document the business
financial services application technology-based communities requirements during the early
may require someone who is a communicate, “Human beings phases of the project. A seeding
certified accountant to specify are the most effective carriers visit in the opposite direction may
requirements and test function- of information, and the best way also be planned for just prior to,
ality. Some applications need to to transfer information between and that carries through the con-
interface with legacy systems organizations or social systems is clusion of, the first development
with poorly documented data to physically transfer a human iteration. This visit would send
structures and interfaces. Some carrier” [1]. The most effective customer representatives (often
organizations have rigorous audit distributed agile development a project manager and business
or go-live processes to which the teams typically have about 20% of analyst) to the remote site to
off-site team must adhere. When team members working outside meet the team members and
confronting a special project of their base location at any point be available to them locally for
consideration, always remember in time. These ambassadors carry a short time.
that the more you can do to domain, project, and team infor-
locate or develop that knowl- mation between the development During the seeding visits, the team
edge remotely (through rotation, sites via regular visits. There are members should just plain work
recruitment, or training of staff two basic types of visits: seeding together. Developers should pair
located there), the more effec- visits and maintenance visits. program on code to reach a
tive your team will ultimately common understanding of coding
become. Seeding Visits
standards and application archi-
tecture. Business analysts should
Using some or all of these A seeding visit occurs the first also pair up on defining require-
roles on your project will pro- time people from the off-site team ments and communicating with
vide a solid foundation for dis- visit the local site or the first time project stakeholders. Even project
tributed agile development. But people from the local site visit the managers should pair to collabo-
to really make your teams per- remote location. Seeding visits ratively come up with project
form well, you will also need tend to last a bit longer (two plans and progress tracking and
some ambassadors. weeks are the minimum) than reporting mechanisms. By work-
maintenance visits to allow for ing together in person, everyone
Ambassadors sufficient team building and for will not only put names to faces
The basic challenge of distributed initial knowledge transfer to but also will get used to one
agile development is how to occur. In addition to project- another’s working styles and learn
transfer complex knowledge related activities, the project whom to go to with the various
about projects and processes managers from each site should questions or concerns that will
that is held in the heads of a ensure that the teams socialize arise over the remainder of the
group of people in one location at work or in the evenings if project.
into the heads of a group of peo- possible.
ple in another location. Proven Maintenance Visits
The first seeding visit usually
team structures and disciplined
occurs when members of the Once the seeding visits have been
communication practices will
off-site team (often an iteration completed, you should maintain
facilitate this exchange, but for

©2004 CUTTER CONSORTIUM VOL. 5, NO. 4

 14 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE

some level of rotation (in both some of the common benefits figure out how to not get in each
directions) throughout the course ascribed to distributed develop- other’s way.
of the project. These maintenance ment (specifically cost savings
visits can be of shorter duration when using offshore teams). A best practice for scaling up a
than the seeding visits. They serve While there is certainly overhead development effort (whether or
to keep relationships fresh and to associated with maintaining such not the effort is divided across
contribute to the flow of informa- high levels of team rotation, do multiple sites) is to split it into
tion between project sites. The not be tempted to skimp on this, independent components that
length of the project will deter- as it has been shown to be one of can be worked on separately.
mine the number of maintenance the single most important factors Getting this right can be quite
visits that will be required, but the for distributed agile development a complex chore that requires
longer you go without a visit from project success. Saving a few collaboration between project
either side, the greater risk you dollars doesn’t warrant putting managers, businesspeople, and
incur. A one-week visit in each the delivery of the entire project technical staff. Don’t be tempted
direction every six to eight weeks at risk. into splitting teams based on busi-
is probably the minimum work- ness function or resource location
able level of cross-pollination. Additionally, if you view distrib- alone, as divisions that are not
uted agile development as a represented in the structure of
Longer-Term Ambassadors long-term strategy for your devel- the underlying code are essen-
opment organization, you should tially arbitrary and will not allow
Sometimes you will find someone
view seeding visits as an invest- teams to work independently.
from the local site who is willing
ment for future projects. Once If you are considering multisite
(or even anxious) to relocate to
the team members have largely development efforts, consult with
the remote location for a longer
gotten to know one another, the your techies to help you choose
period of time. You should
seeding visits become less critical. which work is sent off-site. Be
encourage and support this if it
Over time, they can be replaced prepared to learn that you need to
is even remotely feasible, as the
by less frequent maintenance do some work to restructure the
constant presence of a local
visits. Seeding visits will then code so that it is more modular
team member at the remote site
be required only for big new proj- and cleanly separated.
will significantly boost communi-
ects or to introduce new team
cation and aid in knowledge
members to the organization. Another factor to consider when
transfer. Remember, however,
you are trying to decide which
that after too much time has Splitting Up the Work work to do off-site versus on-site
elapsed (six months is probably
is the complexity of the domain
the maximum), the local team In the simplest (and probably
and the need for on-site experts.
member will have become suffi- most common) case, distributed
If you are building software to run
ciently distanced from local agile development teams are
a nuclear power station and you
events such that he or she will structured so that business analy-
have only one nuclear engineer
begin to lose value as an ambas- sis occurs at the local site and
(who will only work from the
sador to the remote site. development occurs off-site.
local site), you should keep the
With a bit of thought, however,
Ambassadors and the “reactor monitoring” functionality
this simple case can be extended
Cost of Success on-site and send the “time and
to cover split development teams
expense reporting” modules to
It may strike you that this degree across multiple sites. The trick to
the off-site team.
of staff rotation is exceedingly successful distribution of teams
high and in fact may jeopardize working on common code is to

VOL. 5, NO. 4 www.cutter.com

EXECUTIVE REPORT 15

Access to external systems upon approach you choose for splitting n Communication plan. The
which your system is dependent up the work should account for most important tool in your
is critical for the development the location and availability of toolkit isn’t a technology at all;
team. Agile teams can work won- critical intellectual capital and it is a good old-fashioned plan.
ders with mocks and stubs (ways should be guided by the desire to The project managers (from
to quickly simulate external sys- reduce delivery risk and transfer both the local and remote sites)
tems), but at some point, you greater application knowledge should collaborate with one
need real connectivity to ensure among all participating teams. another and their local teams
everything will work when the to reach consensus on how
system goes live. If you cannot DISTRIBUTED AGILE the two sides will work together.
provide adequate access to DEVELOPMENT The plan should be quite
COMMUNICATION PATTERNS
dependent systems, you should detailed and include items
consider doing this portion of the Compensating for the reduction such as schedules of ambas-
development work on-site, where of communication that comes sador visits; project roles/
those systems are available. with distance is a critical enabler responsibilities (including spe-
of distributed agile development. cial communication-focused
A final item to consider is your In response to this need, the mar- roles such as the SPOC); contact
project release schedule and ket is teeming with high-priced, details for all team members;
any requirements for application technology-based offerings guar- chosen communication tech-
support. In one case, when faced anteed to improve off-site collab- nologies; instructions and eti-
with the need to deliver and sup- oration. Be wary of gizmos and quette guidelines for using the
port regular successive releases, gadgets that have novelty appeal chosen technologies; meeting
a distributed agile development but do little to enable and sustain schedules; plans for the shifting
team experimented with various basic communication on a con- of working hours to maximize
approaches but ultimately found it tinual basis. Build your com- real-time overlap (if required);
best for one team to do both the munications infrastructure out and details on project docu-
development and early-life sup- of simple, low-overhead tools ment repositories and shared
port of each release. In this way, that provide instant access machines. It is important to
the team could see its work all (such as telephones) instead ensure that everyone on the
the way through the go-live of complicated tools that take team (and anyone who joins
process and provide rapid time to configure and need to while the project is in flight) has
response to eliminate any bugs be scheduled in advance (such reviewed and agreed to follow
found in production. While this as videoconferencing). the communication plan. It is
team was busy supporting its advisable to schedule a special
production release, the other With so many options available, teleconference between the on-
team was building the next it can be difficult to decide which site and off-site teams while the
release. Once production was practices, tools, and technologies project is kicking off to discuss
stable, the on-site team went into are best for enabling distributed and agree on the communica-
deployment/support mode and agile development. The following tion plan. The plan should be
the off-site team took a cut of its have proven useful on numerous reviewed and adjusted as part
release to begin work on the next projects and form the beginnings of the retrospective that follows
release. of a communication-pattern each development iteration.
toolkit for distributed agile
Each project will have its own development: n Instant messaging. If you
unique drivers, but whatever observe colocated teams while

©2004 CUTTER CONSORTIUM VOL. 5, NO. 4

 16 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE

they work, you will notice that team names and numbers, thought into the general struc-
there is almost constant bub- information about project scope, ture it will use and appoint
bling conversation. While the and minutes from technical someone (the SPOC or project
conversation may not always be reviews) on the Wiki instead of manager) to monitor content
directly related to the work at communicating it via e-mail (or and reorganize or extend the
hand, it forms an important part not at all) does wonders to foster Wiki structure when necessary.
of the communication context of a common view of the project You should also specifically
the project that is largely lost by across multiple sites. It also has discuss Wiki etiquette and usage
distributing the teams. The tech- the added benefit of allowing the with the team with some fre-
nology that has proven most team to add new members and quency. Making the Wiki a desti-
effective for simulating team bring them up to speed quickly nation of choice for project team
chatter is IM. In addition to pro- as new members can get a great members is a great way to boost
viding an extremely low-cost deal of context by simply reading communication and foster a
means of communication, these the content on the Wiki. one-team feeling between physi-
tools provide the critical feature cally separate workgroups.
Additionally, many Wikis have
of visually showing online avail-
functionality that allows users n E-mail. Despite its ubiquitous
ability of teammates in remote
to subscribe to certain pages. use, e-mail is not a very helpful
locations. By ensuring that your
Subscribers will receive e-mails tool for distributed agile develop-
entire team has IM accounts
whenever those pages change. ment. E-mail conversations
and uses them appropriately
By asking everyone who is between two people are much
(that is, team members log out
involved with a particular piece less efficient and interactive
or change their status when
of work (a story card or feature) than a phone call or an IM chat:
they leave their desks), you can
to subscribe to the page that e-mails copied to large groups
create a virtual community that
represents that piece of work, are copied only to those who
massively increases the level of
you can create small virtual the original sender believed
communication between your
teams with essentially zero over- would be appropriate and often
off-site teams.
head. As long as all team mem- spawn fragmented or unclear
n Wikis. A Wiki (see http://wiki. bers agree to update the Wiki responses; project announce-
org/wiki.cgi?WhatIsWiki) is an whenever anything substantive ments sent via e-mail are not
easy-to-use technology that facil- changes, the entire virtual team available to people who join
itates the creation and editing of will remain updated with the lat- the project after the announce-
Web pages. By typing and edit- est developments on each piece ment was circulated; people
ing plain text, Wiki users can of work. They can follow up via are left off distribution lists —
post content that can be imme- IM or phone. A final thing to and the list of problems goes
diately viewed by everyone with mention about Wikis is that they on and on. It would be too
access to the Wiki. Medium to require a bit of management. extreme to ban e-mail on a
large distributed agile develop- Left on their own, they will distributed agile development
ment teams (with 10 or more evolve organically and may end project, but it would certainly be
people) have made great and up containing a mix of useful wise to impose strict etiquette
productive use of Wikis as both and relevant information as well on e-mail usage and try to
a lasting record of project com- as some poorly organized, hard- encourage team members to
munication and a daily collabo- to-find, or out-of-date communi- switch to some of the other
ration tool. Posting important cation. If you decide to use a communication tools described
project information (such as Wiki, you should put some here. Some teams have found it

VOL. 5, NO. 4 www.cutter.com

EXECUTIVE REPORT 17

useful to perform a daily review usually takes a one-on-one form. need to find a way to include
of outstanding unanswered Conference calls, which are them in your distributed devel-
e-mails as part of their regular quite useful for some activities opment practices. Some teams
status meetings (a day spent in agile development projects find it effective to hold daily
waiting for an answer to an (such as iteration kickoff meet- virtual standups during a confer-
e-mail is often a day completely ings or “virtual standups”), are a ence call, which is attended by
wasted). Because people have very different type of communi- all members from all locations.
become so accustomed to using cation pattern. Do not make the Other teams hold local standups
it, the shift away from e-mail is a mistake of thinking that every- and appoint someone to publish
difficult one and will probably one on the team will do the right brief notes (on the wiki). That
require significant encourage- thing to make conference calls person is also responsible for
ment and support from project successful. Many distributed following up with the other
managers in both locations. agile development teams have team on any cross-location
given specific responsibility to issues. Some teams use a hybrid
n Phone calls. Despite the avail-
someone on each side of the approach, implementing one or
ability of many text-based
conference call (often the SPOC) two virtual standups a week with
alternatives, distributed agile
to moderate and maximize the on-site standups taking place on
development teams should con-
effectiveness of the conversa- days when no virtual standup is
tinue to include phone calls in
tion. This person watches body scheduled.
their communication toolkit.
language at his or her location
Regular phone calls serve to
and ensures that everyone who PROJECT STEERING
maintain relationships in ways AND TRACKING
has something to add has a
IM or Wikis never can, as voices
chance to have their say. This The iterative nature of agile devel-
and conversations carry much
person also asks for clarification opment directly addresses many
more context than plain words
when it is apparent that some- of the project tracking and visibil-
ever will. Teams should be made
thing is unclear. ity issues posed by distributed
aware and taught to think about
issues that are appropriate for n Standup meetings. A distin- development. Most of the project
phone and issues where other guishing characteristic of many
tracking and steering practices of
channels are sufficient. Ques- agile development teams is their
agile development apply directly
tions of fact or questions with daily standup meetings. These
with very little modification other
binary answers are fine for IM meetings are designed to be
than making sure to include
chats while questions of opinion short and to air any issues facing
the right people in the various
or questions seeking context are the team. They also allow people
processes, regardless of where
best left for the phone. If teams to coordinate efforts and syn-
they happen to sit.
are separated by many time chronize with one another
Steering
zones, it is important to agree on before starting the workday.
some rules for phone contacts at Finally, they provide a bit of a To rightfully be termed agile
the outset and for both sides to project pulse and publicize prob- development, technical teams
exercise flexibility in being con- lems and risks early so they can must collaborate with their
tacted outside of standard work- be dealt with or communicated customers on a regular basis to
ing hours. more widely instead of coming choose what to work on next.
as a surprise several weeks later. The goal of this collaboration is
Additionally, although most
These meetings are essential to to move project planning away
people talk on the phone nearly
agile development, and you from being a point-in-time event
every day, the conversation

©2004 CUTTER CONSORTIUM VOL. 5, NO. 4

 18 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE

and toward more of a continuous out. After the first couple of steer- the project managers at all, but
balancing act over the course of ing sessions, the team should be rather of the team itself. Because
the project. On a normal agile able to lay out a rough release agile teams incrementally build
development project, project plan that provides a projection production-ready code, they have
steering takes a multitude of of the course of development the unique ability to demonstrate
factors as inputs, including shifting over at least a few months. At this completeness along the way. After
business priorities, progress to time, the off-site members can every development iteration, it is
date, technical risk, schedules, return to their home base and critical to go through the exercise
dates, and availability of key participate in future steering ses- of showcasing those parts of the
resources. On a distributed agile sions via phone, returning for per- system that have been completed
development project, the only real sonal appearances only if major at the remote site to the local cus-
difference is that there may be changes occur. tomers and stakeholders. These
several other factors to consider, showcases not only serve to build
such as the following: Tracking trust and confidence in distributed
Agile development provides agile development but also offer
n Does the off-site team have
the capability to track projects highly effective forums for collect-
connectivity to required third-
at an extremely detailed level. ing feedback on the system under
party systems as is necessary
This detailed tracking serves to construction and feeding that
to begin developing a certain
address many fears about distrib- information into the project-
set of components?
uted development that are based steering process (and back to
n Should we postpone a particu- simply on the inability to see the the off-site team).
larly tricky or new area of the team working.
system until the next scheduled You may find that there is a lot of
ambassador visit to the off-site As mentioned above, the on-site overhead involved in preparing
location? and off-site project managers for and executing iteration show-
should agree on a framework for cases, but by being disciplined
n What will the availability of the about maintaining a regular “plan,
project tracking at the outset. At a
off-site team be during this itera- build, showcase, replan” cycle,
minimum, this framework needs
tion (may be different if the off- you essentially incrementally
to include initial estimates for
site location has holidays or achieve system sign-off from your
each unit of work, refined esti-
festivals that are not synchro- customers and stakeholders. By
mates done at the time the work
nized with the on-site team)? the time you deliver the final sys-
is started, and actual time spent
to complete the work. Collecting tem, it has essentially been
Additionally, it is strongly sug-
and analyzing these three num- accepted. If for some reason your
gested that members (ideally a
bers will greatly enhance the customers are unwilling to review
project manager, technical lead,
project’s ability to measure its regular showcases, you should
and business analyst) from the
development capacity (as well as find a way to simulate this by
off-site development team are
its skill at estimating). It will high- holding internal showcases every
present in person for the first few
light problems quickly and allow couple of weeks. That way, by
project-steering sessions. During
for projections going forward that the time your customers are ready
these initial sessions, it becomes
are vital as inputs into project- to have a look, the process of
very clear which stakeholders are
steering activities. deploying and showing off the
advocates for which priorities and
system will be silky smooth and
how the various customer repre-
The remainder of the burden of all that much more impressive.
sentatives see the project playing
tracking isn’t the responsibility of

VOL. 5, NO. 4 www.cutter.com

EXECUTIVE REPORT 19

DEVELOPMENT PRACTICES teams must constantly be on wanted to touch any code devel-
AND TOOLS the lookout for ways to reduce oped at the other site.
The various incarnations of agile ambiguity in their communica-
n Agile configuration manage-
development recommend a tion between sites. Without a
ment. Veterans of the software
plethora of development practices doubt, test cases are the clearest
development game have proba-
designed to enable and facilitate way to describe requirements
bly all had someone tell them
agile ways of working. Of all the and to document the code that
(often wryly) when faced with
development practices to choose implements those requirements.
a broken system that “it works
from, the following are the four Communicating via test cases
on my machine!” The fact is
most critical in distributed agile (both between business analysts
that as systems increase in com-
development projects: and developers and among
plexity from simple executables
developers working on the sys-
to complex, multitier enterprise
n Continuous integration. If prac- tem) is an agile best practice
systems that integrate with mul-
ticed with discipline, continuous that is even more beneficial in
tiple other systems, the constant
integration (the process by which a distributed agile development
deployment demanded by agile
developers integrate their code project environment.
development becomes an enor-
and build the entire system
n Collective code ownership. mous challenge. When you
whenever they have made
Teams practicing collective code add the fact that development
changes) should reduce or even
ownership allow any developer will be going on in two locations
eliminate on-site deployment
to change any piece of code that are often quite different in
risk at the end of a distributed
with impunity — providing all terms of technical infrastructure,
agile development project. The
the test suites pass following the you begin to appreciate why
value of continuous integration
change. This practice encour- successful distributed agile
is that it solves small integration
ages developers to write code development teams often
headaches immediately instead
with a high degree of test cov- employ someone specifically
of trying to solve huge ones at
erage (to ensure it won’t be to address this problem.
the end. The key is to make sure
broken by someone down the Configuration problems can
that the automated build system
line) and greatly improves the bring the critical rapid feedback
builds quickly and then tests and
internal quality of the system. cycles of distributed agile devel-
deploys into an environment that
It also allows teams of develop- opment to a grinding halt. To
simulates the production envi-
ers who are not colocated mitigate this risk, you must have
ronment to the highest degree
(and who may never have met) someone on the project whose
possible. This practice is so criti-
to trust one another enough job is to understand and manage
cal that on a project of any size
to work on the same code. the development, test, and
(i.e., more than 10 developers)
Distributed agile development deployment environments at
or with concurrent development
between multiple sites would all project sites.
in multiple sites, it is often useful
not be possible without col-
to make the construction and
lective code ownership — DEPLOYMENT AND SUPPORT
maintenance of the build system
especially in light of how
a distinct role so that it gets the Depending on how the project
development teams that are
attention it deserves. has been progressing, the deploy-
separated by many time zones
ment phase may turn out to be
n Test-driven development. would otherwise have to wait a
somewhat of a nonevent. If the
Faced with reduced communi- day for their off-site teammates
result of each iteration has been
cation bandwidth, distributed to wake up every time they
released into production, then

©2004 CUTTER CONSORTIUM VOL. 5, NO. 4

 20 SOURCING AND VENDOR RELATIONSHIPS ADVISORY SERVICE

when the iterations end, there development to support isn’t These culture- and morale-related
are no additional special activities really much different from transi- considerations are not just nice
required to get the system live. tioning any other system except to have; they can make the differ-
However, if you were unable to that your system should have ence between success and failure
fully practice continuous deploy- cleaner, more fully tested code on a distributed agile develop-
ment, you may still need to install and will come with an automated ment project. Making distributed
the system in the production envi- build and testing system that agile development work requires
ronment and perhaps go through should prove very useful to the people to change their working
some formal audit or acceptance support organization. practices, to travel away from
testing prior to going live. home, and sometimes to come in
CULTURE AND MORALE to work early or stay late to maxi-
This final part of the project is mize overlap with a remote team.
an excellent time to schedule In addition to all the tangible prac-
Things do go wrong, and people
a visit to the local site by the tices discussed above, one thing
can feel powerless because of
ambassador at the remote site that the most successful distrib-
their inability to get involved in
so that the people who built and uted agile development teams
person. Those who are having
configured the system are also have in common is a culture of —
fun working together on a happy
available in real time to get it for lack of a better word — fun.
team will be willing to give the
installed and launched. The peo- Although the decreased personal
extra effort that is required to
ple who should visit are probably interaction can negatively impact
make distributed agile develop-
the configuration manager and morale, distributed agile develop-
ment succeed.
one or more of the technical staff, ment also presents team mem-
although you will need to con- bers with opportunities to travel
CONCLUSION
sider your specific project situa- and to work with a new group of
tion and plan the participation people on solving hard problems. It should now be clear that distrib-
accordingly. uted agile development has the
The best distributed agile develop- potential to help your organization
Once the system is live, you will ment project managers work hard realize some powerful benefits. It
arrange for some period of transi- to foster a one-team feeling, often should also be clear that you must
tion from distributed agile devel- by posting pictures of the off-site proceed with care and work hard
opment into live support. As a team and encouraging the sharing at planning and executing a port-
general rule, teams that are built of stories across locations. They folio of projects to build up your
for distributed agile development also make sure outbound ambas- distributed agile development
are not well suited to the chal- sadors are loaded up with gifts for competency over a period of
lenges and duties of system sup- the off-site team and look after the several years. By applying the
port. These are very different jobs inbound ambassadors that visit lessons learned and best practices
that require very different skill their own site. They help establish described above, you can lever-
sets. Depending on your strategy, common practices and do not age the hard work of those who
you should select a support allow finger-pointing when some- have gone before you and signifi-
provider and work to transition thing goes wrong. Finally, they cantly increase your chances of
the knowledge from the develop- actively encourage communica- succeeding with distributed agile
ment team to the support team. tion until the teams have bonded development. It will still be hard
Transitioning a system that is enough that they do not need work and require fortitude and
developed using distributed agile encouraging. determination, but take encour-
agement in the knowledge that it

VOL. 5, NO. 4 www.cutter.com

EXECUTIVE REPORT 21

can indeed be done. As you and ABOUT THE AUTHOR

your teams encounter and eventu-
Matthew Simons is a project
ally overcome challenges that
manager and distributed agile
aren’t even addressed here, you
development advocate for
will contribute to the art and
ThoughtWorks. For most of the
science that is distributed agile
past 10 years, he has managed
development, and you will con-
large teams that are using
tinue to change the way we live
advanced technologies to
and work. Good luck!
deliver strategic enterprise
systems. He has particular
REFERENCES
expertise in adapting agile devel-
1. Allen, Thomas J. Managing opment approaches to large
the Flow of Technology. 6th ed. and/or distributed projects.
MIT Press, 1993. Mr. Simons has been involved
with ThoughtWorks’s distributed
2. Andriole, Steve. “Be Careful agile development teams from
Out There.” Cutter Consortium the earliest days. For the first year
Business Technology Trends of operations of TW-India, he
and Impacts E-Mail Advisor, was based out of Bangalore and
25 September 2003. was primarily focused on how
to extend the ThoughtWorks
3. Mah, Michael. “Offshore agile development approach to
Outsourcing: A Tale of Two Bids.” support offshore development.
Cutter Consortium Business Mr. Simons is currently based in
Technology Trends and Impacts London, where he continues
E-Mail Advisor, 21 August 2003. to help extend and proliferate
ThoughtWorks’ distributed agile
4. Simons, Matthew.
development model. His most
“Internationally Agile.”
recent project used a 150-person
InformIT. Pearson Education,
development team distributed
15 March 2002.
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

About the Practice

Sourcing and Vendor Senior Consultant

Team
Relationships Practice Each of the individuals on the Cutter
Consortium Sourcing and Vendor Relationships
Cutter Consortium’s Sourcing and Vendor Relationships Practice provides companies
team is an expert in outsourcing, offering the
with objective information, advice, and data that enable them to make sense of all
expertise that comes from decades of hands-
sourcing options. Organizations get advice on how to develop, implement, and
on, real-world experience. The team includes:
manage a sourcing strategy that frees up scarce and expensive resources so they
can concentrate on development projects that are crucial to gaining or maintaining • Eric Buel
a competitive edge. • Bill Curtis
• Carole Edrich
The subscription-based component of this service addresses issues such as
• Michael J. Epner
making the outsourcing decision, structuring outsourcing contracts, relationship
• Danny Ertel
management, offshore outsourcing, service levels, and other essentials.
• Ian Hayes
Personalized consulting help is available to enable you to manage sourcing projects • David Herron
and relationships effectively, negotiate contracts, develop and implement a metrics • Jonathan Hughes
program, write enforceable service-level agreements, create appropriate pricing • Wendell Jones
schemes, choose an application service provider, and more. • Stuart Kliman
• Michael C. Mah
Products and Services Available from the Sourcing and Vendor • Marty McCaffrey
Relationships Practice • Eugene G. McGuire
• The Sourcing and Vendor Relationships Advisory Service • Bart Perkins
• Consulting • William Ulrich
• Inhouse Workshops • William A. Zucker
• Mentoring
• Research Reports

Other Cutter Consortium Practices

Cutter Consortium aligns its products and services into the nine practice areas
below. 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