One of the key motivations that led me to Extreme Contracts was the need for more freedom. This article is the first in a short series to explain why I think we are less free as knowledge workers than we usually think.
Last spring I had again the chance to negotiate an Extreme Contract as a freelance consultant and it went amazingly fine, with a true win-win outcome for me and my customer. I really loved every bit of the story I am about to tell you and I hope it may give you some clue on how a freelance knowledge worker like me could get better deals than usual.
After the chat I recently had with Greger Wikstrand about Extreme Contracts, another nice video was made by Greger with Joakim Lindbom, both Enterprise Architects from Capgemini. In the video they discuss the nice behavioral and economical patterns emerging with the use of such contracts which I forged a few years ago when I was coaching e-xtrategy‘s team.
It is rewarding to see how e-xtrategy still keeps on using those contracts after years and, at the same time, seeing Greger, such an experienced person in enterprise software development, being so interested in them along the years.
e-xtrategy, Greger, thank you all: you are the best incentive to look for better solutions everyday.
We want to reach a wise agreement, in order to generate value for all the parties involved.
We want the deal to be efficient, because time spent searching for a good deal is not generating value: it is pure waste. This implies simplicity. We want the rules to be simple.
We want to keep a good relationship with our counterpart over time. Exploiting agreements are fragile, with those people continuously trying to escape towards better conditions if not trying to cheat in first place.
Extreme contracts are meant to be simple and address all the criteria we want to use to define a good deal among all the parties involved.
Just three rules, everything follows as a side effect:
Very short iterations, usually one week.
A flat fee for every iteration.
Money back guarantee.
The (short) story.
The customer express her needs. A team is set up to address those needs. The team starts working on analysing those needs and one week after delivers anything they think worth the fee. The customer evaluates the deliverable and has two options: accept the delivery and pay the flat fee; reject the delivery and keep the money.
If the customer accepts we repeat this short story one more time. If the customer rejects we can either stop the collaboration or try to run another iteration, maybe – but rarely – after having agreed on a different deal about iteration length or price.
The chat with Greger Wikstrand
On Apr 07 2015 I had a Google Hangout with Greger about this kind of contracts, willing to get his raw feedback. Enjoy our video!