In this article, we will discuss what you need to consider if you get into a dispute concerning an agile project. We have previously discussed agile contracting in a series of articles (here, here, and here) touching on the basics of contracting for an agile IT project, examining this in greater detail from a customer’s perspective, and looking into hybrid alternatives to pure agile methodology.
In our previous articles we explained the uncertain nature of agile projects. This uncertain nature not only makes it probable that a dispute will arise but also increases the complexity of any dispute.
Proving breach of contract requires demonstrating that:
- a contract exists;
- a party has breached an obligation or warranty in the contract; and
- the other party suffered loss.
In an agile context, there may be particular issues in proving that a party has breached an obligation or warranty in the contract.
A contract for an agile project is inherently changeable as it provides for a process rather than any set scope or schedule to govern the provider’s performance. This could pose an issue for proving that a contract has been breached because the requirements for a process are inherently more uncertain than a specified deliverable. For example, timeframes for completion of a party’s obligations are generally more flexible under an agile contract. Where a breach of a contracted timeframe might be clearly seen as a breach of a standard contract, it could become more difficult to establish that missing a flexible deadline constitutes a breach of an agile contract.
As such, it can be difficult to demonstrate that there has been a breach of the contract and could make it more likely for a dispute to arise, given the uncertainty as to the obligations and roles of the parties. These issues could be addressed in five ways.
Breaching an obligation or warranty
The first of these is to ensure that there is clear documentation around the requirements for each sprint. This can be done operationally by ensuring that there is a clear record of the user stories that are to be targeted during the sprint. A user story is a description of what functionality the customer wishes to be developed that act as a guide to the developer. In essence, each user story can be considered the scope of a specific piece of functionality that is to be developed.
This can become complicated, as it requires a careful balance between making the process of choosing user stories for each sprint simple enough to be flexible, while keeping them rigid enough to ensure there is adequate documentation. This can be done through allowing priority lists to be agreed during the sprint planning meeting and documented as an outcome of that meeting. The exact amount of documentation required will depend on the parties’ tolerances for documenting the agile process, but it is likely that documentation, such as agreed minutes or an updated digital platform, combined with written acceptance by both parties would be the minimum requirement.
The second is to ensure that all user stories are appropriately decomposed (ie split into smaller more manageable chunks of work) so that it is clear exactly what the required functionality is for. By decomposing the original user stories into more discrete pieces of functionality it could be simpler both for that functionality to be developed during a sprint, and to identify whether there is a failure to correctly develop that functionality.
The third is for the contract to include specific requirements on what process is to be followed and how the work is performed. This could be done by incorporating more detailed process requirements that have been created by an independent industry body rather than just including a general outline of the process. By incorporating more detailed process requirements, it is clearer what the expectations are on the developer and if those expectations have been breached. This makes it easier for both sides to identify potential breaches and ensure that their conduct is in accordance with the contract.
It is important that if industry standards are to be incorporated into a contract that this is done with enough certainty to ensure that they form a binding part of that agreement.
The fourth is for there to be a clear acceptance process that can be used in relation to developed software. This can provide for acceptance on a user story level and for acceptance of the final developed software in relation to the product vision.
Many agile methodologies have a ‘definition of done’, a set of criteria that the functionality developed during a sprint must meet for it be considered complete. This definition of done can be used to define acceptance and create structure as to when developed software should be accepted. This should reduce the risk of dispute around if the individual pieces of functionality are completed.
The contract can also allow for final acceptance of the finished software against the initial product vision. This can be useful to ensure that the initial aims of the project are accomplished but can be complicated by the high level nature of a product vision. This problem is inherent to the product vision but can be mitigated by including specific business needs in the product vision will provide criteria that the software can be compared against.
The final way to reduce uncertainty in an agile contract is to ensure that there is a clear paper trail. Making sure that all decisions, changes, and approvals are documented will assist in providing evidence as to what occurred.
However, clear documentation does conflict with one of the aims of agile methodology, which is to reduce the amount of documentation required in a project. This means that any documentation used in an agile contract needs to be simple and easy to implement, such as recording decisions in meeting notes rather than requiring signed separate documents. The exact balance will depend on exactly what agile methodology is being used and this should form part of the process that is agreed between the parties.
Other options
While it is important to take steps to reduce the risk of a complex dispute emerging by taking the above steps, the best way to reduce the complexity of a dispute is to prevent it emerging in the first place.
In our previous article we discussed how agile contracts should have a right for the parties to terminate for convenience at the end of any sprint. This tool is likely to be the most efficient way of dealing with issues in an agile project as either party can and should terminate if there are issues with the project. Simply terminating the contract and absorbing the associated losses is likely to be simpler, quicker, and cheaper than trying to litigate a dispute.
While disputes can and do emerge, the best dispute strategy is to avoid a dispute in the first place and being proactive with terminating a contract is a vital tool to achieving this.
Next steps
It is important that as businesses embark on their agile journey, they take steps to ensure that they are protected in the event of a breach of contract. Utilising the techniques discussed above should help with this.
HWL Ebsworth’s IP and IT team has extensive experience in advising businesses regarding arrangements for development, licensing and support of on-prem and cloud software, IT procurement and contracting in the IT industry. If you are concerned about contracting for an agile project, please contact us for further information on how we can assist you.
This article was written by Luke Dale, Partner, Daniel Kiley, Partner, Nikki Macor Heath, Special Counsel, Max Soulsby, Solicitor, Alycia Millar, Law Graduate, and Alina Tairli, Law Clerk.
