28.3 Guidance on how to structure an agile contract
Structuring a contract that is suitable when working with agile does not necessarily involve creating a completely new type of contract. Existing contract frameworks currently being used by organizations may still be suitable to a large extent (e.g. as a master agreement). However, change will be needed at the lower levels in order to work in a more agile way (e.g. in a statement of work (or SOW), which may apply to a period of time, such as a sprint or a release).
When using agile, structuring a contract according to the following guidelines is likely to be more beneficial to both parties than using a traditional style of contract:
- If possible, make the focus of what is being delivered ‘outcome-based’ in preference to ‘output-based’. An output focus is typically about a product or solution that either is, or is not, as specified. An outcome focus relates to the benefits and value that a project enables. This allows the customer and supplier to work together to create an output (or product) that can be changed and adjusted throughout the course of the project, in order to deliver something more valuable if the opportunity arises. There is a difficulty with outcome-based contracts in that outcomes can be hard to define objectively (see section 9.4.1, Defining value) and if this is the case, then a middle ground between outcome and output is to use such things as service levels or throughputs (e.g. velocity), while still allowing the customer and supplier to respond to change in order to optimize the value delivered.
- Define the level of customer involvement needed during the project. This would take the form of how much time would be committed to the project by the customer so that the supplier can benefit from the collaborative working relationship. This is likely to take the form of named individuals from a variety of levels with clearly defined roles and responsibilities. When working in an agile way, a collaborative relationship between the customer and supplier is an essential ingredient that helps with many things such as speed of decision-making, accuracy of deliverables and ultimately the ownership of the products delivered. Agreeing the level of commitment in advance and clearly defining responsibilities increase the chance that this collaboration will happen.
- Create several time-based deliveries as part of the main agreement (e.g. based around sprints or releases), which can be used to monitor the overall project against an agreed baseline that relates to the value the project should deliver. This may, or may not, be put into operational use, but it will show how much is being delivered by the supplier, and it can be measured according to, for example, value, velocity or story points. This allows the customer to see how the project is progressing. In effect the customer is buying amounts of time (or a throughput of work) from the supplier. It may be appropriate to create an initial delivery that goes into more detail of what the project intends to achieve (e.g. this may include requirements-gathering and/or a prototype).
- Allow for the project to be stopped at any time by the project board. This allows the customer to stop a project if feedback from early deliveries indicates that the project as a whole is no longer viable. This will not be seen by the supplier as breaking an agreement, as this is always a possibility with this form of contract and the supplier is fully aware of it from the start. Further to this, most existing contracts have early termination clauses anyway. This does not preclude the contract from being fixed-price, although the full price will only be relevant if the project runs to completion.
Sometimes sprint zero (or early sprints) can be used for the initial delivery. (Also referred to as iteration zero or discovery.)
|Delivery target||Amount received||Customer credit|
90% or greater
100% (or more)
80% to 90%
70% to 80%
60% to 70%
Table 28.1 Sliding-scale incentives
|Level of trust||Composition of the incentive scheme|
No need to incentivize.
Incentives for amount delivered and shortfalls used as credits for use on future work (see column 3 in Table 28.1).
Incentives acting more as penalty clauses (although the supplier may be happy with this arrangement).
Table 28.2 Levels of trust and incentives
- Incentives can be linked to the amount delivered. If the supplier delivers everything that was intended during a particular timeframe, then they receive 100 per cent (or even 100 per cent +) of the remuneration agreed. Lesser deliveries could then be on a sliding scale as shown in Table 28.1.
The composition of an incentive scheme would depend on the level of trust and collaboration between the customer and supplier, which may take the form of schemes shown in Table 28.2.
An incentive scheme can be seen as a penalty clause depending on the nature of the relationship. If the incentives are linked to throughput (e.g. velocity) this can create a mutually beneficial situation; although trust plays an important part here as throughput can be manipulated (e.g. the supplier inflates the story points used for estimation or delivers more features by focusing on easier, less critical ones – sometimes this is referred to as ‘gaming’). If the incentives are related to outcomes and value delivered, the risk of ‘gaming’ is reduced.
- Requirements will be defined in the contract at a high or intermediate level, but not in detail. If the requirements are not specified in detail from the start, this allows for the correct products to emerge during the course of the project without the need to control and change the baseline created during project initiation, which may form part of the contract.
- Requirements need to be prioritized so that the most important in terms of value are delivered, and the least important can be used as contingency in order to protect the quality of what is delivered and also to meet deadlines. A minimum viable product (MVP) is also likely to be described. The level of trust is important with respect to the MVP as this may represent a ‘material breach’ and a failure to deliver. Alternatively, it could still be classed as ‘best endeavours’, in that what the customer and supplier set out to achieve did not actually turn out to be possible.
- Requirements change is handled by ‘trading’ new ones for existing ones (see section 25.5; for example, any new requirements discovered during the project can be added to the requirements list, but the effort needed to satisfy the new requirement will be at the expense of other requirements that are either given a lower place in the order of priorities or removed from the list altogether.
- Depending on the level of trust between the customer and the supplier, it may be agreeable to create a contract using as few clauses as possible and then add clauses when needed (in effect this represents a ‘minimum viable contract’). This is counter to the usual approach of starting with many clauses and removing the ones that are not needed. However, it is the quality of the clauses that is the most important consideration and not the quantity (e.g. specification of who owns the intellectual property of the output).
In summary, the guidelines for structuring a contract for use in an agile context are as follows:
- Focus on outcomes or throughput in preference to outputs.
- Define the amount of customer involvement required in order to collaborate with the supplier in the best way.
- Buy amounts of time relating to timeboxes with deliverables.
- Allow for a premature end to the project.
- Relate incentives to the amount delivered (value or throughput).
- Avoid including detailed requirements.
- Prioritize the requirements and identify an MVP.
- Handle changing requirements by trading out the less important ones.
- If preferred, build a contract up from the ‘minimum’ to start with.