BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Contracts for Agile Software Development

Contracts for Agile Software Development

Leia em Português

This item in japanese

Bookmarks

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.

Rate this Article

Adoption
Style

BT