Stick to the rivers and lakes that you’re used to: Agile contracting for clients

Agile software development projects emphasise business value and flexibility. They are also inherently uncertain: due to the lack of fixed scope, budget, or schedule, customers do not know what they will get for their money. Using an agile methodology means embracing that risk, while taking steps to mitigate it.

In our previous article, available here, we discussed the basics of what makes an agile project and the underlying principles for contracting for these projects. In this article, we will focus on agile from a customer perspective, examine the risks and benefits of using agile methodology and propose how you can reduce these risks.

The traps of using agile

Let’s take a hypothetical example: you’re a business looking to engage a software developer to create a product to assist your day-to-day processing, including inventory and warehouse management, invoicing, managing enquiries and orders, and stock control.

You need this work completed within a year and you decided to use an agile methodology to deliver this project, despite neither you nor the developer having any experience with agile projects. You entered into a contract that did not specify the scope of work, the methodology that would be used to develop the software, what the responsibility of each party is (especially in relation to functional requirements of the software) or provide for termination rights for the customer.

There were issues with the development project as both you and the developer refused to create the user stories that identify the desired functionality for the solution, instead only providing either high level summaries of the project or technical specifications. This led to the wrong functionality being developed. Your lack of sophistication with agile processes also caused an inefficient development process.

You considered terminating the agreement but didn’t have the rights to do so, leading to a three-year development cycle that was millions of dollars overbudget. To make matters worse, the software developed at the end of the project was not suitable for purpose as the required functionality had not been communicated to the developer and the developer had not identified the issues this would create in the final solution.

You then attempted to sue the developer, but the high-level nature of the contract made it impossible for you to prove any specific breaches by the developer and led to you losing the case.

How to do agile well

An agile project can be implemented in a way that maximises the customer’s return on investment and reduces the inherent risks of agile methodologies.

If we look at the above example, we can identify changes that could have been made that would have allowed the project to be successful:

1. Choice of methodology: The short timeframe makes the project unsuited to a pure agile methodology, as would a strict budget or scope of work. Instead, a hybrid-agile approach or waterfall approach would be better suited for this development project. We will assume that this change has not been implemented for the remainder of our discussion about the above scenario;
2. Outline of methodology: The lack of clear outline and understanding on how the project methodology would work leads to confusion as to how to implement the project. The contract should include a clear outline of what project methodology will be used, including a delineation of responsibilities and the specific sprint process that would be used for the project. This would make it clear how the project functions and allow both parties to meet their responsibilities and allow the project to succeed;
3. Engaging an experienced contractor: The lack of agile sophistication on the customer side has led to inefficiencies in the project. Customers should engage a contractor with experience in managing agile projects to run the project from their end. This would allow the customer to upskill its agile sophistication and get the maximum value out of using an agile project;
4. Specifying key developer personnel: The contract contained no restrictions on who could work on the project, allowing the developer to use inexperienced and ineffective resources. The contract should specify the developer key personnel required for the project and the qualifications needed. This would require the developer to employ staff with appropriate agile qualifications; and
5. Termination: The inability to terminate the contract even when it was obvious the project would not be successful further exacerbated the problems. The contract should include a termination for convenience right that allows the customer to terminate at the end of any sprint. This would allow the customer to terminate if it becomes clear that the developer is not meeting the required standards and prevent unnecessary costs due to an ongoing project the developer had no control over.

Next steps

Agile projects can be a valuable tool as they can allow for the maximisation of return on investment and the minimisation of wasted resources. However, in order for you to get the most out of an agile project you have to ensure that the project is suitable for an agile methodology, that the contract is set up to maximise the chance for success, and that the right resources in place to create the most efficient project. We can help you with this process.

HWL Ebsworth’s IP and IT teams have 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 and
Max Soulsby, Solicitor.