Distributed Agile Teams and

Alternative Contractual Forms

- What Works Best?

Greg Hutchings

August 6, 2008

Greg.Hutchings@valtech.fr
Distributed Agile Teams and Contractual Forms

About the author…

Greg Hutchings
I live in Paris and work for Valtech,
proposing, negotiating, managing and
living with large distributed agile projects.

I travel often to Bangalore and within

Europe. I am originally from the SF Bay
area, where I was a client partner for
ThoughtWorks, after spending years in
software product development.

I’ve been involved with software teams

since the early 80’s, and have been using
Agile and XP practices with teams formally
since 2003 and informally since the early
90’s.

2
Session outline

Distributed Agile Teams and Alternative Contractual Forms – What works best?

Building and supporting contracts to engage large distributed Agile teams (30 min)

In-depth Case Studies (30 min)

Fixed-bid, T&M and pay for production contract alternatives (20 min)

Discussion (10 min)

3
Building and supporting contracts

Importance of the proposal

Selecting and defining methods

Types and structures of agile contracts

Planning Releases, Iterations and Communication

Client and Vendor Roles and Responsabilities

Team organisation and roles

Estimating functional and non-functional scope

Alternative units for measuring software production

Acceptance testing

Warranties / Reversability

4
Distributed Agile proposal process

Interest in doing distributed agile development is usually related to cost savings, or

time to market and enhanced capacity, and may focus on rates

Most new large company clients I talk to have already have had an offshore
experience, often not very positive or with mixed results, and have some fear

Quality, productivity, schedule and budget control are all key issues for a client

Methodology, included Agile, is often of increased importance for a client when

working with an offshore vendor, and can help to address fears and concerns

It is better to introduce offshore and onshore delivery staff early with a

collaborative approach, and to absolutely involve the delivery team in estimates
and client relationship building.

After an understanding of the client’s needs is obtained – high level scope, time
frame and budget, and specific constraints, a proposal is prepared

After the proposal is presented, reviewed, revised and agreed in concept, the
contractual development process begins

5
Selecting and defining methods in the contract

In our proposals and contracts, we discuss Agile, Scrum, TDD, CI, and the
importance of collaboration; we incorporate lessons learned from prior projects

Part of the Vendor role of developing business and ultimately writing and signing a
contract is to understand the key drivers, concerns and constraints of the client,
and another is to propose and coach success factors (agile adoption patterns)

I discuss on-shore and off-shore roles, those that might be staffed by the Client and
by the Vendor – with enablement / delivery trade-offs and relative priority

A key role to define at the client is an internal distributed agile champion – who
becomes elemental to the contract negotiation and project execution, and who
often becomes the Scrum Product Owner. This person should be able to travel.

The relative importance of knowledge transfer, cost, time-to-market and scope are
important to clarify, allocate resources to and define acceptance of in the contract

It is important for the proposal and then the contract to provide the team with time
to ramp-up, self-organize, perform an Iteration 0 and develop and validate sufficient
requirements / stories to begin Iteration 1

6
Types and structures of typical agile contracts

Types and structures

 Time and materials
 Fixed bid: could be fixed capacity and/or fixed scope and/or fixed schedule
 Fixed cost per unit of work (Story point, UCP, Function point, etc.)

Structures
 Pre-contract: verbal understanding, “hand shake”, email, letter of intent
 Simple contract for professional services – no scope defined, rates and budget
 Simple contract for software development – scope defined, total cost, timing
assumptions defined with terms and conditions to protect vendor and client
 Hybrid contract – often a phase 1 (T&M or fixed bid) to define release backlog and
high level estimates, assumptions and to produce a phase 2 fixed bid for delivery
 Fixed cost per unit of work. E.G. Valtech Software on Demand

Building the contract collaboratively

 As with software, avoiding BDUF for contracts is a good practice. Iterate!
 MSA with SOWs is preferable if a longer term relationship is anticipated
 Maybe be best to meet and develop contract (from a template) together
7
Planning Releases, Iterations and Communication

In addition to the type and structure, the contract will need to define the term of the
engagement; it is useful to describe, plan for and gain commitment to events

Although we probably don’t have enough precision in our estimates, yet, the client
probably does have a budget in mind. After all, they are talking to you as a vendor
or IT team which likely follows a budget exercise of the previous year.

Based on a very rough sense of the work to be done, a capacity plan with a number
of iterations and a ramp-up in team size can be used to model what level of effort
the budget might cover.

Especially for distributed agile projects, in the contractual discussion it is very

useful to review a release plan of a number of iterations, and to discuss the need
for face to face communication at iteration boundaries. For distributed projects we
often use a Sprint of 4 weeks, in part due to higher travel costs.

A product or release backlog (high level requirements) is often shown as an exhibit.

If the contract form is fixed bid, fixed scope, in order to protect client and vendor
either estimates involving development spikes on representative requirements or
terms that permit substitution of or variance in scope are important.

8
 Key events in a distributed agile Iteration

Week 1 Week 2
Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10

Iteration Requirements

Est Workshop
Development Development
Planning Meeting Workshop
Design
Workshop
Development of test
Deployment of Development of test cases
cases
previous iteration

Prep Build Build Build Build Build Build

Support Deployment UAT UAT

Week 3 Week 4 (Week -1)

Day 11 Day 12 Day 13 Day 14 Day 15 Day 16 Day 17 Day 18 Day 19 Day 20

Development Next Iteration Planning

Retro-
Demo
spective
Testing Testing Prior Iteration

Build Build Build Build Build Build Build Build Build Package Package
Preparation of UAT Env Validate Env

During a distributed agile contract negotiation, I discuss the events in a sprint

and which should involve face to face discussion.
9
 Distributed Agile Events – roles and conditions

Meeting / Facilitating Session

Session Type Role Attendees Locale Length Pre-Condition Post-Condition Inputs Needed for the Session Session Output

Input Responsible Role Output Responsible Role

A backlog of high
High level
level requirements
functional and
Release EM, PO, FM, Project is initiated, is prioritized to Release Backlog,
technical PO, BAs, Arch,
Planning EM PM, Arch, all France 1 day key participants permit planning of known definition of EM, PM, PO
requirements, EM coaching
Meeting BAs, Tech Lead are on board the iterations, project success
schedule and
overall release and
budget contraints
major milestones

Enough
information is Previous iteration
PO, FM, PM, Demo of previous available for scope "Done"
Iteration PO, BAs, Arch, High level
PM Arch, all BAs, France 20 days iteration is finalizing priorities status for each PM, FM, BAs
Preparation EM coaching scenarios
Tech Lead complete for the iteration scenario taken up
and agreement to
scope of iteration.
Enough
Proritized
information is
Iteration PO, EM, FM, requirement
High level available for High level
Planning PM PM, Arch, BAs, India 4 Hours FM, BAs backlog with BA + Customer
scenarios preparing scenarios
Meeting Tech Lead, Devs desired scope for
Requirements
the iteration.
Overview

Above is a sample description of some of the events in a distributed agile project.

By discussing in the proposal and engaging via the contract the commitment of client
and vendor to communicate regularly face to face, the budget for travel and the
commitment of key staff to the project can be planned.
10
Client and Vendor Roles and Responsibilities

An agile contract should clearly state what is expected of each party, and of
specific roles: who must do what, when, and sometimes how and where.

Normally the client must approve budget, approve requirements and approve
acceptance of delivered software, at a minimum, but it is nearly critical that they
participate in release and iteration planning, retrospectives and as product owner
using the Scrum role metaphor, be available daily, even at a distance, to clarify
requirements.

These responsabilities need to be time-boxed, and particularly in the case of a fixed

bid agreement, it is advisable and mutually beneficial to define the consequences
of being late.

These may include transferring risk back from vendor to client (e.g. convert to time
and materials, assume capacity was consumed but wasted, etc.) or from client to
vendor (e.g. a quality or scope debt was incurred by the vendor for not delivering)

In this section of a contract an escalation procedure should also be defined so that

the team does not become blocked prior to, during or after an iteration

Executive sponsors / stakeholders should be defined, in the contract or exhibit.

11
Roles and Organization Chart
Executive
Executive Steering
SteeringCommittee
Committee
Transversal
Transversal Committee
Committee
Operational
Operational Committee
Committee

Client (typical)
Product Owner Program Director
(Owns Initiative budget) France

Agile Offshore Coach

Project Manager France

Feature Manager
Domain experts France

Technical Lead Tech Lead / CSM

India

Senior Developers
Development Team

Release Management

Infrastructure

The larger the Client’s delivery involvement is, the less likely that the
terms of a distributed agile contract can be fixed bid, and the more
likely that enablement will be the top priority. 12
Estimating functional and non-functional scope

In all Agile projects, estimation is very important, and is necessary to plan releases and
iterations

Estimation units of a team often need to be translated into terms meaningful to the client

The client’s units of measure vary, from story points, ideal days, actual days, use case points,
function points, use cases, stories, large functional specifications, “a system sufficient to
replace the existing”, etc.

Contractually, if the contract is not time and materials, something other than time must be
delivered and measurable in order to justify payment, and for distributed agile contracts the
more easily and exactly the units can be measured and verified, the more clear communication
will be and generally the better the relationship

Clearly, it is very important to define “What is done” with acceptance tests and to include these
with requirements when doing detailed estimates

Others in this conference, including Mike Cohn in his session yesterday, have treated this
subject in great detail, so I will stay high level

The main point to make for distributed agile contracts is that you should define the unit of
measure in a manner that is clearly described and understood in the agreement, and can be
managed, with incremental acceptance. We have found Use Cases, UCP and function points to
be useful measures in this regard.

Teams often forget to include estimates in what ever units they are using for non-functional
requirements in fixed bid contracts – or sometimes, even to adequately define these
requirements.

13
Acceptance Testing

Agile contracts or their associated proposals should define what acceptance tests are, who
writes them, validates them, performs them, where, and when.

I often contractually suggest that the client participate in the definition of the acceptance tests
during the preparation of stories or use cases, and that they be discussed and validated
consensually in the requirements workshop

Acceptance of the delivery of an iteration is specified contractually to be associated with the
passage of the scope’s related acceptance tests, and in a fixed bid contract or a pay for
production contract, this acceptance is often associated with the release of a payment.

A KPI I recommend tracking is the % of functional tests automated, and I prefer to state in the
contract that feature delivery acceptance is assumed within a short period of time (eg 10 days) if
automated acceptance tests pass and there is no indication by the client or team of other
reasons not to accept the delivery

UAT is usually, at least with our clients, a separate phase of time that includes some additional
risk in terms of time and budget, but which is absolutely necessary. We invite client
representatives to iteration end demos and provide access to the project dashboard to reduce
this risk.

Customer visits to the offshore development site can be coordinated with demos and
acceptance testing of the most recent iteration’s delivery if planned appropriately, and this
practice greatly increases the offshore team’s satisfaction level and the client’s confidence and
trust in the offshore team.

In distributed agile projects, the importance of comprehensive and automated functional and
non-functional testing is critically important to serve as an objective indicator of project quality
and progress. Tools such as Rally Dev, Version 1 and others provide information radiators to
keep client and vendor in sync, and their usage is often stipulated in our contracts.
14
Warranties and Reversability

Most vendor attorneys generally advise limiting the warranties provided by the
vendor in many important ways

However, clients wish to be reassured that the vendor is engaged and committed
and aligned with the client’s business needs.

These terms vary from country to country, and I have found warranties to be
stronger in Europe than in the US in many cases. A common European standard is
to guarantee that a custom app will be free of major or blocking defects for a period
of 3 months after delivery to production, and most often provides correction
services at no charge. There may be penalty clauses for the vendor in the event of
major defects that require liability insurance to be purchased.

Reversability clauses deal with the event that the Client decides to switch vendors
or in-source the application’s continued development or maintenance, by providing
for a knowledge transfer process supported by the vendor for a certain period and
with specific measures for completeness.

Reversability clauses in a distributed agile team may require travel and/or

translation services, so an appropriate budget should be defined and costed into
the contract at the time of its negociation.

15
Case Studies

Case 1 : Employment agency application

 Distributed Agile project
 Fixed bid converts to bid per iteration
 Organisation and contract evolves and adapts

Case 2 : eBusiness Catalog, eCommerce and POS

Agile contract evolution in large distributed agile
program
 Large distributed agile project
 Several interesting contractual forms
 Organisation also evolves and adapts, learning together

16
 Case 1 : Employment agency application
Fixed bid -> bid per iteration

Refactoring and port of a large temporary employment agency application

 Rewrite in Java of a large Forte application, identical feature set and human interface
 The distributed agile project was staffed with a relatively offshore team and smaller local team
 Project size : 6 500 person days
 Duration : 24 months
 Application to manage employment agency candidates (1000 agencies with > 5000 users)

Fixed Bid Bid per iteration / incremental acceptance UAT

June 2005 December 2005 June 2007 August 2007

Re-Negotiation

Acceptance criteria : Quality metrics

Basis for invoicing : Acceptance of the iteration

Project Results :
 Exceeded initial fixed bid budget by 3 iterations
 2% defects beginning at the UAT (14000 functional test cases)
 Piloted September 2007 and went to production December 2007
17
Case 1: Employment Agency Application

How did this contract affect the team?

The initial contract was bid for a fixed fee, with fixed scope, and though a desired time frame
was agreed, there was no penalty for late delivery

The onshore team was initially the sole point of contact with the client. They developed close
rapport, negotiated the contract, provided estimates and built the requirements and
architecture. The client wished to communicate in french and did not have face to face contact
with the offshore team.

The offshore team was not involved in validating the onshore architect’s estimates, and did not
feel committed to the estimates, the contract or to the client

Strained relations developed between the onshore and offshore teams, internally, and
eventually with the client as quality expectations were not met. The client seemed
unreasonable.

A “blow-up” occurred when the quality level was consistently not acceptable.

The parties met, including representatives from offshore, addressed some technical issues
related to human interface requirements, and renegotiated the budget and contract to permit re-
estimation and budget fixing by iteration

The now more collaborative and integrated team went on to successfully deliver the application.

18
 Case 2 : eBusiness Catalog, eCommerce and POS
Agile contract evolution in large distributed agile program

Project was to implement an integrated multi-channel eCommerce solution with a new POS in 220 stores
 Progressively replace features of 7 legacy apps with a custom Java / WebSphere Commerce Server solution
 Distributed agile program began in France and shifted over time to large distributed team
 Project size : 15 000 person days. Duration: 3 years
 4 contractual modes :
• V1.C – Product Catalog, fixed bid, fixed scope – but no time boxing and 8 month delay!
• V1.S - Sales (Point of sale) with integrated Catalog and eCommerce site – T & M with bonus /penalty.
• V2 - Evolved Catalog and Sales for full production roll out – pay per productivity with velocity assumption
• V3 - Time and materials support agreement, capped budget, prioritized backlog

V1.C

Fixed bid duo-shore « agile » Time and materials with KPI – strong offshore T&M UAT

Jan 2005 December 2005 June 2006 Dec. 2006

POC
V1.S
Negotiation

Negotiation
• Change project management, France -> India
• Rebalance French/India team and roles • V1.C delivered
• Create direct India/customer communication • V1.S negotiated, POC begun
• Quality and productivity indicators put in place • Revamped process, ramped team19
 Case 2 : eBusiness Catalog, eCommerce and POS
Agile Contract Evolution…

V1.S V2 V3

BIG ramp up, T&M +/- Pay per UCP, Rising Velocity assumption T & M with a cap

Janvier 2007 June 2007 June 2008

Negotiation Negotiation Negotiation

• T & M with + / - • Fine-tuned process for integration

• With trust established, returned to a
• Established PD budget • Established UCP cost and budget
simple time and materials mode for
• Productivity & Quality • Forecast velocity and acceleration
support of deployment and production

20
Case 2 : eBusiness Catalog, eCommerce and POS
Agile Contract Evolution…

V1.S
the T&M contract with bonus / penalty clause was in response to client demand for fixed bid and
vendor concern about estimation risk and acceptance speed.

This contract form had an effect on the team of very strong motivation to deliver completed use cases
(use cases which passed their functional acceptance tests), but sustainable pace was not maintained.
Morale was none-the-less very high.

During this period, January – March 2007, the team ramped up from 18 to 90+ members, from 1 to 4
delivery locations.

The team earned the 5% productivity bonus by delivering 99,5% of Use Cases, but had a 2.5% penalty for
quality based on integration tests

The planned 2.5 month UAT and Beta test period was extended to 3.5 months, and a larger team than
planned was maintained.

During the release retrospective workshop we determined to broaden integration testing and define
collections of use cases that together delivered potentially shippable increments and real customer
value, and focus on ways to increase efficiency and production. We also agreed to discontinue the
bonus / penalty clause.

Quality OK 2.5% 5%
Quality Productivity Productivity Penalty Penalty
5% Bonus +5% +2.5% 0
Defect
Person Day
Rate and
In-Budget Neutral 0 -2.5% -5%
Severity
Variance
KPI
5% Penalty -5% -5% -5%
21
Keep it simple?

V1.S

A part of the contract on bonus / penalties we decided to discontinue…

Formule de calcul :
∑ ((UC A / (UC A+UC Raf)) x UC Init)
V1A =
∑ (UC Init)

Inférieur ou égal à
V1 Feature Complete (V1 F) 70% 80% 90% 95% 100%
Bonus / Malus au 31/3/2007 -5% -2,5% 0% 2,5% 5%
V1 Acceptance (V1 A) 70% 80% 90% 95% 100%
Bonus / Malus au 15/6/2007 -5% -2,5% 0% 2,5% 5%

22
Case 2 : eBusiness Catalog, eCommerce and POS
Agile Contract Evolution…

V2

The client was ultimately satisified with the team’s delivery in V1.S, but felt that
productivity could be improved.

We agreed and together defined a budget for feature development estimated in Use Case
Points (UCP).

After substantial debate on whether velocity could be predicted, for commercial reasons
and based on some thin research on theoretical UCP productivity, a new contract was
agreed.

The contract stipulated that we would bill the client for UCP delivered, and in effect, over a
six month period, (6 four week iterations), deliver to the client a UCP productivity per
person that corresponded to the research.

The total UCP (plus some) engaged by this contract were delivered, but only after 9
iterations. The team became more efficient but not as much as predicted.

Substantial collaboration was necessary between client, business analyst, technical leads
and project management to permit planning and accepting the UCP for each iteration

This ultimately resulted in a high trust relationship – and the contractual eventually
evolved again, into… Time and materials.

The project was deemed a success – and also a substantial learning experience.
23
New contractual forms to consider?
- Valtech has introduced Software on Demand

24
What did the manifesto say about contracts?

Manifesto for Agile Software Development

We are uncovering better ways of developing

software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

© 2001 http://agilemanifesto.org

25
Conclusion

Agile contracts are especially important for clients and vendors when large
commitments are at stake

As an agile project itself, contractual forms evolve during a project

It is better for both parties to gain some experience with a smaller commit level,
and to inspect and adapt the contractual form

Direct communication between the team and client are essential to optimize the
learning and evolution of the relationship and related contract

Customer Collaboration trumps Contract Negociation – but contracts can be

negotiated collaboratively and can be written to favor collaboration!

26
Questions and Discussion?

27
 Thanks!

Greg
GregHutchings
Hutchings

E-mail
E-mail gregoryhutchings@gmail.com
gregoryhutchings@gmail.com
Ligne
Lignedirecte
directe +33
+33(0)1
(0)153
5357
5773
7356
56
Mobile
Mobile +33
+33(0)6
(0)687
8725
2500
0058
58
28