Contracts are the seam that tie together different organizations. Traditional contracts are based on mistrust and a CYA philosophy. Fixed price contracts don't take into consider the uncertainty of software development. Time-for-money projects are not based on value delivered - a team can work for a long time, burn many hours, and not have much to show for. The Agile community is looking for something better.
Mishkin Berteig put together a quick set of readings for those interested in Agile contracts. In it, he notes that this is based on a post by Chris Sterling, and added a few links of his own.
Reading through the different posts by Mary Poppendieck, Alistair Cockburn, Martin Fowler, you will find many different suggestions and war stories but little convergence.
Mary Poppendieck's presentation focuses on building trust and the monetary value of trust in comparing how Toyota and GM deal with their suppliers, and how Toyota has built much more trust:
- (Toyota) Obtains 3⁄4of US components from suppliers while GM obtains < 1⁄2 from suppliers
- (Toyota) Spends 1⁄2 as much money & time on procurement as GM
Alistair Cockburn summarizes 10 different strategies that one might take to creating contracts. An intriguing idea is one that he quotes from Uncle Bob:
[A]gree to pay a certain amount for each point completed, plus a certain amount for each hour worked. For example, let's say you've got a project of 1000 points. Let's also say that a team of four has established an estimated velocity of 50 points per week. This looks like about an 80 man-week job. At $100/hour this would be a $320,000 job. So lets reduce the hourly rate to $30/hour, and ask the customer for $224 per point.
Martin Fowler presents an example from a ThoughtWorks project where they went in with a fixed bid contract, built trust with the customer, and then moved to a more "flexible charging scheme".
I think the key to this story (and we have half a dozen similar examples) is that from the beginning we sought to put the relationship between our companies on a collaborative note rather than a confrontational note. The biggest problem with the fixed scope contract is it immediately pits the client and contractor on opposite sides where they are fighting each other about whether something is a change and who should pay for the change. An agile approach hinges upon replacing that confrontation with collaboration (customer collaboration over contract negotiation).
So why are Agile contracts important enough that the luminaries above all are discussing it, and difficult enough that there seems to be little consensus about them? None of the traditional contract modes actually fit well with the way Agile development teams work - there is a mismatch in process, and more importantly, a mismatch in values.
Have you worked with Agile contracts or are you using traditional contracts in the way you work? How is that working? Is it 'just fine', or do you sometimes feel that 'something is wrong' ?