Skip to content

Iterative Waterfall vs Scrum: Why “Waterfall in Sprints” Often Fails in Enterprise Projects

Is your Scrum project actually Waterfall in disguise?

Recently, we’ve reviewed several public and enterprise procurement documents where a key requirement is that the project must be implemented using Scrum. However, once we look beyond the label, a different picture often emerges.

The project is planned for 12 months upfront, a fully detailed sprint plan is required before development starts, there is no Product Owner assigned, and progress meetings are scheduled monthly.

This raises a critical question for delivery leaders:

Is this really Scrum or is it Waterfall executed in sprints?

In practice, this hybrid is often referred to as “Waterfall in Sprints”, and in our experience, it is one of the most common reasons Agile projects underperform or fail.

Why “Waterfall in Sprints” fails

1. Inflexibility disguised as Agile

Once the project starts and stakeholders begin reviewing real functionality, it becomes clear that not everything could have been fully defined upfront.

Changes are inevitable, but when sprint scope is locked months in advance, adapting becomes slow and expensive. This directly contradicts one of Agile’s core principles:

Working software over comprehensive documentation

Instead of enabling learning and adaptation, the process becomes constrained by heavy upfront planning and documentation – the thing Agile was designed to reduce.

2. Slow response to change

Traditional Waterfall structures struggle with evolving priorities, new insights, and shifting business needs. When Waterfall governance is simply squeezed into sprint cycles, changing direction mid-project requires re-approvals, replanning, and renegotiation often resulting in delays and inefficiencies.

True Agile delivery assumes that change is normal, not exceptional.

3. Delayed and ineffective feedback

In Waterfall, meaningful feedback typically arrives at the end of a phase or worse at the end of the project – too late to influence outcomes.

When this model is applied within sprints, it undermines the entire purpose of iteration:

  • feedback arrives late
  • issues accumulate
  • course correction becomes costly

Regular stakeholder engagement and fast feedback loops are essential for successful Scrum delivery. Without them, adaptability and progress suffer.

Why hybrid Agile–Waterfall models often struggle

When organizations attempt to “add Agile” without changing their mindset, hybrid models frequently fail, not because Agile doesn’t work, but because it’s implemented incorrectly.

Success depends not just on adopting ceremonies, but on:

  • redefining stakeholder expectations
  • empowering the right roles
  • knowing when (and when not) to apply Waterfall practices

How to avoid “Waterfall in Sprints” 

Educate stakeholders on Agile realities

Many hybrid projects fail because stakeholders expect:

  • fixed scope
  • fixed budget
  • fixed timelines

Scrum offers something different:

  • faster delivery of usable features
  • continuous learning
  • the ability to change direction based on real feedback

Aligning expectations early is critical.

Maintain a truly prioritized backlog

A well-groomed, prioritized backlog is the foundation of Scrum.

Only the highest-value items should enter each sprint and determining that value is the responsibility of a Product Owner. Without this role, sprint planning becomes guesswork rather than value-driven decision-making.

Use Waterfall selectively, not everywhere

Waterfall can be effective in strategic phases, such as:

  • initial planning
  • regulatory requirements
  • system architecture decisions

However, once development begins, teams should transition fully to Agile to enable iteration, feedback, and continuous delivery.

Key takeaway 

Projects fail not because they use Scrum, but because they label Waterfall processes as Agile.

Successful delivery requires:

  • flexibility
  • fast feedback
  • empowered roles
  • incremental value delivery

Scrum is not about running sprints.
It’s about learning, adapting, and delivering value continuously.

At Latvia Technologies (ltech.lv), our delivery values closely align with Agile principles.
We prioritize:

  • regular and effective collaboration
  • fast adaptation to changing business needs
  • working solutions over excessive documentation

If you’re interested in how we structure and manage our projects in practice, let`s get in touch.