Contracts for Agile Software Development

Posted by Chris Sims on May 04, 2009

Sections

Process & Practices,

Architecture & Design,

Enterprise Architecture

Topics

Agile ,

Business ,

Collaboration

Tags

Business Models ,

Contracts & Negotiation

While the Agile Manifesto says "Customer collaboration over contract negotiation", contracts are a reality for many developers and firms. Peter Stevens has analyzed 10 different types of development contracts, shedding light on how well each style fits an agile project. He has uncovered a couple that seem to fit much better than either fixed-price or time-and-materials.

Peter examines each of 10 contract types, and for each describes:

• The general structure of the contract
• How changes in scope are dealt with
• How the risk is distributed
• What type of relationship it fosters between customer and developer

The most basic type of development contract is a time-and-materials approach. This puts most of the financial risk on the customer. The developer has no incentive to finish early or otherwise keep costs down.

The most common alternative is the fixed-price contract. This approach has been popular with clients as it puts most of the risk on the developer. If the project takes longer, the developer eats the cost. This type of agreement is not friendly to scope changes, which can set the stage for potential disagreements about what is and isn't in scope.

Stevens examines these, as well as interesting variations such as the Fixed Profit approach. The parties agree in advance on a fixed profit, e.g. $100,000 that will be paid to the developer. Regardless of how long the project takes, the development firm receives the profit plus the actual costs incurred. If the project completes early, both the customer and the developer benefit.

Llewellyn Falco has used a hybrid contract that he credits to Bob Martin. The contract includes both a fixed amount and an hourly rate. The developer makes an estimate of how long the work will take, for instance 80 hours. The developer then multiplies this by their 'usual' hourly rate, say $200 hour, to get an expected cost for the work. In this case the expected cost is $16,000. This amount gets broken into a fixed amount and a lower hourly rate. For example, the fixed part might be $8,000 and the hourly rate reduced to $100 per hour. If the project takes as long as expected, then the price would be: $8,000 + 80 * $100 = $16,000. If the project runs late, the developer is only making $100 hour on the additional work. This approach is an attempt to share the risk more equally between developer and client.

Peter Stevens' recommendations are the phased development contract and the money for nothing, changes for free contract. He reports personal success with phased development, while observing:

'Money for nothing, changes for free' contract turns the advantages of the Scrum and agile development processes into a competitive advantage.

• By prioritizing and delivering business value incrementally, the chances of an outright failure are dramatically reduced. This advantage is passed on to the customer.
• Furthermore, it’s a cooperative model, so it offers incentives to both parties to keep the costs down.
• The early cancellation clause rewards the higher productivity achieved with Scrum teams. On the down side, this clause feels a bit like a 'golden parachute' which may not be politically acceptable in the current economic climate.

Peter circles back to the Agile Manifesto at the end, reiterating that while having a good contract is important, having a good collaborative relationship is more important.

What types of contracts have you been involved in how well did they serve the relationship? Leave a comment and share your experience.

1. Back to top

   $200 per hour

   by Chris Treber

   :-O That's not USD, right?!
   
   Cheers,
   
   Chris

   Reply

2. Back to top

   I think there's a little misunderstanding...

   by Jim Leonardo

   "we value x over yyyy" doesn't mean we never do y. It only means that given an option, we prefer to do x and will focus on creating opportunities to do x over y.
   
   In addition, I don't think the agile manifesto ever meant preferring collaboration over contract negotiation to imply that when there's an outsourcing relationship, there's not an appropriate financial contract in place. It was more that we prefer to collaborate over having big discussions over what scope is, what the requirements are etc. There's a lot of internal contract negotiation on purely internal projects that is a waste of time and an impediment to doing the right thing for the organization. That's what I think they were addressing in the manifesto.

   Reply

3. Back to top

   Is this kind of contract really push to collaborate?

   by Frédéric TU

   A supposition : I don't see what prevent client to specify something very blur, get a fixed cost, and finally getting some additionnal cost for only 100$ ?

   Reply

4. Back to top

   The hybrid approach

   by John Rusk

   Interesting to hear about the hybrid approach from Falco and Martin. I've used something similar, and think that the hybrid approach has great potential.

   Reply

5. Back to top

   2 years later

   by lars feldmann

   Hi,
   
   Since this article is now 2 years old I was wondering if you had any success or failure stories regarding the hybrid approach? Would be interesting to hear if you could apply it as you described it.
   
   Cheers,
   Lars

   Reply

• Older >