Agile software development methodologies remove the concepts of clear scope, schedule, and budget, replacing them with an embrace of uncertainty. Embracing agile requires changing your way of thinking about a project, and about how you contract.

There is some evidence that suggests as many as 98% of projects are developed using some variation on an agile methodology, and only 2% are developed using traditional waterfall methodology. Despite this high uptake, agile projects are often contracted in the same manner as projects run using a traditional methodology, leading to an increased risk of dispute. This makes it vitally important that businesses understand the risks associated with agile methodologies and how to best contract for these projects.

Anecdotally, agile development is popular with software developers and has been used by a variety of different companies for other reasons, such as Saab in its development of fighter jets.

In this article, we will provide a brief overview of what makes an agile project and how this differs from a traditional project. We will also examine what are the key differences in how you contract for an agile project when compared to a traditional project.

What is an agile project?

An agile project is any project that uses a methodology based on the principles from the Manifesto for Agile Software Development. Click here to access the Manifesto. The Manifesto for Agile Software Development was authored by 17 leaders in the software development industry in 2001 and has been taken up by the industry as shown by the adoption of methodologies like Scrum, Kanban, extreme programming, and feature-driven development. These methodologies focus on customer collaboration, responding to change, and using iterative sprints to develop working software. This means that agile projects do not have set scopes of work, budgets, or timeframes; a factor which often raises alarm bells for businesses which are unfamiliar with how the methodology works.

The sprint is, in many ways, the fundamental unit of an agile project. Each sprint is typically two to four weeks in length and involves developing functionality, as chosen by the customer at the sprint planning meeting, into working software. The customer then reviews the developed software in a sprint review meeting before the whole process starts over again, as shown in the diagram below.

The idea behind using iterative sprints is that it allows for a prioritisation of the most important functionality by the customer and allows flexibility for the customer to change what they want the software to be able to do over the course of the project. This saves effort from being wasted developing functionality that is not beneficial to the customer and places the focus squarely on developing valuable functionality.

How does an agile project differ from a traditional project?

Agile projects differ from traditional projects in a variety of ways, but the key difference is that agile projects are iterative and traditional projects are linear. This can be seen by comparing the diagrams below:

This difference in project methodology means that traditional projects have fixed scope, schedule, and budget, whereas agile projects do not have fixed scope, schedule, or budget.

Hypothetical example

The differences between agile methodology and traditional project methodology are best demonstrated through an example.

A business approaches a software developer to create a solution for their online shopping portal. The business wants a solution that allows for the purchasing of goods, secure processing of transactions, and that automatically creates the order for dispatch and delivery. However, sometime after they engage the developer, the business realises that they want to include the ability for customers to have secure accounts, leave reviews on products and that the functionality they specified for dispatch and delivery is going to need to change as the business has engaged a new contractor who will provide delivery services and uses a different system.

In a traditional project, the linear nature of the project means that any variations require the whole project to be put on hold while the new functionality goes through the first stages of the project. This can cause significant delays in the schedule and substantial increases in cost. This is compounded by work having already begun on the now defunct functionality, meaning effort (and money) was wasted on functionality that is no longer valuable to the business.

In contrast, an agile project uses iterative development cycles. This means that new functionality can just be slotted into the product backlog with no impact on the current development work being done. This decreases the potential impact on the project schedule and budget, provided that the now defunct functionality was never prioritised and developed. Agile project management requires prioritising functionality based on business value, so would prioritise the purchasing of goods and secure payment of transactions first, especially if the potential change in distributer was known to the customer’s product manager. This would result in less work being wasted, as no time would be spent developing defunct functionality, and the overall project would therefore be cheaper and quicker than if traditional methodology was used.

However, the use of agile should be taken with a grain of salt as a traditional project is likely to be better for a customer as the scope, schedule and budget are fixed. The benefits of agile are also reduced if there is not a clear understanding of what functionality to prioritise as that can result in effort being expended on functionality that becomes defunct or is of low business value.

What are the key differences in how you contract for an agile project?

Agile projects function very differently to traditional projects. This means that you must contract them using different principles. An example of this is shown in the table below:

When contracting for agile projects, you are contracting for a process and not an outcome. This allows you to vary the specifications of the project and what is being developed in each sprint as part of the sprint planning meeting via agreement in the sprint planning meeting. This allows for the scope of work to change without varying the contract as it is just the application of the contracted process.

Next steps

Agile methodologies are not going anywhere. More and more businesses are adopting agile processes to modernise and stay competitive. This means that contracting for these projects is vital to reflect the realities of the development process and mitigate the risk of disputes.

However, agile projects are not without their inherent risks. In our next article in this series, we will examine what these risks are from a customer’s perspective and provide some examples of how these risks can be minimised.

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.