Why agile delivery fails in legacy heavy environments without structural preparation.
Agile remains the dominant model for modern software delivery for good reasons. Iterative development, fast feedback loops and the ability to adapt to new information are essential in complex, evolving systems. However, when agile is introduced into legacy-heavy organisations without accounting for institutional constraints, its effectiveness can diminish over time. What begins as an agile programme can often shift imperceptibly into a sequential delivery model beneath the surface.
In 2019, 29% of organisations reported using waterfall delivery models. By 2022, that figure had risen to 43%. Not because teams chose to abandon agile, but because the environments they were delivering into quietly forced the shift.
Teams start with discovery and prototyping, iterate rapidly and validate assumptions early. But as delivery progresses, unaddressed constraints begin to emerge, such as undocumented legacy behaviours, regulatory edge cases or operational workarounds that were never captured as formal requirements. At this point, the legacy system reasserts itself as a source of truth.
Agile ceremonies may continue, but the programme becomes more reactive. The goal can subtly shift from solving user problems to reproducing historical behaviour. What remains is a hybrid model becoming agile in appearance, yet waterfall in substance - the hidden waterfall.
Legacy Replacement as High-Risk
The data on legacy modernisation is consistent. These programmes fail more often, and more visibly, than greenfield initiatives.
A review of ERP project outcomes by KPC Team places failure or severe underperformance rates between 55% and 75%, depending on scope and definition. With ERP Today highlighting testing, data quality and scope volatility as common points of failure.
Data migration projects carry even higher risk. According to Oracle, over 80% of data migration initiatives either overrun, underdeliver or fail entirely. Most often due to undocumented dependencies and inadequate validation. Factors such as schema drift, semantic inconsistencies and legacy entanglement are reported as persistent blockers to successful transformation.
Most digital transformation efforts in large organisations are not pure greenfield builds. They are legacy replacement or coexistence programmes - subject to all the structural, technical and operational complexity that entails.
Why Legacy Becomes the Specification
A common misstep in legacy modernisation is the assumption that existing systems simply encode outdated implementations of known requirements. In practice, legacy systems carry decades of organisational memory, much of it undocumented.
Research in requirements engineering reveals several persistent patterns in legacy systems:
- Business logic is embedded in code rather than documentation
- Exceptions are handled through hidden branches or procedural workarounds
- User behaviours evolve around system constraints, becoming de facto requirements
When delivery teams attempt to define new system requirements without examining these embedded behaviours, they quickly encounter gaps. At that point, the legacy platform is no longer a background dependency - it becomes the only available reference model.
Studies published in IJACSA and Springer show that late discovery of implicit requirements is a leading cause of rework. In legacy replacement programmes, these “requirements” were never made explicit because they were never formally captured.
This is a structural outcome of relying on systems that evolve without parallel investment in shared knowledge.
Water-Scrum-Fall
In 2011, Forrester introduced the term “Water-Scrum-Fall” to describe hybrid delivery models in which agile practices are embedded between upfront planning and downstream release governance. More than a decade later, this pattern persists, and if anything, it has increased.
CIO Dive reported in 2022 that 43% of organisations still use waterfall models, up from 29% in 2019, with compliance, assurance and funding structures cited as the main reasons. KnowledgeHut’s 2025 State of Agile found that agile adoption is now stagnating or reversing in many enterprise environments, with hybrid models becoming the norm.
These regressions are rarely ideological. Most organisations want to be agile. But delivery becomes sequential by structure.
Why Waterfall Reappears by Default
Several factors can pull agile programmes toward waterfall behaviours:
- Funding cycles require fixed scope and budget commitments before discovery
- Governance models rely on stage gates, rather than continuous assurance
- Supplier contracts focus output completion over outcome delivery
- Compliance processes are serial in nature, with formal sign-offs and audit trails
In the public sector, the National Audit Office has repeatedly highlighted how legacy estates, inflexible procurement and capacity gaps create barriers to agile working. The State of Digital Government Review 2025 confirms that many central government services still rely on systems more than two decades old, with modernisation constrained by high operational risk and fragile dependencies.
In this environment, teams may adopt agile practices within their sprint cycles, but the programme remains governed by linear constraints, creating hidden waterfalls.
Recognising Hidden Waterfalls Before They Set In
Hidden waterfalls rarely announce themselves. They emerge gradually, often masked by functioning agile rituals. But several indicators can signal that a programme has shifted from iterative delivery to sequential progression:
- Sprint goals are increasingly defined by legacy parity rather than user outcomes. Backlog items begin to reference "the old system does X" as the primary acceptance criterion, rather than solving a validated user need.
- Discovery stops but requirements keep growing. The team completed a discovery phase early in the programme, but new requirements continue to surface from legacy behaviours that were never formally captured. Each one is treated as an exception rather than evidence of a structural gap.
- Release planning compresses into a single milestone. Despite iterative development, the programme converges on a single go-live date with limited rollback options, often driven by contract, funding or political commitments rather than technical readiness.
- Testing becomes regression-dominant. The majority of test effort shifts toward proving that the new system reproduces existing behaviour, rather than validating that it meets redefined needs.
- Stakeholder confidence depends on sign-off, not evidence. Progress is measured by stage-gate approvals and documentation completeness rather than working software, user feedback or operational metrics.
None of these indicators are necessarily failures in their own right. However, when several appear together, they suggest the programme has structurally reverted to sequential delivery, regardless of the methodology it reports.
Modernisation Approaches
Projects that aim to replace legacy systems in a single release, often called “big bang” delivery, assume considerable risk. These programmes concentrate delivery dependencies, limit rollback options, and make data migration a single-point failure.
Incremental modernisation strategies can offer a more resilient alternative. Patterns such as parallel run, feature toggles, coexistence architectures and the strangler fig pattern allow systems to be evolved rather than replaced outright.
In one survey, 79% of developers said the strangler pattern reduced project risk, primarily because it isolates change and supports rollback. Incremental delivery also aligns better with governance and assurance frameworks - supporting progressive certification, staged user validation and controlled data migration.
In regulated environments, these approaches can reduce disruption and support operational continuity. They also provide decision-makers with clearer evidence of progress and outcomes at each stage.
Balancing Ambition with Legacy Constraints
Preparing for hidden waterfalls is not an argument for replicating legacy systems. It is a call to interrogate them more rigorously, and to distinguish between what must be retained and what can be rethought.
This involves:
- Identifying which behaviours are regulatory, contractual or operationally essential
- Separating business-critical rules from historical conveniences
- Defining the minimum viable increment that preserves service capability while allowing change
- Designing systems that support evolution rather than frozen replication
These assessments are less suited to be completed through workshops or documentation. Instead they require early and direct engagement with legacy systems, their data models, codebases, interface behaviours and operational roles.
The Role of AI in Surfacing Constraints
AI-assisted tooling offers practical support in navigating legacy complexity. When applied responsibly, these tools can help teams:
- Analyse code to extract business rules and logic paths
- Identify unused or redundant code segments
- Map dependency chains and integration points
- Generate automated tests to capture existing system behaviours
In environments where documentation is sparse and institutional memory has faded, these tools can reduce the time and effort needed to understand legacy systems. Oracle’s whitepaper notes that poor understanding of legacy code is a major cause of data migration failure, an area where AI-driven code analysis can make a measurable difference.
However, it is important to view AI as an enabler, not a decision-maker. Tools can help surface logic and dependency, but they can struggle to decide which behaviours remain relevant or valuable. That task requires domain knowledge, user insight and human judgement.
Preparing for Hidden Waterfalls
Effective preparation involves a combination of technical, governance and delivery decisions:
- Map structural constraints early, particularly data, regulatory and legacy integrations
- Treat legacy systems as evidence, not default specifications
- Select modernisation approaches that allow co-existence and rollback
- Align governance and assurance models to tolerate incremental delivery
- Use AI tools to reduce manual analysis effort and highlight legacy dependencies
The objective is not necessarily to eliminate all waterfall elements but to make them visible and manageable. Programmes that fail to do this often discover late in delivery that they are operating under assumptions that no longer hold, or that were never articulated to begin with.
Why This Step Is Important
Hidden waterfalls are a predictable outcome of unaddressed structural constraints that agile methods alone are not enough to resolve.
Acknowledging this reality early allows teams to structure programmes that are responsive, transparent and recoverable. It enables more realistic delivery planning, supports operational continuity and improves trust between teams and stakeholders.
This step becomes particularly important when delivery timelines are fixed, data quality is uneven or regulatory scrutiny is high.
