Navigating the legal risks in agile projects

Agile methodologies are often linked with high-profile project failures. From public sector digital transformation programs running over budget to private sector implementations that fail to deliver viable solutions, these failures share common characteristics: a fundamental misalignment between agile delivery principles and the legal frameworks that govern them.

While agile methodologies can unlock exceptional value for certain projects, particularly those that are complex and novel, it is critical that they be built on sound legal and operational foundations.

This article examines the key legal risks in agile contracting and provides practical guidance to help protect a customer’s interests when adopting agile delivery methodologies.

What is an agile project?

Agile delivery is based on iterative development, where work is divided into short cycles known as ‘sprints’ rather than designed and built in a single, linear process. In each sprint, the team selects, designs, develops and tests a set of features from a prioritised backlog of requirements. At the end of each sprint, a working software increment is delivered for customer review and feedback. This approach means the project scope is continuously refined based on feedback, and commercial and delivery risk shifts throughout the project lifecycle. 

By contrast, traditional waterfall models fix scope, schedule, and price upfront. The project proceeds through strict sequential phases (such as requirements, design, development, testing and deployment). Each phase must be completed and formally approved before the next phase may begin.

‘Agile’ is not a single, standardised methodology. It is an umbrella term covering Scrum, Kanban, SAFe, XP, and numerous proprietary variants, each with different assumptions about governance, accountability, and risk allocation. In practice, many projects operate as hybrids and adopt agile terminology while retaining waterfall-like phase gates. If the parties have not agreed and documented a shared understanding of what ‘agile’ means for their project, including how scope changes are governed, who has authority to make decisions, and how ‘done’ is defined, they may discover they were never on the same page. 

Why choose agile over waterfall?

It is important at the outset of a project to understand why an agile methodology is being adopted and whether it is appropriate for the project. If it is not, a traditional waterfall contracting approach may be more suitable.

The waterfall model assumes that all requirements can be defined in advance. In practice, customers rarely have a complete understanding of the system they need or how it should function. Requirements may change over time, which can be difficult to accommodate under a waterfall contract as changes may fall outside the agreed scope or require rework that increases cost, time and delay. Agile is therefore often better suited to complex and novel projects where requirements are likely to evolve.

Agile also offers several advantages over waterfall:

1. Faster contract negotiation. Less detail needs to be agreed at the outset. This allows contracts to be negotiated and executed more quickly than in a waterfall model, which often requires detailed scope and specification documents.
    
2. Meeting customer needs. Continuous customer involvement and feedback make it more likely that the final product reflects what the customer requires. This can reduce the risk of disputes about whether the delivered product meets expectations.
    
3. Flexibility to adapt. Agile allows the scope of the project to evolve over time. This enables issues to be identified earlier and suppliers to respond to changing customer needs, without the costly rework that is required in a waterfall model.

However, these advantages come with corresponding legal risks that must be actively managed.

Key legal risks of agile

The key legal risks in agile development, outlined below, generally stem from the tension between the flexibility of agile methodologies and the need for contractual certainty. Contracts for the delivery of technology projects often assume a fixed scope, agreed milestones, and sequential delivery, and do not always align with agile development. It is critical to ensure that contractual terms align with the agile delivery methodology. 

Liability for unfinished or unusable deliverables

Without staged milestones and robust acceptance criteria, incremental sprint deliveries can lead customers to fund work that fails to integrate into a viable solution. Organisations can find themselves having paid substantial sums for unusable deliverables with limited contractual recourse to recover costs or compel completion. It may also be unclear when the project is ‘done’ or what constitutes final acceptance.

Absence of fitness for purpose warranties

Since requirements evolve continuously throughout a project, suppliers are often unwilling to guarantee that the final product will be fit for a purpose that is not clearly defined at the outset. This leaves customers exposed to the risk that a delivered solution, while technically compliant with the individual sprint outputs, fails to meet the business needs that it was designed to address.

Increased dispute complexity

The flexibility of agile makes it difficult to prove breach of contract, as obligations and deadlines are rarely fixed, increasing both the likelihood and complexity of disputes. The rapid pace of agile delivery means that if disagreements are not escalated and resolved in real time, evidence trails can be lost and remedies foreclosed. 

A common issue is scope creep. Because scope evolves over each sprint rather than being fixed at the outset, it can be difficult to pinpoint when a change crosses the line from legitimate refinement to outside of scope. Without clear mechanisms to control changes, requirements may expand without corresponding adjustments to time, cost or resources. Parties may disagree on whether additional work falls within the original agreement, whether extra payment is owed or whether delays caused by changing requirements amount to a breach.

Intellectual property and data rights ambiguity

Collaborative development practices can create IP ownership ambiguity, especially when open-source software and pre-existing code are incorporated. Without explicit provisions ensuring customers receive all work in progress, source code and documentation upon termination, organisations risk being left with incomplete products and no legal right to finish them.

Termination and exit rights complications

Without clear exit provisions, customers may be liable for significant break charges or lose access to work-in-progress code and documentation upon termination. The iterative nature of agile means that at any given point, substantial value may exist only in incomplete form, making contractual protections for termination, IP ownership and transfer, and transition-out essential.

Governance authority and delegation risks

Agile projects empower roles such as the product owner to make binding decisions on scope and budget. If these individuals lack appropriate financial delegation or authority under procurement law, organisations may inadvertently breach internal policies or statutory frameworks.

Practical mitigations for agile project risk

To successfully navigate agile projects, project teams must shift focus from managing fixed outcomes to governing dynamic processes. That requires deliberate choices when commencing a project about the commercial model, contractual obligations, and governance structure. The following mitigations can deliver protection against the risks discussed above.

Select the right commercial model      

Choose a commercial contracting model appropriate for the project's scale and requirements. Common options include:

• Time-and-materials with sprint governance: Customer pays for supplier effort per sprint, with budget managed by capping sprint velocity or overall funding. 
   
• Agile fixed-price per sprint or Minimum Viable Product: Each sprint or Minimum Viable Product is priced as a discrete work package, with changes accommodated through backlog reprioritisation. 
   
• Hybrid ‘water-scrum-fall’ models: High-level scope, milestones and funding limits agreed up-front, but detailed requirements and build/test cycles run in agile sprints. 
   
• Outcome-based contracts: Payments linked to defined business outcomes or user stories delivered, not merely effort expended. 

Align contract language with agile reality

Give special consideration to warranties, termination clauses and dispute resolution mechanisms. For example, this may include a termination right that the customer can exercise at the end of each sprint or at particular checkpoints. Traditional IT delivery contracts are often unsuitable for agile projects, particularly where they rely on waterfall concepts such as fixed specifications, sequential acceptance or milestone-based payment triggers that do not reflect how work is actually delivered. 

Require delivery of a Minimum Viable Product

Require the supplier to deliver a Minimum Viable Product with clear acceptance criteria. The benefit of this approach is that it mandates a tangible outcome and ensures the customer receives at least the core product or solution it commissioned, without dictating the process or methodology the supplier uses to get there. 

Establish sprint cadence commitments

Require contractual commitments to specific sprint activities and cadence, including:

• Defined sprint duration (typically two to four weeks);
   
• Mandatory sprint planning, daily stand-ups, sprint reviews and retrospectives;
   
• Minimum velocity or story point commitments per sprint; and
   
• Clear definition of ‘done’ for each user story (being each discrete feature or requirement, as described from the end-user’s perspective).

Build in continuous governance checkpoints

Establish mandatory governance reviews at defined intervals (e.g. every three to four sprints) where senior stakeholders assess project health, budget trajectory and strategic alignment, with explicit rights to pause or terminate if value is not being delivered.

Invest in team capability

Provide project teams with training in contract awareness and continuous contract governance. Ensure your project team has the technical expertise to validate work quality and raise issues early.

Implement real-time dispute resolution

Build escalation mechanisms that operate at sprint velocity, requiring disputes to be raised and resolved within defined timeframes (e.g. one sprint cycle) to prevent evidence loss and maintain project momentum.

Clarify intellectual property ownership

Ensure the contract defines ownership of all deliverables, including work in progress. Provide that ownership vests in the customer as deliverables are created (each sprint output) and on project completion.

Building the right foundations for agile methodologies

Agile methodologies can unlock exceptional value for digital transformation projects, but only when they are built on sound legal and operational foundations. By understanding the risks and implementing robust contractual and governance frameworks, project teams can harness agile's benefits while protecting against its pitfalls.

Many private and public sector organisations are seeking practical guidance in structuring, negotiating and troubleshooting agile contracts. Whether embarking on a new digital transformation project, seeking to remediate an at-risk project, or wanting a ‘health check’ of existing arrangements, organisations benefit from clear strategies that support project success and mitigate risks.