Agile Contracting

One of the four values of the Agile Manifesto states that agile teams prefer “Customer collaboration over Contract Negotiation”. Agile software development values and principles are motivated by the basic assumption:

In software projects, customers don’t necessarily know what they want, but they always know exactly what they don’t want.

In other words: in most agile software projects is utterly impossible to determine requirements at the beginning (maybe you can gather 20% of then, at most). So requirements need to be derived as you go. When stakeholders are given a demonstration of part of the work done, then they know exactly if they wanted that or not, and at the same time they reformulate many requirements and give you new ones.

This paradigm is the opposite of the predictive approach, and is good to focus the project on value. The great issue is when the work is not done by inner resources and we need to outsource, in that case we need to sign a contract with a seller. The question is: What type of contract should we sign for an agile project?

We know the answer is not a fix priced contract. What kind of seller is going to commit to fix price-variable scope?

We also can guess that time and materials or cost reimbursable contracts are not ideal. What kind of customer is going to take the overcost risk if project ends up costing a 50% more than budgeted, or even a 100% more?

Let’s try to see this through an example. Let’s say a given customer needs to outsource a project of 20 weeks duration. Scope is going to be derived in collaboration with certain stakeholders throughout the project, but they know there will have to be 4 releases by the end of weeks 5, 10, 15 and 20 each of them valuable for the business because some users will improve their way of doing things. Everybody considers that fair size for the external team should be 4 people full time, having a total estimated effort of 3,200 person-hours (=4 people * 40 hours/week * 20 weeks). Let’s assume 50€/h as a fair hourly rate for these professionals.

With these data, customer could estimate a project budget of 160k€ (3,200 person-hours * 50€/h). If we see the cumulative curve in time, at the end of each release, the amount paid would be of 40, 80, 120 and 160k€, respectively. However, as we said before, no seller is going to sign for a fix price contract if they cannot estimate scope. On the other hand, no customer is going to sign for a time and materials contract of 50€ an hour because final effort could reach 5,000 or maybe 10,000 hours, who knows?

A reasonable approach here could be breaking the project down into big features or epics and then reach an agreement on performance and price for each of them.

The Product Owner could analyze better (with the help of the business stakeholders) and decompose features/epics into user stories. These user stories may change, of course, otherwise this would not be an agile project, but the aim right now is to get a prioritized backlog for the 4 releases. That is, we could produce 4 release backlogs populated with their respective user stories, the earlier the release the deeper details, logically. Next step is to determine the size of the project (with the help of the technical stakeholders) using story points (by means of relative comparisons, not absolute numbers). Let’s say we get an initial project size of 1,000 story points, distributed as 400, 300, 200 and 100 story points for releases 1, 2, 3 and 4, respectively.

With this information the customer could propose several win-win agreement models to the possible sellers. The models introduced by Alistair Cockburn and Jeff Sutherland are quite interesting.

Cockburn proposes, among others, a time & materials model combining hourly rate and story points rate. Let’s see how can we apply it to our example:

  • First of all, it is agreed an hourly rate quite lower than the market rate, let’s say for instance an hourly rate of 15€/h instead of de 50€/h.
  • In order to reach the total budget of 160k€, it is agreed a rate per story point of 112€ per story point = (160000–15*3200)/1000.
  • Customer mitigates the overcost risk: If the final outcome accounts for 1,000 story points, but taking 24 weeks instead of 20, the final project budget would be of 169,600€ (=15*160*24+112*1000). Comparing with a time & materials contract costing 192,000€ (=50*160*24), we see that overcost is reduced from 20% to 6%.
  • Seller mitigates scope change risk and has an incentive to finish earlier: If they finally deliver 1,000 story points in 16 weeks, instead of 20, for instance, the project would cost 150,400€ (=15*160*16+112*1000) being the actual hourly rate of 58.75€/h instead of 50€/h (+18%).

The contract model proposed by Scrum co-author Jeff Sutherland, named after Dire Straits’ song Money for Nothing and Changes for Free is foundamented on encouraging seller’s productivity and customer’s agile behavior:

  • The clause Money for Nothing is applied when the customer wants the contract early finished. This makes sense in agile projects because quite often it is reached a situation in which the next value increments would not be significant. Customer may call this clause if they have honored their role as an agile customer (that is, they have helped solving impediments promptly, they have attended to meetings for backlog grooming, spring planning, they have helped Product Owner to estimate and prioritize, they have provided feedback at sprint demos, etc.). Customer finishes the project early and the seller gets a pre-arranged percentage of the cost for the remaining work. Applying to our example, let’s say customer wants to finish after the 3rd release (15 weeks instead of 20). If prearranged incentive fee is 20%, they would pay 128k€ (=15*160*50+5*160*50*20%) instead of 160k€. Seller would release their resources 5 weeks earlier and their actual hourly rate would be 53.3€/h instead of 50€/h (+7%).
  • The clause Change For Free is applied when customer wants to change a statement of work (SOW) for other of equivalent size: they can do it if they have behaved agile, as explained before, otherwise they would have to pay for the new SOW as a new change. Let’s say in our example that we are on the 2nd release. There is a feature of size 25 story points belonging to the 4th release not very valuable for the customer, but they discover a new feature very interesting of 25 story points. If the customer is behaving agile, this can be changed without a cost. Otherwise (there is a claim from the seller’s part stating the breach of this clause), then the new feature needs to be quoted and price is increased.

This article is also available in Spanish

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.