Agile Contracts

“There are so many men who can figure costs, and so few who can measure value” – Unknown

How much does this cost? This is the question that every manager is asked at some point. We hope that you realise that it’s the wrong question. The real question is: What is it worth?

These four words are probably the most important four words you can ask in your organisation. And when it comes to external vendor contracts, these four words are incredibly hard to both ask and answer.

Writing a contract with a vendor in an agile organisation can be incredibly difficult. To clarify, we’re not talking about a contract for specific goods (use a price per widget or fixed price) or contracts for individual contractors (use time and materials); those don’t really change. But when you’re contracting a third party to deliver work or a product for you, the traditional contract of fixed price, time, and scope won’t work. That’s partly because the work is highly variable but also because you have designed your teams around delivering outcomes.

Fundamentally, a contract is defined by the level of risk each party is willing to accept. To manage this risk, there are three questions that every organisation will ask at some point:

1. How much will this cost?
2. How long will it take?
3. What am I going to get?

And while “as much as you’re willing to spend”, “as long as necessary”, and “whatever you ask for” are sometimes acceptable answers, many organisations are uncomfortable with this approach. This reflects more on the organisation than the vendor but has often led to the misconception that teams are writing themselves blank cheques.

Let’s first be clear about the basics. There is a fundamental relationship between time, cost, and scope. To understand this, it can help to visualise any work as a pipe. The width of the pipe is your team size, the length of the pipe is the time available to deliver, and the flow is your scope. If you’re engaging a vendor team to deliver an ongoing outcome, then time is not really a constraint. However, if you’re engaging them to provide short-term services, it may be.

Therefore, any variations require one of these three variables to change. Effectively, and simplistically, you have three options: increase capacity (cost), increase duration (time), or drop requirement (scope). 

Overtime isn’t a solution, as current research suggests that long-term, sustained^{[1, 2, 3, 4]},overtime leads to a significant reduction in productivity.

So, what does this mean for contracts? Traditional contracts rely on predictability — I’ll pay you X to do Y — which demonstrates a fundamental flaw in how you traditionally build contracts. So, you need to find a different constraint, a different way of agreeing to a commitment. Experience shows that most software contacts come in three forms: time and materials, outcome based, or fixed contracts.

Time and material contracts

Time and materials (T&M) is the most agile contract model and provides the greatest flexibility to change, scale, and adapt on demand. If you are able to identify and prioritise the value of any unit of work, a T&M contract gives you the flexibility to stop work (or at least trigger the contract closure clauses) when the cost of delivery is greater than the value of what is delivered. In other words, work should continue until you choose to stop.

To understand what this means, it can help to visualise the rate of spend. In the above figure, we track the value of work against a linear financial spend (fixed team size). In this example, the initial work is of low value (but necessary to enable the later, high-value pieces of work to be done at all), followed by low-effort yet high-value tasks, followed by the lower-value and harder tasks. In this case, it is very easy to see where the T&M contract should come to an end as the value diminishes against the cost.

If you need additional controls, you can create a capped T&M contract, which limits financial spend to a fixed amount. It’s important to ensure that the cap is high enough so that the overall return on investment is positive. You can also introduce a guaranteed minimum spend or delivery bonuses to encourage productivity in the team. However, be wary of incentivising the wrong behaviour.

Outcome-based contracts

Outcome-based or performance-based contracts are gaining popularity. These are sometimes known as “power by the hour” in reference to the support contracts for aircraft engines that are based on hours flown rather than fixed or annualised contracts.

The terms and measures in this contract should directly relate to business outcomes. However, do not underestimate the difficulty inherent in agreeing on a mutually acceptable financial model. Common examples of outcome-based contracts are software-as-a-service (Saas) and other pay-per-use models. In developing the contract you will need to define the the expected outcome and the the outcome measures and levels (how will you measure the performance of the outcome and how are these rated against the contract).

In the contract you’ll also need to define the payment curve (how will you pay, or be paid, against the performance measures), incentives to exceed the baseline measure, and the acceptable level of risk to the outcome.

Mirko Kleiner has an approach he calls “lean-agile procurement”, which uses a lean procurement canvas to identify shared goals and outcomes, find alignment on the way of working, and rapidly agree to either work with a vendor or part ways.

"Fixed" contracts

Sadly, many organisations will still require fixed contracts, especially where there are significant capital costs. In a traditional project, this would be a combination of fixed cost, time, or scope. In the worst case, all three would be fixed. Providing fixed quotes can sometimes be compatible with an agile approach but this requires careful attention to manage the flexible component in a way that is reasonable and achievable.

• Fixed cost — This is a capped contract where the vendor provides services up to a price. What they do and how long it takes is completely flexible.
• Fixed time — If a specific unit of work needs to be done in a specific time frame (e.g. before the end of the financial year or product launch), a fixed-time contract may be appropriate.
• Fixed cost and time — This is the most common type of fixed contract in an agile environment: a contracted team, supplementing the existing team, hired for a limited period of time at a fixed cost.

Where possible, avoid fixed scope in any combination unless the work is short or obvious. In place of scope constraints, incorporate other constraints into the contract terms. For example:

• quality constraints (e.g., defect injection rate),
• MTTR (mean time to recover),
• ROI (maintaining a positive effort-to-value ratio, similar to the T&M example above),
• MVP (minimum viable product; a limited scope constraint that should be no more than 20% of the total contract size), or
• productivity improvements (a small, incremental increase in productivity measures over time).

All these approaches fundamentally come down to the core principle of managing risk. Your contract terms are going to be set by the level of risk each party is willing to accept. In an agile organisation, avoid a contract that overly constrains a partnership where the risk is already low or is acceptable.

Internal funding models

So far we’ve covered how to create an agile contract in the context of two separate organisations. It’s also possible to use these approaches to structure a funding model if the work is being undertaken internally.

Be aware though, if your finance division requires business as usual (BAU) budgets and project budgets at least 18 months ahead, it can be difficult to react to opportunities in the market in an agile context.

I’d like to leave you with one final approach for internally funded projects – change the question. When business cases are raised for new projects – don’t base your budget on “How much will it cost”, but rather “How much is it worth”. By putting to benefits at the fore, and delivering an agile scope, projects can focus on what is most important – business value.

A matter of trust

However, none of this is relevant without trust between the parties. In large part, the form and flexibility of a contract between parties depends on the level of trust that exists between them. This can be defined across four distinct levels.

1. Reference: This is the lowest form of trust and exists where trust between the parties is based on the reference of a mutually trusted third party.
2. Contract: This is the most common level of trust, and the majority of relationships do not extend beyond this. This exists where parties create legally binding contracts as the core mechanism to enable trust between them.
3. Identification: This level of trust is created over time where parties have the opportunity to work together and build trust based on personal experiences.
4. Partnership: This is the highest level of trust between two parties and exists when both parties share the same goals and outcomes. This may take the form of a strategic partnership or similar structure.

Understanding the levels of trust is essential in developing agile contracts.

Conclusion

Fundamentally all these approaches come down to core principle of managing risk. Your contract terms are going to be set by the level of risk each party is willing to accept. In an agile context, what you want to avoid is the situation where a contract overly constrains a partnership where the risk is already low or can be accepted.

Given what we know now, let's go back and answer the original three questions.

1. Q: "How much is this going to cost?" A: "As much as you’re willing to spend."
2. Q: "How long is this going to take?" A: "As long as it takes to deliver what you ask."
3. Q: "What am I going to get?" A: "Whatever you tell us you want."

References

1. Better Work Discussion, Seo, Paper Series No. 2 (2011)
2. Overtime Work and Incident Coronary Heart Disease: the Whitehall II Prospective Cohort Study, Virtanen, et al (2010)
3. Effect of Overtime Work on Cognitive Function in Automotive Workers, Proctor, et al (1996)
4. Effects of Workload and 8- Versus 12-h Workday Duration on Test Battery Performance, MacDonald and Bendak (2000)