Do you understand how risk transfers in an Agile contract?
The common thread throughout this series of articles has been the requirement for a fundamentally different approach to be taken to contracting for the use of Agile. It requires both parties to adopt a collaborative approach, which involves a change of culture. Already accepted at a technical level, it is the commercial relationship that now has the greatest need for attention. In this final article we consider how the contract needs to deal with the issue of risk transfer and contractual governance.
Contracts are generally drawn up for the parties by lawyers, whether in-house counsel or externally. Lawyers are a trained to identify the risk in a transaction or project, and then to remove, reduce or mitigate it. In the original article we identified why lawyers therefore represent one of the greatest barriers to the adoption of Agile as a methodology for large, high-profile or high risk projects.
Lawyers play it safe
Lawyers find highly innovative solutions to complex problems, but in doing so they frequently seek to identify where similar risks have occurred before and to apply similar solutions. This reliance on past precedence meant that the original contracts for software development relied on contracts that tackled similar problems, such as engineering and construction contracts. However, the sequential processes used in these contracts, often referred to as "waterfall", does not suit the flexible and collaborative approaches to solution development that are found in Agile methodologies. Drafting an Agile contract therefore requires a fresh approach, in particular to understanding how risk transfers within the contract.
Who bears the risk?
A key aspect of this risk transfer is who ultimately bears the responsibility of whether the solution satisfies the requirements. Arguably no contract is capable of transferring the solution risk to the supplier - legal precedent such as St. Albans UDC v ICL  identifies merely that the supplier must satisfy the customer's requirements as articulated in the specification. However, does financial compensation really provide an adequate compensation for the lack of a solution?
Additionally, the solution risk for the customer lies within its ability to adequately articulate its requirements, for which it may rely on the professional knowledge and experience of the supplier. For the last decade, government contracts have sought to resolve this risk by keeping the expression of the customers' needs and the suppliers' solution separate; the supplier is required to satisfy the former and deliver the latter. The public failure of government projects masks only the fact that similar failures in the private sector are not subject to the same degree of public scrutiny.
By contrast Agile recognises that the parties cannot define all aspects of the requirement and that the solution will change and evolve as the project progresses. To achieve this, the customer is only required to set out its higher level vision for the project with both parties required to share in the solution risk through the discovery phase and during the incremental solution development. Some of the solution risk is also passed to the supplier, who will only be paid for product that delivers a business benefit, through the commercial model.
A cry for stronger governance
One of the harder cultural shifts for the customer to adopt to is the greater involvement it must have in solution development. This can represent a hidden cost for the customer, but it does provide the opportunity to control the direction of the development and even to identify when its requirements have been satisfied. However, particularly for larger projects, it does mean that it must also be prepared to delegate greater decision making authority to its staff who, as stake holders and product owners, should be embedded within the suppliers' development teams.
A collaborative approach is inherently more visible to the customer, with direct involvement in development providing immediate feedback. Agile methodologies are also considered to keep the supplier 'honest' by the need to deliver regular working product to the customer.
Despite this, strong governance is still very important for the success of the project, particularly for Agile projects with any scale, and both parties should be interested in monitoring the progress of each self-directing team. Provisions relating to monitoring, often seen as intrusive and disruptive in waterfall contracts, can therefore have a collaborative advantage in Agile, with each party interested in keeping the project aligned to the vision.
The requirement for contractual flexibility that has been described in these articles forms a key feature that must be articulated in an Agile contract. This flexibility is not found in traditional engineering or construction contracts, with their process-orientated drafting for the delivery of fixed solutions, such as building a school or a car. Agile requires the creation of new provisions to govern the necessary collaboration between the parties and allow for the fair allocation and sharing of risk. Drafting for Agile is the disruptive technology for commercial contracts.