Contracting for Agile
In a capitalist system, customers want value, suppliers want profit. In the delivery of bespoke (IT) products to customers, Agile has become the defacto approach to delivering value, but how do you satisy a supplier’s desire for profit without hampering the delivery of value?
The Status Quo
The two traditional approaches to contracting the delivery of services are:
- Time and Materials (T&M)
- Fixed Price (which also fix Scope)
Unfortunately, T&M does not drive the correct supplier behaviours owing to a lack of incentive to deliver early or to use resources creatively. As a result the customers retains the majority of the risk for the delivery. On the flip side, Fixing price and scope does not drive the correct customer behaviours owing to a focus solely on price rather than working together to deliver value — change is often highly contentious.
The best outcome to contract for agility is an approach where the risk of delivery is balanced between the customer and supplier; by balancing the risk, both parties are incentivised to collaborate for the best possible outcome. So whilst there is no such thing as an “Agile Contract”, some contracts support an agile way of working better than other and ultimately they will influence the behaviour of one or both parties.
The End — almost
So you want a few ideas on how to achieve the above?? Here are some potential contracting options …
1. Time and Materials (T&M)
Regularly invoice for labour used in pursuit of delivering customer value
- Low risk for supplier
- Clarity over what is being contracted for (i.e. labour)
- Ultimate flexibility
- Limited scope for supplier to differentiate from competition
- Supplier becomes a body shop — customer can get attached to specific supplier employees
- Customer focused attention on day rate rather than value delivered
- Most of risk retained with customer (Preferred supplier lists/frameworks can help here. With these there is the ever present prospect of a future re-compete at which point the supplier will have to demonstrate value — hence, in theory, incentivising the supplier to perform assuming they value the relationship).
2. Capped Time and Material
Regularly invoice for labour used in pursuit of delivering customer value, but with an upper limit
- As per T&M
- Fixed financial liability for customer (can’t overspend by acident)
- More incentive on supplier (some transfer of risk) to ensure benefit is realised before cap is reached
- Supplier knows they don’t have a blank cheque
- As per T&M
3. Capped Time and Material, define outcome
Agreed fixed outcome, customer may pay less if acceptable level of value is delivered early, supplier retains delivery risk.
- Low customer risk, customer benefits if either the project is delivered early or late.
- Supplier is incentivised to deliver on time
- Supplier is not incentivised to deliver early
- Risk is not shared equally
- Quality likely to suffer in the result of overrun
4. Incremental Delivery
Customer pays for incremental units of work
- Outcomes can be regularly changed
- Total Risk can be better understood by biting the problem off in smaller chunks
- Supplier is incentivised to delivery
- No confirmed upfront price for customer
- Long term pipeline of work not guaranteed for supplier
5. Two(+) Phase, Discover then Fixed Price and Scope
Fixed cost to derisk/discover, fixed cost to deliver — A specialisation on the Incremental Delivery model
- Promotes derisking early (think UP Inception/Elaboration)
- Shared risk between customer and supplier
- Works towards customer having a defined costs and deadlines after small initial outlay
- Incentives supplier to work effectively in both phases
- No confirmed upfront price for customer may cause issues getting business cases signed off
- Temptation for supplier to use derisk phase to produce detailed specification to reduce risk of change later (V model)
6. Fixed Price and Scope
Price and scope fixed at the start of project (usually via competitive tender)
- Lower risk for customer
- Supplier drives the deliver and manages resources
- Change is handled explicitly
- Opportunity for increased profit/cheaper solutions if economies of scale leveraged
- Provides an opportunity to break into new markets / earn the trust of a new customer
- Does not foster a collaborative relationship
- “Change”, cost and what is considered change likely to become highly contentious
- Risk mostly with supplier
- Quality likely to be traded in the event of overruns
N.B. Don’t forget the Minimum Viable Product for your scopen(or as I prefer Minimum Vuable Product)
Agile can work with Fixed Scope contracts by defining a core Minimum Viable Product. The MVP represents only what is absolutely essential in order for the product to be useable and is likely to make up around 80% of the total price. This offers the advantage that the customer knows that they will get something of real business value (i.e. the MVP), whilst providing some additional risk contingency to the supplier in the form of non-mandatory requirements within the fixed price to soak up any unforeseen complexity delivering the MVP. By adopting this approach around the requirement, you effectively get a version of 9. Fixed Price, Shared Risk Budget.
7. Price Target
Both parties agree a realistic price and contribute to overspends or share underspends (Toyota model)
- Risk is shared (generally in proportion to the size different between customer and supplier — bigger party taking on more risk)
- Both sides are incentivised to deliver
- Agreeing “what” the price target is for (i.e. scope)
- Change needs to be handled carefully.
- Need to negotiate sharing proportions
8. Fixed Profit
A fixed profit point is agreed after which the project runs at cost. Customer can pull out at any time by paying the remaining profit. Supplier fixes scope at a defined quality level.
A fixed profit point is agreed after which the delivery runs at cost. Customer can pull out at any time by paying the remaining profit.
- Risk is split between parties
- Supplier is incentivised to deliver early and has costs covered in the event of an overrun
- Customer retains control of backlog and has freedom to request change
- Quality is controlled in the event of an overrun
- Money for Nothing — Customer can terminate (if value proposition no longer makes sense) by paying remaining profit
- Change for Free — If the customer remains engaged, they can replace items (of equal value) in the backlog with anything they choose.
- Careful attention is required to define the outcomes to the satisfaction of both parties (which is now the central commercial agreement)
- Likely to get some disagreements around if a change is part of the core contract — as the supplier will be incentivised to up sell to increase profit (or to prevent dilution of profit)
- Follow on work after the delivery date will need recontracted
- Customer does not have a fixed price for the work (but will benefit through “cost price” on additional effort resulting through other runs)
9. Fixed Price, Shared Risk Budget
Customer and Supplier have access to a shared risk pot in the event of risk materialising or mitigation being required.
- Formal arrangement for customer and supplier to share risk
- Allows customer to cap exposure to delivery risk, but supplier also has some protection for unforeseen circumstances
- Both parties incentivised not to raid risk pot
- Additional formality, complexity and cost of setting up contract
- Customer may be reluctant to share risk funds
10. KPI Driven
The supplier is paid on the basis of hitting predefined key performance indicators.
- Highly flexible and KPIs can be targeted to specific customer value measures
- Allows for change, scope not predefined
- Delivery expectations clearly understood — less scope for ambiguity
- KPIs can be assessed at regular intervals (e.g. Sprint, Program increments) — so risk can be managed and shared
- Goodhart’s law — “When a measure becomes a target, it ceases to be a good measure.”
- Extreme care is required to pick the right metrics. Picking the wrong metrics may cause significant issues — drive the wrong behaviours
- Many Agile metrics make poor KPIs (e.g. Velocity) — hence this approach is recommended only if customer and supplier has appropriate SMEs who understand what they are doing
- Unstable output likely at start of contract or with new/changed team — best results with stable team with a track record
Incorporates and extends on ideas from 10 ways to contract agile published by Peter Stevens on agilesoftwaredevelopment.com and the above is therefore released under Creative Commons Attribution NonCommercial Licenses (2.5) — http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts. Note that I have been unable to find the original post.
Other Useful resources:
An overview of Agile Contracts : Scrumology Pty Ltd
This article is part of my online newsletter called the Scrum Addendum. If you enjoyed this article you should signup…
13 Secret tips to retart your Organisational Agility
Here are a few great techniques to slow down any organisation …
The insidious institutionalisation of “water-Scrum-fall”
What the hell is Water-Scrum-Fall and why you should not go near it …