Failed Agile Software Projects: Who Is Responsible, and Who Bears the Loss?
Agile software development is designed to accommodate change. In an Agile software project, requirements are refined during the project, software is delivered in shorter cycles and customers are expected to participate in prioritisation, testing and feedback.
That flexibility can be useful, but it can also make disputes harder to untangle.
When an Agile software project fails, suppliers may argue that requirements kept changing. Customers may respond that they hired the supplier precisely because it had the technical expertise to turn business requirements into working software.
Neither argument automatically determines liability.
Agile is a delivery methodology, not a separate legal regime. When a project fails, responsibility under the law of England and Wales still depends on what the parties agreed, what each side was required to do, what happened during delivery and which failures caused the resulting loss.
Does Agile change who is legally responsible?
Not by itself.
An Agile contract may allow requirements to evolve through product backlogs, user stories, sprint planning and demonstrations. That does not remove contractual obligations.
The supplier may still be required to provide appropriately skilled personnel, follow an agreed delivery process, meet particular milestones, manage technical risks and perform adequate testing. It may also be expressly required to exercise reasonable care and skill.
In a relevant contract for the supply of services, section 13 of the Supply of Goods and Services Act 1982 also implies a term that a supplier acting in the course of business will carry out the service with reasonable care and skill. The effect of any attempt to exclude or restrict that obligation will depend on the contract and applicable statutory controls.
The customer may also have important responsibilities. Agile projects commonly depend on the customer providing information, making knowledgeable staff available and giving timely decisions and feedback.
The key question is therefore not simply whether the project was Agile, but what each party was required to do.
Who is responsible when an Agile software project fails?
Responsibility depends on the evidence, but several recurring issues arise.
- The supplier may have delivered defective or inadequate work. Agile does not excuse poor coding, inadequate testing, unsuitable architecture or a failure to provide competent resources. If software repeatedly fails agreed requirements or acceptance criteria, the supplier may be in breach.
- The supplier may have made commitments it could not meet. Underestimating a project is not automatically a breach, particularly where cost and scope were expressly allowed to evolve. However, specific commitments about price, delivery, resources or capability may become important if they were contractual, amounted to actionable pre-contractual representations or were otherwise legally material.
- The customer may have contributed to delay. If decisions were repeatedly postponed, essential data was not supplied or relevant staff were unavailable, that may affect responsibility for delay and additional cost. The supplier should nevertheless be able to show how those failures affected delivery.
- The scope may genuinely have changed. Not every increase in price indicates supplier failure. If the customer materially expands the agreed requirements, the supplier may be entitled to additional time or payment, depending on the contract.
Both parties may contribute to a troubled project. That does not mean responsibility is automatically divided equally. The parties may need to analyse individual delays, defects and cost increases separately.
Does changing the backlog change the contract?
Not necessarily.
A product backlog is expected to evolve. Refining a user story or changing its priority does not automatically mean that the customer has commissioned additional work.
The key issue is whether the change merely clarifies an existing requirement or materially changes the agreed scope.
For example, a supplier may struggle to justify an additional charge where backlog changes simply explain functionality that was already included in the original project. Equally, a customer cannot necessarily rely on a broad business objective to require unlimited additional development within the original price.
A well-drafted Agile contract should distinguish between ordinary backlog refinement and changes affecting scope, budget, timetable, assumptions or technical architecture.
What about fixed-price Agile projects?
A project does not stop being fixed price simply because Agile techniques are used.
However, describing a project as fixed price does not necessarily mean that every new requirement added later is included.
The business should check the contract for provisions dealing with scope, dependencies, assumptions, change control, sprint allocation and additional charges.
Difficulties often arise where the parties stop following the formal change-control mechanism and instead agree changes through meetings, emails or project-management tools. In those circumstances, the parties’ later conduct may become important when establishing what was actually agreed.
Can the supplier blame the customer’s product owner?
Not automatically.
A product owner may prioritise functionality, explain business requirements and approve or accept user stories, demonstrations or completed work under the agreed delivery process.
That does not necessarily make the customer responsible for technical architecture, coding quality or engineering decisions.
The contractual effect of any approval will also depend on the agreed acceptance mechanism and the authority of the individual concerned.
The position may be different where the supplier clearly identified a technical risk, explained the consequences and the customer nevertheless instructed it to proceed.
What if the Agile software project keeps missing sprints and deadlines?
Missing a sprint goal does not necessarily amount to a contractual breach.
Agile documentation often distinguishes between sprint goals or forecasts and binding contractual milestones. Whether a date is legally binding depends on the contract, relevant project documentation and, sometimes, the parties’ subsequent agreement or conduct.
Repeated missed milestones can nevertheless become significant, particularly where the supplier cannot produce a credible recovery plan or an important go-live date is at risk.
A chronology can be particularly useful. It should identify what was due to happen, what actually happened, what caused the delay and what each party said about revised dates.
Should you withhold payment?
Businesses should be cautious about automatically withholding invoices.
The supplier may have contractual rights to suspend work, restrict services or terminate for non-payment.
Before withholding money, the business should establish what the invoice relates to, whether the relevant payment trigger has occurred and whether there is an express contractual right of withholding or set-off.
Any separate legal or equitable right of set-off will depend on the nature and connection of the cross-claim.
Used without proper analysis, withholding payment can turn a performance dispute into an additional contractual dispute.
Can you terminate a failed Agile software project?
Potentially, but termination carries risk.
The contract may provide a right to terminate following a material breach, usually subject to notice requirements and sometimes an opportunity to remedy the problem.
In sufficiently serious circumstances, there may also be a common-law right to accept a repudiatory breach and treat the contract as discharged for the future. Broadly, this requires a sufficiently serious breach or conduct demonstrating an intention not to perform the contract.
Importantly, repudiation does not usually end the contract automatically. The innocent party will generally need to decide whether to accept the breach or affirm the contract.
The business should therefore plan termination carefully.
An exit plan may need to address:
- Contractual rights to software and project materials. The customer should establish what rights it has to source code, documentation and other deliverables. Payment for development does not necessarily mean the customer owns the resulting intellectual property.
- Operational continuity. Hosting, system access, licences, credentials and transition assistance may need to be secured before the relationship ends. Where personal data is involved, the parties should also consider return or deletion obligations, data-processing arrangements and security during transition.
Ending the contract before addressing these issues can leave the customer with a legal claim but an immediate operational problem.
Who bears the financial loss?
Showing that the supplier breached the contract is only one part of a claim. The customer must also establish the loss caused by that breach.
Potential losses may include wasted implementation expenditure, reasonable remediation costs, replacement software costs and additional expense caused by keeping legacy systems operating.
Whether those losses are recoverable depends on issues including causation, remoteness and mitigation.
The law will generally expect a claimant to take reasonable steps to mitigate avoidable loss. It is not, however, required to take unreasonable, disproportionate or speculative steps.
The contract may also contain a liability cap or exclusions for certain categories of loss.
The business should review those provisions carefully. In some circumstances, the Unfair Contract Terms Act 1977 (“UCTA”) may subject an exclusion or limitation clause to a statutory reasonableness test, including certain exclusions relating to negligence and provisions used in written standard terms of business.
Whether UCTA applies will depend on the contract and the liability being limited.
What evidence matters most in an Agile software project dispute?
Agile disputes are often won or lost on the project record.
Useful evidence can include the contract, statements of work, backlog histories, user stories, sprint plans, acceptance criteria, testing records, change requests, project-management systems, meeting notes and correspondence.
Businesses should also preserve financial evidence showing the impact of the alleged failure.
Businesses should pay particular attention to contractual acceptance procedures. Some contracts contain deemed-acceptance provisions or short periods in which defects must be formally notified.
Preparing a chronology early can also help identify when requirements changed, who made important decisions and what caused individual delays.
Can the dispute be resolved without litigation?
Often, yes.
Technology disputes frequently involve practical problems that litigation cannot resolve quickly, such as continued system access, completion of critical functionality, data migration or transfer of project materials.
Negotiation or mediation may therefore lead to commercially useful outcomes such as revised milestones, reduced fees, cancellation of disputed invoices, compensation or an agreed exit.
Obtaining legal advice does not necessarily mean escalating the dispute. It can help management understand its leverage before making decisions that affect the contractual position.
Is there a deadline for bringing a claim?
Yes.
For many claims founded on a simple contract, section 5 of the Limitation Act 1980 provides a six-year limitation period from when the cause of action accrues.
Where the relevant obligation is contained in a deed, the limitation period may instead be 12 years, although the precise position depends on the cause of action and any applicable exception.
The contract may also contain much shorter procedural requirements, for example for disputing invoices, notifying breaches or defects, following escalation procedures or allowing a supplier an opportunity to remedy a breach.
The business should check these issues early rather than waiting until negotiations have completely broken down.
When should you seek legal advice?
Legal advice becomes particularly important when a difficult project begins affecting significant contractual or financial rights.
Common warning signs include repeated missed recovery plans, substantial demands for additional payment, disputes over whether requirements are genuinely new, threatened suspension, withheld invoices or a proposed termination.
Early advice can help establish what the contract requires, distinguish legitimate scope changes from supplier failure and identify whether the available evidence supports the position being taken.
It can also reduce the risk of weakening a claim by approving disputed milestones, agreeing revised terms without appropriate reservations or terminating incorrectly.
How the Jonathan Lea Network can help with a failed Agile software project
At The Jonathan Lea Network, we advise businesses on software development, implementation and technology contract disputes, including Agile software projects.
We can review the contract and project record, analyse disputed scope changes, delays and additional charges, advise on liability and recoverable losses, and assess whether contractual or common-law termination rights may have arisen.
Where appropriate, we can also assist with negotiations, mediation and formal proceedings.
A failing Agile software project does not inevitably need to end in litigation. However, once costs are escalating or confidence in the supplier is deteriorating, understanding the legal position early can preserve options and help avoid further commercial decisions weakening the business’s position.
If your business is dealing with a delayed, over-budget or unsuccessful Agile software project, contact our technology and dispute resolution team. We can help you assess responsibility, identify the practical options available and decide whether the most effective strategy is to repair, renegotiate or exit the project.
Frequently asked questions: agile software project disputes
It depends on what each party agreed to do and what caused the loss. Agile is a delivery method, not a separate legal regime. The supplier may have delivered defective work or made commitments it could not meet. The customer may have caused delay, or the scope may genuinely have changed. Both sides can contribute, but responsibility is not automatically split equally. Look at each delay, defect and cost increase separately. Not by itself. Requirements can evolve through backlogs, user stories and sprint planning, but the contractual obligations remain. The supplier may still have to provide skilled staff, follow an agreed process, meet milestones and test properly. Section 13 of the Supply of Goods and Services Act 1982 also implies a duty of reasonable care and skill. The customer may have duties too, such as giving timely decisions and feedback. Not necessarily. Everyone expects a product backlog to evolve. Refining a user story or changing its priority does not automatically mean you have ordered extra work. The key question is whether the change only clarifies an existing requirement or materially changes the agreed scope. However, a broad business objective does not entitle you to unlimited extra development for the original price. Check how your contract treats scope changes. Yes. A fixed-price project keeps its fixed price even if it uses Agile techniques. However, a fixed price does not necessarily cover every new requirement added later. Check the contract for provisions on scope, dependencies, assumptions, change control, sprint allocation and extra charges. Problems often start when the parties stop using the formal change process. Their later conduct may then decide what they actually agreed. Not automatically. A product owner may prioritise features, explain business needs and approve user stories or completed work. That does not usually make the customer responsible for technical architecture, coding quality or engineering decisions. The effect of any approval depends on the acceptance process and the person’s authority. The position may differ if the supplier warned of a clear technical risk and the customer told it to go ahead Not necessarily. Agile documents often separate sprint goals or forecasts from binding contractual milestones. Whether a date is binding depends on the contract, the project documents and sometimes the parties’ later conduct. However, repeated missed milestones can become significant, especially if the supplier has no credible recovery plan. Keep a chronology of what was due, what happened, what caused each delay and what each side said. Be cautious. The supplier may have rights to suspend work, restrict services or terminate for non-payment. First, establish what the invoice covers and whether the payment trigger has happened. Then check whether the contract gives you an express right to withhold or set off money. Without proper analysis, holding back payment can turn a performance dispute into a second contractual dispute. Take advice before you act. Your exit plan should cover your rights to the source code, documentation and other deliverables. Paying for development does not necessarily mean you own the intellectual property. It should also cover hosting, system access, licences, credentials and transition help. If the project uses personal data, consider return or deletion, data-processing arrangements and security. Otherwise you may have a legal claim but an immediate operational problem. The customer must show that the supplier breached the contract and that the breach caused its loss. Losses may include wasted implementation spending, reasonable fixing costs, replacement software and the cost of keeping old systems running. Causation, remoteness and mitigation all affect what you can recover. The contract may also cap liability or exclude some losses. Review those clauses carefully, as UCTA may apply in some cases. For many contract claims, the limitation period is six years from when the cause of action accrues. Where the obligation is in a deed, it may be 12 years. However, the contract may set much shorter deadlines. These can cover disputing invoices, notifying breaches or defects, escalation and giving the supplier a chance to fix a breach. Check these early, before negotiations break down completely.
Contact us
We provide most enquiries with an indicative scope of work and fee estimate, based on the information you share. We aim to respond within one working day.
In the same email you will be invited to arrange a 20-minute complimentary, no-obligation video consultation, should the proposed scope of work and fee estimate be of interest. This initial discussion is designed to better understand your requirements, refine the scope and ensure our approach is fully aligned with your objectives, at the end of which we will email you a definitive formal fee estimate to consider and approve.
Where you would prefer to receive initial advice and guidance from the outset, or where a short introductory call would not be the most appropriate starting point, we may instead recommend a 2.5-hour fixed-fee appointment, starting from £700 + VAT. This enables us to review the information you provide, discuss your situation with you and provide considered, tailored advice at an early stage.
To make an enquiry, please email us at wewillhelp@jonathanlea.net, complete our contact form, or call us on 01444 708640.
VAT is charged at 20%.
This article is intended for general information only, applies to the law at the time of publication, is not specific to the facts of your case and is not intended to be a replacement for legal advice. It is recommended that specific professional advice is sought before relying on any of the information given. © Jonathan Lea Limited.