Agile Contracts: Reaching an Agreement

Chris O’Brien, Datacom Systems Limited, https://datacom.com/

This article is an extract of the playbook “Preparing for agile success”. This playbook answers questions that are likely to arise while navigating the acquisition, execution, and transition to support of agile-delivered solutions. It is hoped this guide will assist buyers and suppliers to reduce cost, time, and friction while helping them to build effective collaborative relationships and deliver greater value.

What are the trade offs in contracting for an agile-based project?

Agile gives the buyer extraordinary freedom to adapt to what is discovered during delivery, but this freedom to guide the solution direction makes the buyer ultimately accountable for business outcomes. This is quite different from a traditional contract where risk and responsibility for what is delivered (and when) are typically shifted to the supplier. The supplier still has important obligations to be engaged with the process and provide services of a sound professional standard under agile, but warranties as to specific business outcomes cannot be reasonably required of a supplier.

Agile deliveries rely heavily on collaboration and demonstration during the project to enable the buyer to have a high level of control and be able to make quick decisions on matters such as solution direction and the acceptance of work. However, this means the buyer should not contractually require the supplier to take the risk on items that it doesn’t fully control, for example, achieving functionality by fixed milestones, gates and deliverables that may have framed the supplier’s obligations in traditional contracts.

Effective agile-based projects are likely to defer much of the detailed specification and design until later in the delivery, as a natural part of iterative solution development. This approach can lower the upfront costs for buyers and decrease the financial risk if the buyer decides to cancel the project or radically change its direction.

By focusing on delivering small working increments of the final product, agile principles encourage the regular demonstration of valuable, working, integrated slices of the solution (known as increments). This gives the buyer continuous visibility and control of the evolving outcomes and the agile process itself. With those benefits come new obligations for the buyer to address issues as soon as they arise, rather than relying on downstream mechanisms.

Traditional contracts typically allocate commercial risk to the supplier and may provide remedies such as liquidated damages and retentions to address issues. These constructs are not well suited for an agile delivery where the buyer’s commercial protections result from their control of what work is carried out (and when), having earlier visibility of delivered value in the sprints, and being able to address concerns as they arise (rather than at the end). In the event of serious failure and disagreement, rights usually remain for the buyer to withhold payment, to use dispute resolution, and to ultimately terminate the services if necessary.

Some parts of a traditional contract will be different for an agile delivery, and buyers and suppliers will need to be aware of these differences.

Should the contract include detail about what agile is?

The contract needs enough detail on the agile approach so there is a common understanding of what things mean and how everyone will work. A reference to an authoritative source (such as the Scrum Guide) can be useful in setting baseline expectations and as the foundation for an agreed and documented agile delivery framework.

It is important to confirm the expectation for achievement of the key characteristics and principles of agile that are considered essential for success and any differences that have been agreed. For example, whether the teams will be cross-functional and whether co-location will be used.

As the parties work together and learn from applying the agile method, they may wish to adapt the agreed framework. The contract should make clear how the parties will manage and record changes to the approach.

To make the contract readable, it is useful to define basic terms (for example, sprint, backlog, user story, sprint planning, retrospective, time box, and velocity) and how these fit together into the planned sequence of agile events. Avoid being too detailed and prescriptive so the method can adapt without having to change the contract.

Also include definitions for the agile roles (product owner, scrum master, agile coach). Separately, it is important to describe the specific responsibilities of the agile roles, the party providing those roles, and the name of the person performing the function (where they are key positions).

If there are parts of the agile process that are important to you — either because they are different from usual agile practice, have a more significant consequence, or are just more complex — then it would be best to clarify those with the other party before signing the contract and, if necessary, write them into the agreement.

The description of the agile framework can be in the main body of the contract, in an approach section, in a schedule, or in a separate document that is incorporated into the agreement — it depends on the form of contract.

Can an agile delivery contract provide a fixed scope by a fixed date for a fixed price?

An agile delivery may have a fixed price and duration, but the scope to be delivered will vary as priorities change and as features are added or removed to ensure that the fixed time and cost constraints are met. If fixed scope, duration, and price are required, agile delivery may not be the best approach to use (see ‘Is this the right project to deliver using an agile framework?’)

If the buyer wishes to have an agile delivery with a fixed duration, price, and scope, the significant risks this creates will need to be treated. Mitigation approaches that could be used include ensuring:

• Both parties are satisfied with the quality of the initial product backlog, generally through a period of funded collaborative work to confirm this

• Both parties agree the time and money available appear to be sufficient to deliver all the backlog items and nonfunctional requirements, but with a clear understanding that requirements that are not must-haves (perhaps a significant proportion of the requirements) may not be delivered

• Reasonable time and money are included in the price to mitigate risks that the velocity (rate of delivery) might be less than expected, or discovered scope and complexity might be greater than expected

• Activities that lack sufficient clarity and understanding to be reasonably estimated are outside of the fixed price/time/scope

• The buyer has committed to supply the essential aspects of the agile process that strongly influence velocity, such as effective and engaged personnel in the product owner and supporting roles.

Can agile be used for delivery within a traditional project approach?

Traditionally projects are required to implement a fixed set of detailed requirements and designs developed at the beginning and to transition the solution to productive use through formal acceptance at the end.

Increasingly, however, there is a trend for these plan-driven projects to adopt some practices borrowed from agile frameworks during delivery. For example, they may place work items on a backlog, have a kanban board, run sprints, and use regular stand-up meetings. Note that there is a spectrum of hybrid and quasi-agile delivery approaches. Colloquially these are known by names such as water-scrum-fall and wagile.

Projects should be encouraged to adopt useful techniques regardless of where they come from. However, considerable risk is created for the buyer and supplier if these techniques are mistaken for actual agile delivery - to be clear, the use of inauthentic agile implementation is not recommended.

A traditional project uses detailed requirements and tight control of change to attempt to support the allocation of risk from the buyer to the supplier. These characteristics are quite different from agile,

where the buyer retains risk in exchange for being able to start with a much less welldefined specification of the solution and to control its direction as a result of close involvement with its development.

Parties need to openly confront and address the conflicting characteristics of the approaches. For example, how can a buyer specify the priority of work under agile when the supplier also needs to do this to meet its contracted obligations using a traditional delivery?

In a highly collaborative engagement, where both parties have a very mature understanding of the conflicts and a commitment to achieve an authentic agile delivery, it is possible to manage the boundaries between the different approaches. If this management is difficult to achieve, however, it may be better to accept that the project is actually a traditional delivery (even if it utilises some practices borrowed from agile frameworks). Communicate clearly to all stakeholders, and structure the project and contract accordingly.

Also see ‘Is this the right project to deliver using an agile framework?’ above.

How are agile projects paid for?

There are many ways that agile delivery can be acquired. A buyer may purchase complete teams, individuals, or a service. These can deliver variable scope on a fixed-price basis, using time and materials (capped or not), or some combination. Payments can be based on completed sprints (the regular cycles of development and delivery) but may also be driven by other calendar dates, deployments, or any event that the parties believe is a fair milestone that is within their control.

Commercial advisors should remember these are just charging mechanisms that do not define the underlying principles in agile — time and money are constrained, and the scope of delivered functionality will be adjusted to fit within these constraints. (Also see ‘Can an agile delivery contract provide a fixed scope by a fixed date for a fixed price?’ above).

Who is responsible for delivery, and how do we allocate risk for agile delivery in a contract?

As with any contract, it is useful to understand each party’s responsibilities, which set the expectations about allocating risk. In an agile delivery, the following responsibilities and risk allocation would normally apply:

• The supplier is responsible for the quality of the resources it provides and their professional standards - the risk of reasonable quality in its personnel and their work is owned by the supplier

• The buyer is responsible for defining what it wants and the priority with which available time and money will be assigned to those needs (through the product owner role)

• Both parties are responsible for the appropriate performance of their individual roles within the agreed agile framework.

Because the agile delivery relies on both the buyer and supplier’s performance of their responsibilities, apportioning risk and liability is often more difficult in a contract for agile delivery.

Who has responsibility for productivity?

Productivity can be considered as the ratio between the value produced and the cost of producing it. This ratio will vary depending on the nature of the inputs, the nature of the technical and delivery processes, and the nature of the environment involved in creating the outputs.

The buyer is likely to have significant influence over the inputs, and the supplier is likely to have most control over the technical and delivery processes. Each party is responsible for the environment and the performance of their roles in the agile-based delivery process. So, in a project using agile delivery methods, both the buyer and supplier are jointly responsible for productivity.

Factors beyond the direct control of either party may also influence productivity, for example, complexity of the problem domain, the need to use specific technologies, and the extent to which participants rely on effective support from other organisational teams.

Agile frameworks have very useful mechanisms to provide early visibility of productivity, and to allow the parties to consider changes to address issues and take advantage of opportunities.

How will change be managed?

A sound agile implementation allows changes in priority and value to be managed by the product owner.

For other changes, the contract should describe the product owner’s responsibilities to exercise formal change control (similar to what one might expect on a traditional project delivery), where the project deviates significantly from its initial objectives or vision, or where any minimum product functionality may not be achieved.

The contract should also describe the mechanisms under which the number of agile iterations (and associated costs) may be increased or decreased, for example, reducing requirements or bringing the project to an early end.

How will we know we are getting value for money from the agile delivery?

Value for money is an important consideration for any delivery project, including agile delivery, and should be considered during supplier selection (see the section ‘Getting started’ above).

While price is one aspect of value for money, it is not the only factor. For example, a supplier may be chosen because they demonstrate during an early engagement they are easy to work with and have the best capability to achieve the vision, even though they are not the lowest cost.

Buyers and suppliers should agree indicators for the key aspects of value for money used in the procurement so they can be monitored during the delivery. Well-applied agile methods should provide iterative value through work completed in each cycle and enable rapid feedback that will aid monitoring of value delivered. Formal activities and events during the agile delivery process can be used to openly surface issues and address them, such as regular reviews, retrospectives, and reporting on planned-versus-achieved backlog items in each iteration. Contracts can refer to those activities and events as part of the reporting regime or in the general description of the agile process.

Good governance plays a role in supporting the achievement of value for money, by ensuring clarity of purpose, by providing effective oversight of escalated risks and issues, by making timely decisions, and by removing obstacles to the project’s performance that are outside the project’s direct control.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International Licence.

Related articles

Finding a Partner to Trust: The Agile RFP

Requirements for Outsourcing

Agile Requirements

More Agile and Project Management Knowledge

Scrum Expert

Project Management Planet

---

Click here to view the complete list of Methods & Tools articles

This article was published in March 2021