Agile Contracts Require Trust

Posted by Amr Elssamadisy on Dec 11, 2007

Sections

Process & Practices,

Architecture & Design

Topics

Agile in the Enterprise ,

Customers & Requirements ,

Agile

Tags

Contracts & Negotiation

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' ?

1. Back to top

   A Blended Approach

   by Peter Bell

   This has been discussed on an XP list recently:
   tech.groups.yahoo.com/group/extremeprogramming/...
   
   I'm moving towards the idea of a blended approach:
   www.pbell.com/index.cfm/2007/12/13/Managing-Ris...
   
   I think that as developers we should provide a fixed fee for the initial development which is something we can control, but as a client, they should pay hourly for ALL changes required (assuming the delivered software matches the documented story).
   
   As developers, it is reasonable that we take and manage the risk of how long it will take to turn a written description into working code. However, we cannot control how many changes or revisions a client will request or how many additional business rules come up, so if we have to provide true fixed bid we end up padding every quote and good clients get penalized while bad ones get a free ride. I think that charging a fixed fee for working code and then hourly for all discussions, tweaks, new features and support is the least bad solution I've come across to date.
   
   I'd also clarify that where we have a good working relationship, we just fixed bid with a "reasonable" pad (typically 20-40%) and over the course of the project this works out fine. The problem with such an approach are the occasional unreasonable clients.

   Reply

• Older >