An Overview of Agile Contracts
We’re all familiar with the Agile Manifesto but sometimes it’s unclear how to interpret the principle without some concrete examples. The third item, customer collaboration over contract negotiation, is a good example of this.
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.
Much of the early writing on Agile contracts came from the Lean software development community … in particular from Mary Poppendieck’s book “Lean software development“. Alistair Cockburn also has a great summary of different types of contracts on his website.
Although there is a variety of choice, in practice there are only a few styles of contracts that I see over and over. This is due to the fact that we tend to use contracts that we’re familiar with, and so base our decisions on what has worked in the past.
As our experience and expectations change, we will use contracts that are now unconventional. Until that time, I’d like to present three types of contracts. The first two (Capped T & M and Incremental Delivery) are the most common types of Agile contracts. The third (Cost Targeted) is a style of contract that’s often talked about but seldom seen.
Capped T & M
A common contract is the Time and Materials (T & M) contract, but while this style of contract protects the supplier it doesn’t provide any protection for the customer. The customer is fully exposed to the entire risk, while the supplier shares none of that risk.
So, a common extension of T & M contracts is a Capped T & M contract. These are contracts that are T & M up until a fixed agreed upon upper bounds (or cap). Capped T & M contracts provide benefit to the supplier early on by fully covering their expense; but also provide benefits to the customer towards the end of the project by providing a limit to the total exposure. It’s in both parties interest to deliver high value functionality as early as possible and to avoid cost over runs.
Capped T & M contracts are often variable scope, although they need not be.
Incrementally Delivery contracts are structured with regular inspection points, and at each inspection point the customer makes a decision; they can continue with the development of the product or they can stop development. In stopping development the customer can push the product into production and save the remaining balance of the contract. This style of contract works quite naturally for Agile teams because they simply work in an iterative fashion until the point of inspection.
For example, consider a year-long contract that has inspections points every quarter; a team working with two-week sprints would work for six sprints and then present their work to the customer, who then decides to either continue the contract, or not. We can adjust the interval between inspection points to allow for how aggressive the customer wishes. If they wish to inspect more often, then monthly inspection points can be written into the contract.
Cost Targeted Contracts
Finally, it’s worth discussing Cost Targeted contracts. Toyota has attributed these contracts to their long relationship with their suppliers. With Cost Targeted contracts both parties agree on a realistic final price of the product. Then, if the supplier comes in under budget then both parties share the benefit of those savings. However, if the supplier goes over budget then both companies pay some penalty. The amount of benefit or penalty that a company has to pay is usually inline with the ratio of the two companies, so the large of the two companies receives a larger share of the benefit, or pays a larger share of the penalty.
The difficult part with Cost Targeted contracts is agreeing on a realistic final price of the product. Software estimation is (at best) an educated guess, and trying to determine what the final price will be is extremely difficult. I have my doubts whether this style of contract will ever be common in the software industry … although I’d be more than happy to be proven wrong.
Some final thoughts …
I’ve personally used both Capped T & M contracts and Incremental Delivery contracts successfully with Agile projects. And, although there is a lot of buzz and discussion about Target Cost contracts, I’ve yet to see on being used on an Agile project. If you’ve used any of the contracts described by Alistair, I’d love to hear about your experiences.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)