Hire Agile Projects

One of the four values ​​of the Agile Manifesto states that agile teams prefer customer collaboration over contractual negotiation. The principles and values ​​of agile software development are motivated by a core assumption:

“In software, the customer doesn’t know what he wants, but he does know what he doesn’t want.”

In other words, in most software projects it is impossible to determine more than 20% of the requirements at the beginning, so they have to be derived as the project progresses. When stakeholders receive a demo of part of the work, they immediately know whether it is what they wanted or not, and they take the opportunity to reformulate the requirements or add new ones.

This paradigm, contrary to the predictive approach, is very good for focusing the project according to value. The major drawback, however, is found when the development does not have to be done with in-house resources, but has to be outsourced, which implies that a contract must be signed with a supplier. The question now is: what type of contract should be signed in an agile project?

We know the answer is not a fixed-price contract (aka, lock-in, lump sum, etc.). What vendor is going to commit to a fixed price without knowing the scope?

We can also conclude that time-and-materials contracts or cost-reimbursable contracts will not be suitable either. What client is going to assume the risk of cost overruns if the project ends up costing 50% or 100% more (double) than budgeted?

Let’s try to see this with an example. Suppose a client has to contract a project that should be finished in 20 weeks. While the scope is not determined because it must be deduced by collaborating with certain stakeholders as the project progresses, it is known that there will be four production releases at the end of weeks 5, 10, 15 and 20, each of them with value for the business because certain users will change their way of doing things. It is known that the external team would be well-sized with 4 full-time people, obtaining a total estimated effort of 3200 person-hours (=4x40x20). Suppose that the average market rate for these professionals is 50€/h.

With this data, the client could now estimate a budget of €160k (3200 person-hours x €50/h). If projected over time, at the end of each release they would have paid €40, €80, €120 and €160k, respectively. However, as mentioned above, no supplier is going to sign a contract for a fixed price if the scope cannot be predetermined. On the other hand, the client is not going to sign a contract for time and materials at €50 per hour because it might end up being 5,000 or even 10,000 hours, who knows.

The advisable approach here would be to break down the project into modules, or large functionalities, or epics, which is the only thing that can be known at this point, and try to agree on performance and price for each of them.

The Product Owner could go deeper (with the help of business stakeholders) by breaking down the epics into user stories. These stories can change, of course, otherwise it wouldn’t be an agile project, the goal now is to get to a prioritized product backlog for the 4 releases. That is, we could have 4 release backlogs with their respective user stories, more detailed in the first release than in the last, logically.

The project size could then be estimated (with the help of technical stakeholders) in story points (in relative, not absolute terms). Let’s assume that the initial project size is 1000 story points spread across the 4 releases in 400, 300, 200 and 100 story points respectively.

With this information, the client could propose to potential suppliers various models of mutually beneficial contractual agreements. I find the models presented by Alistair Cockburn and Jeff Sutherland very interesting.

Cockburn proposes, among others, a time and materials contract model combining hourly pricing and story point pricing. Let’s see how it would be applied to the example:

• An average hourly rate is agreed upon that is significantly lower than the market rate, say for example €15/h instead of €50/h.
• A rate per story point is agreed upon to cover the total budget of €160k. That is, €112/story point = (160000-15×3200)/1000.
• The client mitigates their risk of deviation due to cost overruns: If 1000 story points are finally delivered, but taking say 24 weeks instead of 20, the project would cost €169,600 (=15x160x24+112×1000). Comparing this to a time and materials contract, which would have cost €192,000 (=50x160x24), we see that the cost overrun has been reduced from 20% to 6%.
• The provider mitigates the risk of scope changes and has a motivation to finish sooner: If he finally finishes 1000 story points in 16 weeks, instead of 20, the project would cost €150,400 (=15x160x16+112×1000) so his average rate goes up from €50/h to €58.75/h (18% more).

The contract model proposed by Scrum co-author Jeff Sutherland, called Money for Nothing and Changes for Free (after the Dire Straits song), is based on encouraging the supplier to finish early and the customer to behave in an agile manner:

• The Money for Nothing clause applies when the client wants to end the contract early. This makes a lot of sense in agile projects because there comes a point when the incremental value that the following sprints would bring no longer justifies their cost. The client can apply this clause if they have fulfilled their role in the agile project (resolved impediments promptly, attended grooming meetings, sprint planning, helped estimate and prioritize, gave feedback in demos, etc.). The client ends the project and the vendor receives a pre-agreed percentage of the amount of the outstanding work. Applied to our example, let’s say the client wants to end the project after the third release (15 weeks instead of 20). If the agreed percentage is 20%, they would pay €128k (=15x160x50+5x160x50x20%) instead of €160k. The provider releases its resources 5 weeks earlier and its rate rises from €50 to €53.3 (7% more).

• The Change For Free clause applies when the customer wants to change a work order for an equivalent one: they can do so at no cost if, as in the previous case, they have correctly exercised their role as a collaborating stakeholder in the agile project. Otherwise, they must pay for the new work order like any change in scope. Let’s imagine in our example that we are halfway through the second release and there is an epic of 25 story points in the last release in which the customer is no longer interested, but has discovered another feature that also measures 25 story points. If the customer is behaving as expected, then it can be rescheduled at no cost. Otherwise (there is evidence of a claim from the supplier for non-compliance with this clause) the unwanted feature continues to be paid for and the new feature is quoted and the price increases.