Gurus on Contracts

Martin Fowler is well-known industry guru, respected by virtually everybody (including me). He suggests you can't use agile processes on projects with fixed price and scope. Alistair Cockburn -- who is a well-known industry guru, respected by virtually everybody (including me) -- says you can. To resolve this apparent conflict, we need to understand two things:

Firstly, you have to give up certain agile techniques when working on fixed price projects. For instance, you can't use "just-in-time" requirements definition [1]. However, even though you have to give up some agile techniques, you don't have to give up all of them. You can still use iterative delivery, automated testing, close communication and most other agile techniques.

Secondly, we must consider what a fixed price contract really is. A fixed price contract is based on an estimate of the work required. Customers don't want fixed contracts because estimates are good; they want fixed contracts because estimates are bad. The actual effort never matches the estimate, and fixed price contracts are simply a way of making the supplier responsible for the difference.

So, as long as the requirements are stable -- stable enough for the supplier to accept responsibility for the cost difference -- a fixed price contract is OK.

Do suppliers accept such responsibility too willingly? Do price-based procurement processes encourage them to do so? How accurate can estimates be, when requirements are stable? These are all excellent questions, which I hope to write about some day...

As Alistair Cockburn suggests, the supplier can follow the fixed quote with an agile process.

Everything changes if the requirements are not stable. As Martin Fowler suggests, changing requirements need agility and a flexible contract.

I've written more on this subject here.

[1] Although, whether you planned to or not, you may end up discovering the requirements before the price is fixed but truly defining them (in detail) afterwards. Depending on how you handle it, this may or may not be a good thing. Done well, it can have an agile feel and a win-win outcome. Done badly, it becomes confrontational and lose-lose.

Page History: Created 24 Jan 05

Updated 30 Jul 05