Internet Explorer 11 (IE11) is not supported. For the best experience please open using Chrome, Firefox, Safari or MS Edge

'Agile’ is an umbrella term that encapsulates a number of modern flexible approaches to software development and IT projects. Broadly speaking, in agile, the emphasis is on the customer and supplier working together to deliver aspects of a solution through incremental short development cycles. In this article we look at the advantages and challenges with the agile method and things to keep in mind when contracting for agile development projects.

Traditional waterfall approach

In traditional technology and outsourcing contracts, waterfall development operates in a linear and sequential manner - hence the ‘waterfall’ title. The product scope and specifications are established at the outset. These are set out in the contract, which also usually include a rigid timeframe for final delivery of the project. Once the parties agree these initial parameters, the customer’s involvement in the progression of the project is more or less finished. The supplier then designs, codes and tests the product, before it is ultimately provided to the customer in its finished form. This process typically takes place over a long period of time, possibly years, during which the supplier is essentially developing in a vacuum.

Waterfall: practical problems

The sequential flow of the waterfall approach poses practical problems for the development and delivery of software and IT projects, including:

  • Difficulty identifying specifications at outset - detailed product scope and requirements are usually recorded in the contract prior to signing. These are used to determine the progression and overall success of the project. However, it can be difficult for the parties to precisely identify them with any degree of accuracy before the customer sees a prototype or proof of concept.

  • Lack of flexibility - the waterfall methodology operates through long development cycles and once the requirements have been set, there is little scope for modification if the customer’s needs evolve, or even if the market itself changes. With the waterfall approach, the customer is tied to an output that may not be fit for purpose, or that may become out-dated, even before it has been completed. This may reduce or even eliminate the value of the product to the customer.

  • Lack of customer visibility - the lack of customer involvement also means that potential problems may not become apparent until the end of the project, which can put overall timeframes in jeopardy.

  • Fixed timeframes - a supplier facing with a strict deadline may inadvertently reduce the quality of the work done, for example, through less rigorous testing, in order to deliver the product on time.

Defining agile?

We are seeing an increasing level of interest in agile in the software and IT project sectors. Agile promotes an adaptive and continuous improvement approach to technology projects, which focuses on broad objectives rather than a fixed set of requirements. The supplier and customer are both actively involved in multiple short development phases, typically no more than four weeks at a time. These development cycles are commonly known as ‘iterations’ or ‘sprints’. The emphasis is on dialogue and collaboration between the customer’s team and the supplier’s team, enabling frequent review and evolution of plans. This, in turn, allows the parties to respond to markets trends and other changes, and for modifications and improvements to the specifications and requirements to be accommodated at multiple stages in the process.

Benefits and challenges of agile

The agile methodology offers a number of benefits. However, it also poses significant risks and challenges, which businesses should consider carefully before embarking on an agile project.


  • Adaptable - the customer’s needs are likely to change over time as the project and the market develop. With the agile methodology, these changes are easier to accommodate.

  • On-going objectives - it can often be difficult for the customer to definitively identify their needs until they have seen how the product begins to take shape. This may be the case because the customer does not have sufficient resources to accurately define their requirements at the outset. This is less of a risk with agile as there is a broad product vision at the outset which can evolve with each sprint.

  • More interactive - agile is based on a more collaborative and interactive relationship between the customer and the supplier, which provides the customer with greater scope to ensure the project is proceeding in accordance with its vision.

  • Incremental delivery - agile is designed so that the customer has visibility of the process and receives a working product at regular intervals, rather than receiving one final complete product at the end of the entire process.


  • Uncertainty as to final outcome - the nature of the agile methodology means that the project proceeds with greater uncertainty as to the final outcome and timing. Agile depends on the parties trusting each other as they proceed towards an undefined final product. The customer and supplier may ultimately disagree over whether the project has been completed.

  • More resource intensive for customer - agile’s emphasis on collaboration means it is more resource-intensive for the customer than the traditional waterfall approach. This is because the customer will have continuing involvement throughout the project, and will need technically skilled staff on hand for this purpose.

  • Pricing model - fixed price contracting naturally fits better with the waterfall methodology and fixed price certainty is obviously the typical preference of a customer. However, pricing on a time and materials basis better reflects the flexible and iterative ethos of agile; but what happens if more sprints are needed than originally planned?

  • Intellectual property rights - the collaborative working method of agile can lead to the development of joint intellectual property. An agile project therefore needs to clearly address the licensing and ownership of background and foreground IPR.

Contracting for agile development projects

The technology sector embraces various ways for lawyers to document the agreed business arrangement between parties. Most technology lawyers are used to a contract format where the customer sets out the detailed requirements in the contract at signing, the supplier develops and delivers the end solution, and the customer then pays. Agile does not adhere to these traditional parameters of risk allocation and performance delineation.

Typical waterfall and agile IT contracts have many themes in common, such as acceptance testing, payment, governance, and termination. However, the approach to these themes and the drafting will differ. For example, the pricing model under the waterfall approach is typically focused on payment of a fixed amount upon delivery of the finished product. Whereas in agile the product is developed in deliverable increments and pricing may be determined on a time and materials basis. The contract may provide termination rights for the customer at the end of each sprint. Similarly, a waterfall contract will clearly at the start identify the form and specifications of the finished output. However, agreeing on the obligations within each sprint and the form and acceptance of a final deliverable will pose greater challenges under an agile contract.

When drafting an agile contract, the parties should identify these issues at the beginning of the process and give them careful consideration.

What the future holds

Agile represents an exciting approach to software development and IT projects, and has the potential to overcome some of the challenges inherent in the conventional waterfall approach. However, the flexible and interactive approach of agile also poses risks to unwary customers; risks that need to be managed carefully. If you are considering an agile project, you should seek expert legal advice.

For more information on agile contracting for your next IT project, contact a member of our Commercial team.

The content of this article is provided for information purposes only and does not constitute legal or other advice.

Share this: