Iterative Waterfall
(Image: https://miro.medium.com/v2/resize:fit:1280/0*mJXyxjYHwi93cqlx.jpg)
Recently, we have come across several procurement documents where a key requirement is that the project must be implemented using Scrum. However, as we dive deeper into the details, it’s clear the project is planned for around 12 months, with a fully detailed Sprint plan required upfront. There’s no Product Owner involved, and progress meetings are scheduled monthly. This raises the question: is this really Scrum, or are we looking at what some might call “Waterfall in Sprints”?
In our experience, “Waterfall in Sprints” often leads to failure, and here’s why:
-
Inflexibility – Once the project kicks off and stakeholders start diving into the details, it quickly becomes apparent that not everything was fully thought through in the initial planning. Changes are inevitable, but adjusting a rigid, pre-defined Sprint plan takes considerable effort. This contradicts one of Agile’s core values: “Working software over comprehensive documentation.” Instead of adapting smoothly, the process becomes bogged down by the very thing Agile seeks to avoid—excessive planning and documentation.
-
Slow adoption to changes – Waterfall’s rigid structure is poor at handling changing requirements or priorities, which are common in Agile projects. Even if Waterfall processes are squeezed into sprints, adapting to changes mid-project is cumbersome, leading to inefficiencies and failure to meet evolving needs.
-
Delayed feedback – In a Waterfall approach, feedback often comes only at the end of a phase (such as development), which can be far too late to make meaningful adjustments. When this happens within a Sprint framework, the delay undermines the entire purpose of iterative sprints, preventing quick pivots and slowing down the response to issues. Timely stakeholder engagement and rapid feedback are essential pillars of a successful project, and without them, the project’s adaptability and progress suffer.
When attempting to integrate Agile into traditionally Waterfall-driven organizations, hybrid models often falter due to a lack of understanding and improper implementation. Success lies not only in adopting Agile practices but also in reshaping the mindset of stakeholders, prioritizing tasks effectively, and knowing when to leverage different methodologies.
-
Educate stakeholders on Agile’s benefits – Many Waterfall projects fail in hybrid models due to stakeholder expectations for fixed timelines, budgets, and scope. Educate them on the benefits of Agile, such as faster delivery of working features, more opportunities to change course, and better alignment with real business needs.
-
Prioritize backlog items carefully – Keep a prioritized, well-groomed product backlog, and pull only the highest-priority items into each sprint, focusing on completing high-value items first. Who knows which are items with highest value? – Product Owner. Try and educated why this role is critical for the project.
-
Waterfall for strategic phases only – Waterfall can be useful in initial planning, requirements gathering, or system architecture stages where clear, upfront documentation is needed. After that, transition fully to Agile for iterative development and delivery.
By balancing the right mix of Agile and Waterfall methodologies, and ensuring stakeholders understand the benefits of true Agile practices, projects can avoid the pitfalls of “Waterfall in Sprints” and achieve greater success. The key is in flexibility, rapid feedback, and focusing on delivering value in small, manageable increments.
Latvia Technologies (ltech.lv) values are similar to the Agile values. We prefer regular and effective cooperation, fast adaption to changing market and our number 1 priority is working solution over massive documentation.
If you are interested how we manage our projects, you can check that out here.