Contracting for Agile Software Development

One of the four core values declared in the 2001 Agile Manifesto, the cornerstone of the agile movement, was “customer collaboration over contract negotiation”. This does not mean that contracts should not be negotiated or concluded. Rather, it is a rejection of the traditional method of contracting for waterfall projects which fixates on detail requirements specification and fails to address their frequent changes. 

When writing a contract for an agile software development project, it is important to remember that “agile” is an umbrella term for several frameworks including Scrum, Kanban, Extreme Programming (XP) or Lean Methodology. Even these frameworks are often used as a starting point only and are modified to suit the needs of an individual project. While there are important differences between these frameworks, they all have one thing in common: a detailed description of the final output does not exist at the start of the project when the contract is signed, and evolves in parallel with the implementation work.

This article focuses on how to address the issue of scope definition in a way that recognises its role as the subject matter and purpose of the contract, as well as its ever-changing nature.

Time and materials (T&M) arrangements appear to be a straightforward answer to the assumption that the output specification is to be defined later. In a T&M arrangement, the supplier works under the customer’s directions. The risks resulting from the lack of scope definition are borne by the customer. When considered together with the inherent risk of poor quality and low performance, a pure T&M model without additional safeguards is unacceptable to many customers.       

The fixed-price-per-sprint (or development cycle) model was formulated in an effort to reconcile the constantly evolving scope specification with the desire to pay for value delivered rather than time spent. This model builds on the fact that, even within an agile framework, the scope to be completed in the near future (ie, in the next development cycle) can be defined and estimated with a high degree of certainty. Use of this approach is understandably limited to frameworks which use sufficiently long development cycles (eg, Scrum). Where this model is adopted, it is important to set it up in a manner that does not create an administrative burden.

None of the models discussed so far provide the customer with a guarantee of delivering the entire solution for a set price. To create conditions in which these guarantees can be reasonably expected and given, the contract needs to both anticipate a final output and support dynamic changes to its specification.

There are several ways in which this may be addressed. One possible approach is to define the final output through Project (or Product) Vision together with the expected functionality blocks (in Scrum Theme and/or Epics), and agree on scope governance. Project Vision describes the overarching goals and intended benefits of the output and will create “security boundaries” of future changes to the scope of the project. Functionality blocks represent a high-level description of the requirements which are to be later broken down into smaller work items (in Scrum User Stories). These two elements provide the greatest possible consensus and understanding for both parties, while acknowledging the uncertainty inherent to an agile development model.

In the next step, a complete list of work items is created for at least one representative functionality block. Agile methodologies expect this list of work items to be prepared by the customer. In practice, the customer is often assisted in work items definition and specification either by the supplier or by a professional product owner. After the complexity of delivering such work items has been estimated, these estimates are used to scope the full list of functionality blocks by analogy. This results in an educated appraisal of the total effort required to deliver the solution within the boundaries of its vision and functionality blocks.

A high-level scope description should always be accompanied by a contractually binding scope governance process. A working process of scope governance that suits and is adhered to in the project’s day-to-day reality is the difference between a successful and failed agile-fixed price model. This process addresses both the continuous requirements specification within the given boundaries and the response to scope specification change. To honour the fixed-price model, the change procedure typically favours outcomes that do not impact on total price, such as simplification or elimination of other, less important, features of the output or mutual exchange of equally complex features.

It is certainly possible to have all the elements of a fixed-price agile contract in place before the project starts. However, even from the brief description of the considerations around scope definition, it is clear that a significant amount of effort is required in parallel with contract negotiation. A viable alternative that supports an efficient project start is use of an initial checkpoint phase. A time-limited checkpoint phase is typically organised on a T&M basis, and is used to create a high-level scope definition and to refine the scope governance process, both of which are subsequently embodied in a contract.

Agile development frameworks and guarantees of timely delivery of a quality solution within an agreed price range are not mutually exclusive. For contracts to serve the parties, it must be recognised that agile contracts need to be constructed differently. Rather than describing the output in detail, they need to focus on parties’ interactions and expected quality standards.