Ok, so my commercial knowledge of contracts of any type is miniscule, so if none of this is new (and I’m sure most of it isn’t) my apologies. However, we covered some of this on the recent
Lean Software Development course I attended in Scotland and I thought I’d pass on some of the ideas and references. I don’t think there is anything earth shattering but it might help when consultancies are negotiating with clients to avoid the ‘fixed price vs. time & materials’ argument (as neither are the best option for Agile).
One of the main points made was that a contract cannot substitute for a trust relationship. This is clearly stated as part of the
Agile Manifesto as "customer collaboration over contract negotiation". Attempts to make it so watertight that companies who mistrust each other can work together will almost always fail. It should provide a framework on which to build the trust. The iterative approach in Agile can help establish trust early – as it did on a recent project – by demonstrating real deliverables after just 1 month. This leads to the idea of, at least initially, having single iteration contracts (or maybe a larger contract with interation work orders called off) that effectively timebox and costbox the work. Once the trust factor has been established, this can hopefully lead to something more manageable for the consultancy.
As an aside, I just read an interesting post about
using this early delivery & trust to sell Agile. Lookout for a future blog entry on this very subject.
Another key part is that scope cannot be fixed! This may start alarm bells ringing but it is the reality of development whether customers like it or not. Since ‘fixed price’ usually means ‘fixed price and scope’, it really doesn’t work for agile projects (or any for that matter) since in anything vaguely complex, requirements will change. Agile development actually encourages change to ensure best fit for the business. The key to resolving this may be to look at the project at a higher level and measure its real value to the company (ROI) to determine its success or failure. As an aside, the idea of measuring what you can influence not what you can control, i.e. at aggregated levels to avoid local sub-optimization, is one of the key principles in Lean manufacturing and is very well described in the
Lean Software Development: An Agile Toolkit book.
One of the best, basic types of contract for agile projects appears to be target price – pretty much what we had for the already mentioned project. This works well since it naturally aligns goals – deliver the best solution for a given budget. There are lots of variation on this theme, particularly around dealing with what happens when the project goes over or under budget. This is where the trust factor comes in - if the scope is variable, how do you identify when the project is actually finished? As already mentioned, this needs to be by measuring at a higher level and could be as simple as having a defined objective - "increase efficiency by at least 10%", "reduce data entry errors by half", etc.
There are some interesting links on the
Poppendieck LLC website. Also, an interesting post by
Martin Fowler about dealing with
a fixed price contract with a new client who insists because of being burned in the past.