Upload
greg-hutchings
View
226
Download
0
Embed Size (px)
Citation preview
8/8/2019 Agile2008GH Agile Contracts
1/28
Distributed Agile Teams and
Alternative Contractual Forms
- What Works Best?
Greg Hutchings
August 6, 2008
8/8/2019 Agile2008GH Agile Contracts
2/28
2
Distributed Agile Teams and Contractual Forms
About the author
Greg Hutchings
I live in Paris and work for Valtech,proposing, negotiating, managing andliving with large distributed agile projects.
I travel often to Bangalore and withinEurope. I am originally from the SF Bay
area, where I was a client partner forThoughtWorks, after spending years insoftware product development.
Ive been involved with software teamssince the early 80s, and have been using
Agile and XP practices with teams formallysince 2003 and informally since the early90s.
8/8/2019 Agile2008GH Agile Contracts
3/28
3
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)
8/8/2019 Agile2008GH Agile Contracts
4/28
4
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
8/8/2019 Agile2008GH Agile Contracts
5/28
5
Distributed Agile proposal process
Interest in doing distributed agile development is usually related to cost savings, ortime 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 whenworking with an offshore vendor, and can help to address fears and concerns
It is better to introduce offshore and onshore delivery staff early with acollaborative approach, and to absolutely involve the delivery team in estimatesand client relationship building.
After an understanding of the clients needs is obtained high level scope, timeframe and budget, and specific constraints, a proposal is prepared
After the proposal is presented, reviewed, revised and agreed in concept, thecontractual development process begins
8/8/2019 Agile2008GH Agile Contracts
6/28
8/8/2019 Agile2008GH Agile Contracts
7/28
7
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, timingassumptions 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
8/8/2019 Agile2008GH Agile Contracts
8/28
8
Planning Releases, Iterations and Communication
In addition to the type and structure, the contract will need to define the term of theengagement; it is useful to describe, plan for and gain commitment to events
Although we probably dont 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 vendoror 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 numberof iterations and a ramp-up in team size can be used to model what level of effortthe budget might cover.
Especially for distributed agile projects, in the contractual discussion it is veryuseful to review a release plan of a number of iterations, and to discuss the needfor face to face communication at iteration boundaries. For distributed projects weoften 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 vendoreither estimates involving development spikes on representative requirements orterms that permit substitution of or variance in scope are important.
8/8/2019 Agile2008GH Agile Contracts
9/28
9
Key events in a distributed agile Iteration
Day 2 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
Iteration
Planning Meeting
Requirements
Workshop
Prep Build Build Build Build Build Build
Day 1
Week 1 Week 2Day 3
Development
Deployment of
previous iteration
DesignWorkshop
EstW
orkshop
Development
Development of test cases
Support Deployment
Development of test
cases
UAT UAT
Day 11 Day 12 Day 13 Day 14 Day 15 Day 16 Day 17 Day 18 Day 19
Build Build Build Build Build Build Build Build Build Package Package
Week 3 Week 4 (Week -1)Day 20
Next Iteration Planning
Retro-
spectiveDemo
Development
Testing Testing Prior Iteration
Preparation of UAT Env Validate Env
During a distributed agile contract negotiation, I discuss the events in a sprintand which should involve face to face discussion.
8/8/2019 Agile2008GH Agile Contracts
10/28
10
Distributed Agile Events roles and conditions
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 clientand vendor to communicate regularly face to face, the budget for travel and thecommitment of key staff to the project can be planned.
Meeting /
Session Type
Facilitating
Role Attendees Locale
Session
Length Pre-Condition Post-Condition
Input Responsible Role Output Responsible Role
Release
Planning
Meeting
EM
EM, PO, FM,
PM, Arch, all
BAs, Tech Lead
France 1 day
Project is initiated,
key participants
are on board
A backlog of high
level requirementsis prioritized to
permit planning of
the iterations,
overall release and
major milestones
High level
functional andtechnical
requirements,
schedule and
budget contraints
PO, BAs, Arch,
EM coaching
Release Backlog,
known definition of
project success
EM, PM, PO
Iteration
PreparationPM
PO, FM, PM,
Arch, all BAs,
Tech Lead
France 20 days
Demo of previous
iteration is
complete
Enough
information is
available for
finalizing priorities
for the iteration
and agreement to
scope of iteration.
Previous iteration
scope "Done"
status for each
scenario taken up
PO, BAs, Arch,
EM coaching
High level
scenariosPM, FM, BAs
Iteration
Planning
Meeting
PM
PO, EM, FM,
PM, Arch, BAs,
Tech Lead, Devs
India 4 HoursHigh level
scenarios
Enough
information is
available for
preparing
Requirements
Overview
High level
scenariosFM, BAs
Proritized
requirement
backlog with
desired scope for
the iteration.
BA + Customer
Inputs Needed for the Session Session Output
8/8/2019 Agile2008GH Agile Contracts
11/28
11
Client and Vendor Roles and Responsibilities
An agile contract should clearly state what is expected of each party, and ofspecific 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 theyparticipate in release and iteration planning, retrospectives and as product ownerusing the Scrum role metaphor, be available daily, even at a distance, to clarifyrequirements.
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 consequencesof being late.
These may include transferring risk back from vendor to client (e.g. convert to timeand materials, assume capacity was consumed but wasted, etc.) or from client tovendor (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 thatthe team does not become blocked prior to, during or after an iteration
Executive sponsors / stakeholders should be defined, in the contract or exhibit.
8/8/2019 Agile2008GH Agile Contracts
12/28
12
Roles and Organization Chart
Product Owner(Owns Initiative budget)
Domain experts
Technical Lead
Senior Developers
Release Management
Infrastructure
Agile Offshore Coach
France
Feature Manager
France
Executive Steering CommitteeExecutive Steering Committee
Transversal CommitteeTransversal Committee
Operational CommitteeOperational Committee
Development Team
Program DirectorFrance
Project Manager
Tech Lead / CSMIndia
Client (typical)
The larger the Clients delivery involvement is, the less likely that theterms of a distributed agile contract can be fixed bid, and the more
likely that enablement will be the top priority.
8/8/2019 Agile2008GH Agile Contracts
13/28
13
Estimating functional and non-functional scope
In all Agile projects, estimation is very important, and is necessary to plan releases anditerations
Estimation units of a team often need to be translated into terms meaningful to the client
The clients 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 toreplace the existing, etc.
Contractually, if the contract is not time and materials, something other than time must bedelivered and measurable in order to justify payment, and for distributed agile contracts themore easily and exactly the units can be measured and verified, the more clear communicationwill be and generally the better the relationship
Clearly, it is very important to define What is done with acceptance tests and to include thesewith requirements when doing detailed estimates
Others in this conference, including Mike Cohn in his session yesterday, have treated thissubject 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 ofmeasure in a manner that is clearly described and understood in the agreement, and can bemanaged, 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-functionalrequirements in fixed bid contracts or sometimes, even to adequately define theserequirements.
8/8/2019 Agile2008GH Agile Contracts
14/28
14
Acceptance Testing
Agile contracts or their associated proposals should define what acceptance tests are, whowrites them, validates them, performs them, where, and when.
I often contractually suggest that the client participate in the definition of the acceptance testsduring the preparation of stories or use cases, and that they be discussed and validatedconsensually in the requirements workshop
Acceptance of the delivery of an iteration is specified contractually to be associated with thepassage of the scopes related acceptance tests, and in a fixed bid contract or a pay forproduction 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 thecontract that feature delivery acceptance is assumed within a short period of time (eg 10 days) ifautomated 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 clientrepresentatives to iteration end demos and provide access to the project dashboard to reducethis risk.
Customer visits to the offshore development site can be coordinated with demos andacceptance testing of the most recent iterations delivery if planned appropriately, and this
practice greatly increases the offshore teams satisfaction level and the clients confidence andtrust in the offshore team.
In distributed agile projects, the importance of comprehensive and automated functional andnon-functional testing is critically important to serve as an objective indicator of project qualityand progress. Tools such as Rally Dev, Version 1 and others provide information radiators tokeep client and vendor in sync, and their usage is often stipulated in our contracts.
8/8/2019 Agile2008GH Agile Contracts
15/28
15
Warranties and Reversability
Most vendor attorneys generally advise limiting the warranties provided by thevendor in many important ways
However, clients wish to be reassured that the vendor is engaged and committed
and aligned with the clients 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 isto guarantee that a custom app will be free of major or blocking defects for a periodof 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 ofmajor defects that require liability insurance to be purchased.
Reversability clauses deal with the event that the Client decides to switch vendorsor in-source the applications continued development or maintenance, by providingfor 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/ortranslation services, so an appropriate budget should be defined and costed intothe contract at the time of its negociation.
8/8/2019 Agile2008GH Agile Contracts
16/28
16
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 agileprogram
Large distributed agile project
Several interesting contractual forms
Organisation also evolves and adapts, learning together
8/8/2019 Agile2008GH Agile Contracts
17/28
17
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)
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
Fixed Bid
June 2005 December 2005 June 2007 August 2007
Bid per iteration / incremental acceptance UAT
Re-Negotiation
8/8/2019 Agile2008GH Agile Contracts
18/28
18
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 framewas agreed, there was no penalty for late delivery
The onshore team was initially the sole point of contact with the client. They developed closerapport, negotiated the contract, provided estimates and built the requirements andarchitecture. The client wished to communicate in french and did not have face to face contactwith the offshore team.
The offshore team was not involved in validating the onshore architects estimates, and did notfeel committed to the estimates, the contract or to the client
Strained relations developed between the onshore and offshore teams, internally, andeventually with the client as quality expectations were not met. The client seemedunreasonable.
A blow-up occurred when the quality level was consistently not acceptable.
The parties met, including representatives from offshore, addressed some technical issuesrelated 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.
8/8/2019 Agile2008GH Agile Contracts
19/28
19
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
Fixed bid duo-shore agile
Jan 2005 December 2005 June 2006
Time and materials with KPI strong offshore T&M UAT
Negotiation
Change project management, France -> India Rebalance French/India team and roles Create direct India/customer communication Quality and productivity indicators put in place
V1.C
POC
Dec. 2006
V1.S
Negotiation
V1.C delivered V1.S negotiated, POC begun Revamped process, ramped team
8/8/2019 Agile2008GH Agile Contracts
20/28
20
Case 2 : eBusiness Catalog, eCommerce and POS
Agile Contract Evolution
BIG ramp up, T&M +/-
Janvier 2007 June 2007 June 2008
Pay per UCP, Rising Velocity assumption
Negotiation
Fine-tuned process for integration Established UCP cost and budget Forecast velocity and acceleration
V1.S V2
T & M with a cap
NegotiationNegotiation
T & M with + / - Established PD budget Productivity & Quality
With trust established, returned to asimple time and materials mode forsupport of deployment and production
V3
8/8/2019 Agile2008GH Agile Contracts
21/28
21
Case 2 : eBusiness Catalog, eCommerce and POS
Agile Contract Evolution
the T&M contract with bonus / penalty clause was in response to client demand for fixed bid andvendor 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 4delivery locations.
The team earned the 5% productivity bonus by delivering 99,5% of Use Cases, but had a 2.5% penalty forquality based on integration tests
The planned 2.5 month UAT and Beta test period was extended to 3.5 months, and a larger team thanplanned 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 customervalue, and focus on ways to increase efficiency and production. We also agreed to discontinue thebonus / penalty clause.
Quality Productivity
Person DayIn-BudgetVariance
DefectRate andSeverity
KPI
-5%-5%-5%5% Penalty
-5%-2.5%0Neutral
0+2.5%+5%5% Bonus
5%Penalty
2.5%Penalty
OKQualityProductivity
V1.S
8/8/2019 Agile2008GH Agile Contracts
22/28
22
Keep it simple?
A part of the contract on bonus / penalties we decided to discontinue
70% 80% 90% 95% 100%
-5% -2,5% 0% 2,5% 5%70% 80% 90% 95% 100%-5% -2,5% 0% 2,5% 5%
Infrieur ou gal
V1 Feature Complete (V1 F)
Bonus / Malus au 15/6/2007V1 Acceptance (V1 A)Bonus / Malus au 31/3/2007
Formule de calcul : ((UC A / (UC A+UC Raf)) x UC Init)
V1A = (UC Init)
V1.S
8/8/2019 Agile2008GH Agile Contracts
23/28
23
Case 2 : eBusiness Catalog, eCommerce and POS
Agile Contract Evolution
The client was ultimately satisified with the teams delivery in V1.S, but felt thatproductivity 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 reasonsand based on some thin research on theoretical UCP productivity, a new contract wasagreed.
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 perperson that corresponded to the research.
The total UCP (plus some) engaged by this contract were delivered, but only after 9iterations. 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 eventuallyevolved again, into Time and materials.
The project was deemed a success and also a substantial learning experience.
V2
8/8/2019 Agile2008GH Agile Contracts
24/28
24
New contractual forms to consider?
- Valtech has introduced Software on Demand
8/8/2019 Agile2008GH Agile Contracts
25/28
25
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 negotiationResponding 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
8/8/2019 Agile2008GH Agile Contracts
26/28
8/8/2019 Agile2008GH Agile Contracts
27/28
27
Questions and Discussion?
8/8/2019 Agile2008GH Agile Contracts
28/28
28
Thanks!
Greg Hutchings
E-mail [email protected] directe +33 (0)1 53 57 73 56Mobile +33 (0)6 87 25 00 58
Greg Hutchings
E-mail [email protected] directe +33 (0)1 53 57 73 56Mobile +33 (0)6 87 25 00 58