This evening I had the pleasure to meet with the Agile community in Tri-City, Agile3M. After several discussions around working in an Agile way they were wondering how to solve the contracting with an external client. Honestly, this is a rather challenging topic. Based on mutual trust it’s possible to reach an agreement, but in case trust is lacking, it’s going to be a long, hard road.
It’s a matter of give and take
Working in an Agile way has in my opinion many advantages and increasingly research is showing this as well. But this doesn’t mean it’s easy. I would even dare to say it’s a lot harder than many people think. Especially when you are cooperating with external clients the contracting part is sometimes a real challenge.
Clients are used to the fact they request for a solution or service based on their specifications. They want to receive an offer matching their needs for a fixed price and before a defined date.
Unfortunately, in reality it won’t work out like that. Too often the specifications aren’t clear enough, which means that the project scope will change during the project. Most traditional contracts don’t include this flexibility, which in general leads to very costly change processes.
Working in an Agile way means that we embrace change, we love it, because we believe it will lead to better results. But allowing change means that flexibility within the contract will be needed. It means you will have to allow scope changes.
The good news is that in general every project specification includes at least 20% (and mostly more) of unnecessary features. For whatever reason they were included. An Agile project allows you to skip these features and to save the reserved budget for more useful things, at least if you agreed about this approach in the contract.
Agile contracts cannot be “fixed”
If you want to work in an Agile way you can no longer demand that a project will have a fixed scope, for a fixed budget, that it will have a fixed high quality and that it will be delivered before a fixed date. Some Agility will have to be included.
I propose making both the scope and budget more flexible.
Based on our experience this in general means you will get more for less.
Do you dare to trust that?
A contract template might follow
Unfortunately, till date I didn’t manage to find a full Agile contract template. If you have one, please share it with us. Otherwise I plan to provide our contract template that we are adjusting at the moment soon.
[slideshare id=27035099&doc=20131009agile3magilecontractingarealchallengefinalpho-131009160523-phpapp02;w=640]
I like the fact that you’re not recommending to play with the quality slider 😉 especially internal quality is dangerous to play with, since clients don’t realise of its importance most of the time (or they assume it’s there implicitly). It’s left up to developers to assure it’s there and too many companies tend to sacrifice it.
Kuba, thanks for replying and supporting the statement. Indeed I don’t recommend to use quality as an adjustment tool like some project management best practices do. Sooner or later you will “pay” for that.