“There are so many men who can figure costs, and so few who can measure value” – Unknown
Contracts, budgets and quotes. These three concepts can send the most ardent agile practitioners running for cover.
Understanding outcomes, value and trust is the key to successfully building an agile contract. Without them, an organisation is naturally constrained in their ability to adapt and leverage a changing market.
- 1 The context of contracts
- 2 A matter of trust
- 3 Developing agile contracts
- 4 Internal funding models
- 5 Conclusion
- 6 References
The context of contracts[edit | edit source]
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 customer will ask a project at some point, agile or not.
- "How much will this cost?"
- "How long will it take?"
- "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 customers are uncomfortable with this approach. This reflects more on the customer than the team, but has often led to the misconception that agile teams are writing themselves a blank cheque.
Let's be clear about the basics first. There is a fundamental relationship between time, cost and scope. To understand this, it can help to visualise your project as a pipeline. The width of the pipe is your team size, the length is the time available to deliver, and the flow is your scope. 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).
We also need to understand that every project has constraints and that these can be important. However, by definition, agile delivery practices put the customer in control of the product and do not constrain scope beyond setting project context at the start. The functionality of a product may evolve as the backlog changes between iterations. Even the agile manifesto states this very clearly; “customer collaboration over contract negotiation”. In other words, the scope of the project is unpredictable.
So what does this mean for contracts? Contracts rely on predictability, I'll pay you X to do Y, which demonstrates a fundamental flaw in how we traditionally build contracts. So for an agile contract, we need to find a different constraint - a different way of agreeing to a commitment.
Let's start where all contracts should start; trust.
A matter of trust[edit | edit source]
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.
- 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.
- 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.
- Identification: This level of trust is created over time where parties have the opportunity to work together and build trust based on personal experiences.
- 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.
Developing agile contracts[edit | edit source]
This brings us to the core of this essay - the contracts themselves. Experience shows that most software contracts come in three forms. Time and materials, outcome based or fixed contracts.
Time and material contracts[edit | edit source]
Time and materials (also known as 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 a user story, 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 the customer chooses to stop.
To understand what this means, it can help to visualise the rate of spending. In the above figure, we track the value of each story against a linear financial spend (fixed team size). In this example the initial stories are of low value, 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 additional controls are needed, 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 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.
Outcome-based contracts[edit | edit source]
Gaining popularity in recent time is the use of outcome-based or performance-based contracts. These are sometimes known as "power by the hour" in reference to the support contracts for aircraft engines that are based on the hours flown rather than fixed or annualised contracts.
The difficulty is defining an outcome which is measurable and mutually acceptable from the financial perspective.
Common examples of outcome-based contracts are Software-as-a-Service and other pay per use models. Referring back to the levels of trust, for outcome-based contracts to be successful, organisations need to be near the top of the trust pyramid at the level of partnerships.
In developing an outcome-based contract you will need to set the following parameters;
- The expected outcome: Fairly obviously you need to define the outcome that you are measuring.
- The outcome measures and levels: How will you measure the performance of the outcome and how are these rated against the contract?
- The payment curve: How will you pay (or be paid) against the performance measures and levels above? Also, are there sufficient incentives to exceed the baseline measure?
- The risks to the outcome: What risks are you willing to accept (especially relating to difficulties in measuring the outcome)?
"Fixed" contracts[edit | edit source]
The fact is that many customers, especially those at the lower levels of the trust pyramid or where there are significant capital costs, require "fixed" contracts. In the standard case this is a combination of fixed cost, time, or scope. Providing fixed quotes can sometimes be compatible with agile, but requires careful attention to manage the flexible component in a way that is reasonable and achievable.
Fixed cost[edit | edit source]
Where your customer asks for a fixed price quote, prior to work commencing, but is flexible on the scope of delivery, and how long it takes.
- For example: Provide operational support and maintenance services.
- How to quote: Identify, and estimate, the approximate user stories in iteration 0. Use this to calculate a first order cost range.
- How to deliver: Keep iterations short as longer iterations have a tendency to cost overruns.
- How to measure: Monitor velocity and burn rate, as these are your key indicators of cost. Adjust scope and time as required.
Fixed time[edit | edit source]
Where your customer asks for final delivery by a specific date, but is flexible in scope and cost.
- For example: Design and print new marketing material for a product launch.
- How to estimate: Using historical velocity data, each team can forecast the number of stories they can deliver by the due date.
- How to deliver: Strictly enforce time-boxes. The duration is defined by a fixed number of iterations, and extending an iteration will push out your final date.
- How to measure: Tracking team and project velocity and/or cycle time.
Fixed scope[edit | edit source]
Where your customer has a fixed set of requirements, but is flexible in the time it takes to deliver, and the cost of delivery.
- For example: Change existing reports to accommodate internal reporting requirements.
- How to plan: Focus on backlog definition and estimation before commencing work, to ensure accurate scope definition.
- How to deliver: Work in predefined, and agreed, backlog order.
- How to measure: Measure how many stories have been accepted so far, and project the rate of acceptance into the future to assess possible delivery dates.
Fixed cost and time[edit | edit source]
Where your customer asks for a fixed price quote, with final delivery due by a specified date. In this situation, the exact set of features, or scope, is flexible.
- For example: Work on an agreed product until the end of the financial year.
- How to quote and estimate: Calculate total cost as cost per week, or cost per iteration – this is one of the simplest types of quotations and fully compatible with agile because you are pricing the project based on what the customer expects and is willing to pay, and not on the potential estimated cost. The cost is effectively budgeted, instead of estimated.
- How to deliver: In addition to the fixed time and cost criteria; regularly maintain the backlog.
- How to measure: Measure how many stories have been accepted so far, and project the rate of acceptance into the future to assess how many stories can be delivered in the available time. Measure the burn-rate to ensure that the costs are in line with the expected budget.
Fixed cost and scope[edit | edit source]
Where your customer asks for a fixed price quote, for a pre-defined set of requirements. In this case, the final date for delivery is flexible.
- For example: Build and deliver a product to architectural specifications.
- How to quote and plan: Increase the contingency (% or $) during iteration 0 to ensure your quote allows for unexpected delays that would affect your cost to deliver.
- How to deliver: In addition to the fixed cost and scope criteria; adjust the final delivery date.
- How to measure: Measure how many stories have been accepted so far, and project the rate of acceptance into the future to assess the possible delivery date for all the accepted stories. Measure the burn-rate to ensure that the costs are in line with the expected budget.
Fixed time and scope[edit | edit source]
Where your customer asks for a fixed set of requirements, with final delivery due by a specified date. In this situation, the total cost to the customer is flexible.
- For example: Fulfilling legal requirements prior to the legal cut-off date.
- How to estimate and plan: During iteration 0, pre-assign requirements by week or iteration to define the scope delivery timetable. Pad the schedule with extra time, to cater for unexpected defects, or technical debt.
- How to deliver: In addition to the criteria in fixed time and fixed scope; increase the team size to ensure the scope is completed on time.
- How to measure: Measure how many stories have been accepted so far, and project the rate of acceptance into the future to assess the possible delivery date for all the accepted stories. Measure the burn-rate and keep the customer informed of the likely final cost of the project.
Fixed cost, time and scope:[edit | edit source]
In this final scenario, your customer gives you no flexibility in the budget, schedule, or scope.
Cancel the work. This is not suitable for agile, and should be run using a traditional framework. Even then it is likely to fail without some flexibility.
But… if you start with a time and materials pilot, you are able to significantly mitigate the risk associated with a later fully fixed contract.
Internal funding models[edit | edit source]
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, that because most finance divisions require business as usual (BAU) budgets and project budgets at least 18 months ahead, it can be difficult to react or proact 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.
Conclusion[edit | edit source]
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.
- Q: "How much is this going to cost?" A: "As much as you’re willing to spend."
- Q: "How long is this going to take?" A: "As long as it takes to deliver what you ask."
- Q: "What am I going to get?" A: "Whatever you tell us you want."
References[edit | edit source]
- Better Work Discussion, Seo, Paper Series No. 2 (2011)
- Overtime Work and Incident Coronary Heart Disease: the Whitehall II Prospective Cohort Study, Virtanen, et al (2010)
- Effect of Overtime Work on Cognitive Function in Automotive Workers, Proctor, et al (1996)
- Effects of Workload and 8- Versus 12-h Workday Duration on Test Battery Performance, MacDonald and Bendak (2000)