Menu
Rather than bore you with yet another detailed description or comparison of Waterfall, Agile, and Hybrid models—of which there are already over 100,000 articles—I will instead attempt to do something more useful: propose a way to fix the broken-by-design Hybrid model. There are a few variants of the Hybrid model, but the one show below seems to be the most common.
We crave quick results that demonstrate progress, often rushing through the initial Waterfall stage. Many of you have likely seen the consequences: inadequate planning, overlooked requirements, and flawed designs—all of which surface later during implementation, derailing timelines. I once had to produce a design in just two days for a project that would span three years and cost $1 million. The team was already in Agile mode, and the design was merely a formal checkbox to close a project gate. Do I need to say more?
On the flip side, some teams take the opposite route, investing immense effort into crafting an exhaustive design. In theory, this should set the project up for success.
But here’s the reality: it doesn’t matter whether you rush, strive for perfection, or aim for a balanced approach. The next phase—the Agile phase—still has plenty of opportunities to mess it all up.
The Agile model, while dynamic and engaging, can sometimes create an illusion of progress. The high pace, frequent human interaction, and constant “fixing” of things give the impression that the project is moving forward effectively. After all, something is always happening. However, without sufficient planning and a commitment to revisiting the requirements and design, how can we be sure that we’re actually doing the right thing? Planning, in itself, is a form of progress—it provides clarity, aligns the team, and builds a strong foundation for the work ahead. Without this clarity on the end goal, we risk wasting energy on the wrong tasks.
“We should communicate more with other teams,” was the consensus after a discussion that followed a presentation titled “Are we working Agile enough?” at a company I once worked for. I suppose I was the only one who disagreed. In fact, I felt the exact opposite—there was already far too much communication.
Teams were constantly engaged in lengthy discussions on Slack, debating what to tweak or how to get things working again after the latest build broke. This happened every single day, and it wasn’t limited to just one thread. There were multiple conversations, often repeating the same points already discussed elsewhere by other developers.
Without clear ownership or channels, conversations spiral into repetitive or fragmented discussions, creating a reactive culture. Teams often spend time firefighting instead of taking a proactive, structured approach to problem-solving.
Sure, there were occasional discussions about design and even requirements, but rarely documented. It felt like we were moving at the speed of light—yet going in circles.
If you’re going to combine the two models, then do it like you mean it. Integrate all the steps into a loop and repeat them regularly. But be pragmatic. This doesn’t mean spending hours revisiting requirements, redesigning everything, or replanning the project each time. That’s not the point. The point is to acknowledge that planning, requirements, and design need periodic updates. The Agile loop can still be there.
Lengthy discussions should be brought to the drawing board and documented properly. Once updated documentation is made available, it becomes much easier for everyone in the project to understand the needs and changes. I promise you, the next discussion will be shorter and more focused because the groundwork will already be clear. There’s no need to retrace the same tangled paths over and over again.
Here’s how you can integrate periodic and ad-hoc revisits into a project timeline:
| Phase/Activity | Waterfall Revisit Type | Timing |
|---|---|---|
| Planning | Periodic | Defined as part of initial planning |
| Post-Sprint Reviews | Periodic | After every 3–5 sprints or Agile cycles. |
| Major Milestones | Periodic | Before transitioning between project phases |
| Requirement management | Ad-Hoc | As soon as there are changes in requirements or stakeholder needs, or confusion is identified |
| Design | Ad-Hoc | When significant flaws or gaps emerge |
| Scope Changes | Ad-Hoc | After major changes in scope or priorities |
Just a few adjustments to the Hybrid model can significantly improve project execution and enhance the quality of the final outcome:
Schedule Regular Reviews: Plan short, periodic reviews to revisit requirements, design, and planning. Use these sessions to make adjustments based on lessons learned during the Agile phase.
Maintain Living Documents: Keep key documents updated as the project evolves. This prevents redundant discussions and ensures alignment across teams.
Leverage the Best of Both Models: Use Agile’s flexibility for iterative delivery while preserving Waterfall’s discipline for critical milestones and tracking requirements.
Define Clear Ownership: Ensure teams know who is responsible for decisions, documentation, and communication. Clear ownership prevents overlap and minimizes confusion.
The Hybrid model isn’t inherently broken—it’s just often poorly executed. By embracing the strengths of both Waterfall and Agile while addressing their weaknesses, we can create a system that is both structured and adaptable. The key lies in intentionality: revisit requirements and design periodically, streamline communication, and document the journey. With these adjustments, the Hybrid model can deliver on its promise of combining the best of both worlds.
Strøket 3, Asker, Norway Krambugata 14, Trondheim, Norway Tordenskiolds gate 2, Oslo, Norway
