distributed agile article ms

24
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. Sourcing and Vendor Relationships Vol. 5, No. 4

Upload: dskumar78

Post on 19-Nov-2014

125 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Distributed Agile Article MS

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

Page 2: Distributed Agile Article MS

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

Page 3: Distributed Agile Article MS

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)

Page 4: Distributed Agile Article MS

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.

Page 5: Distributed Agile Article MS

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.

Page 6: Distributed Agile Article MS

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.

Page 7: Distributed Agile Article MS

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.

Page 8: Distributed Agile Article MS

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.

Page 9: Distributed Agile Article MS

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

Page 10: Distributed Agile Article MS

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

Page 11: Distributed Agile Article MS

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

Page 12: Distributed Agile Article MS

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

Page 13: Distributed Agile Article MS

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

Page 14: Distributed Agile Article MS

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

Page 15: Distributed Agile Article MS

� 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

Page 16: Distributed Agile Article MS

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

Page 17: Distributed Agile Article MS

©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

Page 18: Distributed Agile Article MS

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

Page 19: Distributed Agile Article MS

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

Page 20: Distributed Agile Article MS

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

Page 21: Distributed Agile Article MS

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

Page 22: Distributed Agile Article MS

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

Page 23: Distributed Agile Article MS

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

Page 24: Distributed Agile Article MS

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