|
Agile
Development Conference: Salt Lake City, June 25-28
Agile Contracts Workshop: Wednesday, June 25, 8:30 - 11:30
Organizers: Mary Poppendieck & Christine Moore |
The following papers were discussed at the
workshop (click on hyperlink to see paper):
-
Fixed Price Contract &
Agile Software Development - An Experience Report, by
Christine Moore
-
The Rule of 3rds - An Agile Approach, by Christine Moore
-
Sample Language and
Stories, by Cem Kaner
-
Excerpt on Contracts from Lean Software Development, by Mary Poppendieck
and Tom Poppendieck
-
Sample Contract Wording
(specifying a Prototype to provide learning)
-
Draft DSDM Contract,
Commentary, &
License, by Richard Stephens
and the DSDM Consortium
-
Optional Scope Project,
by Marina Morgagni – Manager, eXtreme Programming Centre &
Piergiuliano Bossi – Coach, eXtreme Programming Centre, Quinary SpA,
Italy (Submitted to XP2003 Workshop)
-
Pay Per Use Contracts,
by Nora Sleumer, Massimo Arnoldi, Massimo Milan
Lifeware SA, Switzerland (Submitted to XP2003 Workshop)
|
|
The following contract terms were discussed: |
|
Dispute Arbitration Clause (See Handout #3)
Have the contract call for mini-arbitration in case of
dispute:
 |
One trusted decision maker |
|
|
Both sides get 2-3
hours to present their case |
|
|
Decision-maker decides |
The very presence of such a clause usually
causes the parties reach an agreement
without arbitration. |
License instead of 'Work for Hire"
Use, not completion, is emphasized.
Customer has an incentive to pay.
|
|
If they use it,
they pay |
|
|
If they don't pay, they
can't use it |
The use of a license protects the vendor
from non-payment. |
|
Participants discussed the following
experience: |
|
Can this Contact be Saved? (See handout #1)
|
|
Fixed Price Government
Contract
(requirements pre-written by another vendor) |
|
|
Trusted Relationship |
|
|
XP was used (not well implemented) |
|
|
Failure (no working
software) |
|
|
Vendor determined to
fix things |
|
|
Less Trust, more
pressure |
|
|
New team of experienced
people |
|
|
XP used again (well
implemented this time) |
|
|
Started delivering
working software that did what the customer actually wanted (not what
the requirements said) |
|
|
Developed a new social
contract. |
|
|
Actual contract was not
changed. |
|
|
Keys to success:
 |
Developers focus everyone on simple solutions
|
|
|
Strong customer
participation |
|
|
Very senior, small
development team |
|
|
Creatively help
customer envision the result |
|
|
Tell customer when
their decisions have negative impact |
|
|
|
The following contract types were discussed: |
|
Fixed Price Contract
Notes:
- A T&M contract should be cheaper.
- Should pay an added fee for fixed price.
- Changing requirements create frustration
+ Mitigate risk with early results |
Fixed Price Contract
Customer Motives
+ Get the best product possible
+ Not held to original requirements
+ High Quality Software
|
Fixed Price Contract
Vendor Motives
+ Get to write good software
+ Get a good reference
- How do we know when we're done?
- Risky |
|
Two Phase Contract
Vendor takes a calculated risk in phase 1
Defines a large enough project to build confidence/trust
|
Two-Phased Contract
Phase 1: Fixed BidSmall;
build trust
Vendor at risk
"Satisfaction Guaranteed" |
Two-Phased Contract
Phase 2: RetainerOpen ended
Customers get what they want
Development is a discovery process |
|
Variable Scope Contract
+ Best for Agile Development
- Can use T&M not-to-exceed
+ Trust starts small, then grows
+ Can use fixed price iterations |
Profit Sharing Contract
+ Both Parties share in the success of a
product line
+ Both parties are motivated to maximize 'total success' |
Target Cost Contract
+ Parties share the pain if target cost is not
met
+ People from both parties are motivated to hit the target cost
|
|
The following customer and
vendor categories were identified: |
Government Customers
|
|
Military |
|
|
State |
|
|
Local (City, etc.) - most friendly |
|
|
Prime Contractors |
|
Commercial Customers
|
|
Life-critical (vs. non life-critical) |
|
|
Been burned before
|
|
|
Use government practices |
|
|
Established culture (not interested in new things) |
|
|
High regulation |
|
|
Entrepreneurial |
|
|
Scientific / Medical / Research |
|
|
Software is central / strategic
|
|
|
Software is a product
|
|
|
Software is a cost center |
|
Vendors
|
|
Big Software House |
|
|
Small Vendors |
|
|
Customization |
|
|
Staffing |
|
|
Issues that may affect
contract negotiation: |
Culture
|
|
East Coast vs. West Coast |
|
Country
|
|
European/Japanese/US etc. |
|
Embedded Software
|
|
Multiple Disciplines |
|
|
We listed these
contract ideas for making agile easier: |
|
|
Use Extensions of Trust: guarantees, easy
outs, equitable outs |
|
|
Point out that rigorous change control
increases cost and proliferates non-value added work |
|
|
Use 'mini-arbitration' to get to decision
points regarding scope |
|
|
Stop when resources are depleted and/or
business value is achieved |
|
|
Try Optional Scope through fixed iterations |
|
|
Build a sorter duration and full business
value into the contract as an alternative to more agile approaches.
(Prioritization is forced by the contract.) |
|
|
Build learning or discovery sessions into
the contract (rather than precise requirements) |
|
|
Incorporate customer responsibility into the
contract |
|
|
Incorporate collaboration into the contract |
|
|
Build in incentives for both parties to hit
the targeted business value |
|
