Contracts for Agile Outsourcing

The question of how to frame contracts and customer/supplier relationships for an agile project is a tough one. To use some patterns terminology, the fundamental 'forces' are:-

1. The customer wants to be sure that they will get value for money


2. The supplier wants to know what they need to do to get paid


3. Agile tells us that we cant specify systems well, so we need to 'embrace change' and minimise the cost of making changes mid-course.

Force 3 is not a big issue for the customer, but will make suppliers used to 'Big Design Up Front' (BDUF) pretty uncomfortable since it is making the commitment rather open-ended and conflicting with force 2.

One possible way to resolve the forces is with a time and materials (T&M) contract. This resolves forces 2 & 3 from the supplier's perspective nicely, but at a first glance, is not a good answer for force 1. In practice, it is not so bad as it seems, - if iteration cycles are kept short and real value is delivered during each iteration then the customer is protected by a rapid feedback mechanism to ensure that things are on a productive track (even if it is not the same track which was envisioned at the start!).

Life isnt always like that though and sometimes customer purchasing policy may insist on fixed price contracts. So what do we do then?

One variation on the fixed price contract is the fixed effort contract in which the supplier commits to providing a specified number of man days to the project. This may be thought of as T&M in fixed price clothing, so its resolution of the forces is similar to those of T&M, with the additional benefit of keeping the purchasing department happy.

Then there are customers who insist on fixed price AND fixed scope. This is a tricky situation to reconcile with agile, because 'fixed scope' sounds a lot like BDUF, which is exactly what Agile tells us we don't know how to do well. On the face of it then, the customer's expectations of Agile and fixed scope are contradictory, so how does a supplier cope? Well, there are several possibilities:-

• Accept the business and the risk of unscoped changes. This may be acceptable where the customer and supplier have a track record with each other and are comfortable that the risk can be assessed.


• Say 'no thanks' and walk away. This doesnt happen very often in my experience. Maybe it should!


• Adopt a two-tiered approach to requirements and agility in which 'broad brush' high level requirements (epic user stories?) are used to fix scope but at a detailed user story level, agile practices are followed.


• Allocating a fixed size change budget which the customer can spend during the period of the project, although this does require impact assessment or detailed tracking of activity for each change, both of which may be counter to the spirit of 'embrace change'

And finally, when you really know your stuff, there are customers who want a fixed price and business benefit-related payments. This needs the supplier to at least be able to size the work up front without any commitent to a scope (correct or not) from the customer. The commitment here from the supplier's side is so open-ended that the he must be really sure that he knows both the business and the customer. My feeling on this is that Agile is actually very well suited to such a scenario - in this case the rapid feedback mechanism which I described earlier will help the supplier to pick up problems early, although his options for resolving them without affecting the bottom line may be limited. Clearly it is better if the benefit measurement can be broken down into the same short iterations that the delivery is broken into, so that tracking is clear and course corrections can be done quickly. Tom and Kai Gilb's article on Incremental value delivery and measurement includes some very relevant advice for suppliers and customers who are using value-based payments.