Wed 28 Oct 2009
In the the world of Scrum & agile there is an ongoing discussion about contracts. Main problem is clash between agile approach of flexibility based on adaptation and the world of RFPs, RFIs and fixed contracts. I’ve seen many good talks and presentations about this, including also on the last Scrum Gathering. One thing I don’t agree with is the way the problem of risk is being handled almost in all of them.
People usually start their talks with the notion that in the basic time&materials contract (the only truly agile contract if you ask me) all the project risk is on the client’s side and other contract types somehow move some of the risk to the supplier. Some go as far as to say that in a fixed bid contract (fixed time, scope & cost) all the risk is on the supplier side.
First time I heard this I thought this is clever, but over time it dawned on me that this “risk sharing” is as much illusory as is the security of the fixed bid contract. Here is why.
The single biggest risk anyone faces when they build something is that this something won’t fit the purpose it was intended for. Causes for this can be numerous: the needs might have been not understood properly or the idea doesn’t fit the market, the needs have changed or the thing built can’t be used because of defects. Finally, the thing being built may be delivered too late for it to be used as intended.
No matter how hard you try the biggest share of this risk is always on the client’s side, because it is the client who won’t get expected benefits in the end. You may add as many penalties and harshly sounding clauses to a very fixed and rigid contract as you want, you still won’t get away from this risk.
Imagine you’ve spent 3 months writing the initial spec, then next two months on RFP/bidding process, then contract negotiation, then two years on developing your complex software system only to discover at the end of all this that the product is not exactly what you intended, is full of bugs and is irrelevant because in the meantime the world moved on (the usual, flawed, waterfall process). What then? Yeah, you can sue the unhappy supplier all the way, but how much good will it do to your business? You can not pay them and even bankrupt them if they were not careful – will that repay all the lost opportunity? Make up for lost time? No way!
This risk is like a boomerang. I’ve heard someone define a boomerang as a piece of wood that no matter how hard you throw away from you will come back and smack you in the face. Very fitting. The harder you try to move away from this risk with complex contracts the more you will be hurt in the end. You don’t need rigid relationship based on distrust to tame this risk, you need an adaptive relationship with people you trust but can check all the time.
That’s exactly what agile offers: tight control of the product being developed in short inspect&adapt cycles. Instead of trying to write clever penalty clauses and waste time on lawyers clients can closely monitor the progress of the team(s) that build their software. They can spot any problems early on and correct them. Or readjust the backlog to changing situation keeping their product relevant. Or change the team.
I’d say there is way way less risk here. What clients pay with for this is their time and involvement – they have to see test builds at least every sprint, they have to speak to the team, readjust the backlog and overall stay on top of their project. But all the time they have all the tools and controls to navigate the project to a successful end. A fixed contract just kills all the outset.
So, next time when people will again define contract negotiation as risk pushing I’ll definitely interrupt them with my little boomerang analogy, because I feel we must all realize this is yet another (paper) illusion.
October 28th, 2009 at 21:02
Totally agreed – excellent blog post! The boomerang metaphor may help us in according future discussions 🙂
October 28th, 2009 at 21:24
In theory it sounds good, and I wish they could, so I can almost agree… Unfortunately the reality is more complex.
Agile doesn’t offers control, offers to fail in a short period of time. This does not reduce the risk, just reduces the loss.
Agile Contract only works in the IT World, not in Real World. Everyone (not IT) puts the risk on supplier side (in fact yourself when you buy anything), that will not change for a while… Do you have only IT clients? Good for you!
October 29th, 2009 at 23:00
Willy, everyone is just fooled the risk is not on their side. And I’m talking here about custom-built complex products, not about mass manufactured, repeatable goods.
October 30th, 2009 at 0:40
Hi Andy:
In theory the client should be involved along the way – but I don’t think the client has the skills or time to wait for an entire project to be completed prior to a first review. So I normally push for a technique used by countless folks: milestone-based projects/contracting.
The developer breaks the single project into discrete milestones. Things that ARE capable of inspection (and testing) by the client get reviewed and then PAYMENT is tied to successful milestone acceptance, with the entire amount paid over time tied to successful completion of the entire project (ie: if you never reach the goal, the client gets their $$ back).
Oh, it still doesn’t eliminate the risk, but it does spread it about some. 😉