Gabriel asks: Can you suggest me few relevant papers on Agile contracts? I am interested in both the ad-hoc, non-commercial agreements, to maximize, based on Pareto law naive application, the output of PO-development team through collaboration, and the commercial agreements that best support such an objective. I read this: http://www.agilecontracts.org/agile_contracts_primer.pdf but I would like to read more materials on the topic.
Here is a short answer. And maybe too basic for you.
1. You can have a waterfall contract (old style) and use agile to deliver. And probably things will turn out better. One problem could be getting progress paid for ‘interim deliverables’ (documents), but I won’t do there now.
2. I like Jeff Sutherland’s idea about an ‘agile contract’ half-way house. It is between a waterfall contract and a real agile relationship between the buyer and the seller.
The basics are: you get a BRD from the client, and convert that to a product backlog. You organize the PB by business value, add story points, and give it a fair overall cost. And you estimate the ‘final delivery date’. And then discuss contract terms.
In summary, the terms include:
Client will inspect every sprint. Change for free (if we did something wrong…obviously we built in some padding for this…aka ‘contingency’).
Equal substitution. If the client wants to add a feature, then a feature (story) of equal size comes out.
Addition. Client can still just add a feature, at the same old price (high).
Early Termination. The client can terminate early if the client pays X% of the remaining contract. (X=20%?)
This gives the vendor a strong incentive to terminate early. And aligns the vendor with the customer need to ‘complete’ faster. Also, the features are built (mainly) in BV order.
Jeff Sutherland calls it ‘money for nothing and change for free’. Smile. A good step in the right direction. Often the biggest first step one can make away from the old waterfall contract.
3. A real agile contract.
This is more like a T&M contract. The client becomes the PO. Or at least can change the PB at any time.
The key term is that the client ‘owns’ the team continuously, for as long as they want and at a monthly price. And the client can cancel the contract at any time, with X months’ of notice. (X=2?)
This gives both parties an incentive to work well together, and get it done early (get the next release out early). The vendor does good work each month to justify continuing to be employed by the client. The client gives good PB items (stories) to the team to maximize the BV from the team.
And this contract maximizes the ability to change. And reduces ‘early termination’ costs for the client. Typically the vendor should charge a higher rate, since the customer is getting in every other way a great deal.
If I were the client, the first work for the team would be agile release planning, where they helped me establish an initial sense of the scope, dates and costs for the first release or two. But I would understand that this initial plan will change. And largely due to me — due to business side changes. But not only due to that….due to other learnings as well.
Nowadays, the key problem with the real agile contract is often the lawyers. The business guys at the client understand the need to do things this way, but they can’t explain it to the lawyers well enough. So, the contract does not get changed enough. See comment on Larman/Vodde below.
***
Other resources for contracts include earlier blog posts on this topic:
http://www.leanagiletraining.com/blog/agile/agile-contracts-the-poppendiecks/
http://www.leanagiletraining.com/blog/agile-business/agile-contracts-another-resource/
http://www.leanagiletraining.com/blog/agile-business/the-basics-of-agile-contracts/
http://www.leanagiletraining.com/blog/business-value/agile-contracts/
http://www.leanagiletraining.com/blog/better-agile/agile-contracts-question-1/
http://www.leanagiletraining.com/blog/key-problems/joes-real-agile-contract/
***
Some notes:
* The Poppendiecks focus on the larger goals of agile contracts and give you some specific examples of how it worked. How do we get the vendor and the client in alignment, and share risks appropriately?
* Larman and Vodde talk about getting the lawyer(s) in the mindset of agile. The details come out better if the underlying thinking is agile.
* It is of course still true that some people are still stuck on keeping the waterfall contract: scope, date and budget are locked down, and the vendor gets some progress payments based on waterfall ‘deliverables.” So, the first thing is to discuss how this is working for them so far. Typically, not very well. So, gathering some examples of the failures of waterfall contracts might be needed to loosen up the thinking.
