In my 20+ years, I have observed the fight between Agile supporters and traditional Waterfall people in software development. In most discussions, both are opposite, and the argument becomes more extreme. I often ask myself, “How can I use the good points of both approaches to build better digital products?”

Challenges with traditional models

Why the Waterfall model doesn’t always work

The traditional Waterfall model provides structure and predictability with its step-by-step phases of requirements, design, implementation, verification, and maintenance. However, I have found that it often fails when requirements change (as they always do) or when early feedback would significantly improve the product direction. I don’t want to build a product for two years and find out that it was a bad product; I’d rather know it in the first 90 days itself.

Why the Agile approach doesn’t always work

On the other hand, while Agile methods are good at responding to change and delivering working software quickly, I have seen them struggle with keeping a clear long-term vision. Focusing on short sprints and immediate delivery leads to architecture problems and piles up technical debt. Eventually, this technical debt starts driving the decision-making (subtly, but no one will acknowledge it openly).

A Third Way: My Hybrid Model

“What if” I combine Waterfall’s architectural strictness and long-term planning with Agile’s adaptability? My approach isn’t about compromise but strategically applying the correct method at the right time in the product life cycle. This approach has consistently worked for me in building new digital products.

The Architecture-First Approach

In my model, product development starts with Waterfall-style architectural planning from a long-term vision of the product:

1. Build a complete architecture: I create a paper design that shows what’s possible and impossible from an architectural view.
2. Map improvement paths: I document multiple design options, limitations, and decision points for switching from design-1 to design-N.
3. Establish transparent decision governance: I keep a decision journal to track design choices and assumptions.

Once this foundation is established, I shift to Agile execution:

1. I work with product management to define and deliver the MVP.
2. I implement in sprints focused on delivering working software.
3. I maintain clear KPIs and observability to identify when to move from one design stage to the next.
4. I conduct regular, honest reviews to check whether assumptions and outcomes are consistent.

Key Measures for Design Stage Transitions

A critical aspect of my hybrid approach is knowing when to change from one design stage to the next. At the outset, defining and journaling KPI metrics helps to objectively evaluate them periodically; it also helps not to fool myself and keep treading on the path that isn’t good:

1. Technical Complexity: When codebase complexity reaches a point where changes become increasingly complex, I recognize the need to revisit the design. Though subjective, I take a few hints from the dev team, such as person-dependent and unintended consequences.
2. Maintenance Cost: If my team spends more time fixing bugs than delivering new value, I know it’s time to consider architectural changes.
3. Operating Outlay: In cloud environments, I especially monitor infrastructure, deployment, and monitoring costs to detect architectural inefficiencies.
4. Team Skill Set: I assess whether my team has the expertise to maintain the current design or if a change is necessary.
5. Incremental Time to Build New Features: If similar-sized features take progressively longer to implement, I recognize growing friction in the existing design.
6. Non-functional Requirements: Performance metrics, error rates, and quality indicators guide my decision-making on design changes.

Why Organizations Often Default to Agile: The Hidden Challenges

My experience has revealed several underlying reasons why organizations gravitate toward pure Agile despite its limitations for product development:

Accountability Avoidance

Jeff Bezos, founder of Amazon, puts it this way: “I always point out that there are two different kinds of failure. There’s experimental failure—that’s the kind of failure you should be happy with—and there’s operational failure. We’ve built hundreds of fulfillment centers at Amazon over the years. . . . If we build a new fulfillment center and it’s a disaster, that’s just bad execution. That’s not good failure. But when we are developing a new product or service or experimenting in some way, and it doesn’t work, that’s OK. That’s great failure.”

The waterfall model demands greater accountability from decision-makers at every level. Few want to put their neck on the line for high-stakes approaches with long-term consequences. Almost everyone is comfortable making small, reversible decisions (the Agile way), but hardly anyone wants to make the big, consequential ones required for time-tested architecture.

Supplier Motives

It is like asking a barber if you need a haircut.

External consultants and vendors often prefer complex solutions without accountability. Any feature change means “re-architecting” – and more billable hours. With this model, it becomes easier to add people to manage technical debt than to prevent it in the first place. It is often presented in a way depending upon who built the as-is system.

Team Skill Set Challenges

At the outset, thinking long-term and identifying multiple design options with ambiguity to define decision criteria is a rare skill. Thinking about all possible outcomes with probability is not easy. Balancing domain and technical skills and the ability to apply other industries’ learning in the current context is an art.

Incentive alignment:

I’ve observed no “brownie points” for doing things correctly from the start. The near-term fallacy means teams that spin up more issues (creating fires and putting them out) are seen as “agile” and get more attention than stable teams. Meanwhile, teams that can easily accommodate features due to good initial design are paradoxically considered less agile.

Inability to Say No

Perhaps the most challenging aspect of development leadership is the courage to say “no” to requests that don’t align with the architectural vision. Without this backbone, even the best hybrid approach will eventually fall to short-term pressures.

Avoiding the Technical Debt Trap

A common pitfall in product development occurs when decision-makers don’t understand, care, or are encouraged to understand the technical solution and focus solely on outcomes. This led to teams applying patchwork fixes rather than addressing fundamental design issues.

I address this by:

1. Establishing clear architectural boundaries upfront.
2. Creating a shared understanding between technical and business stakeholders.
3. Using a decision journal to revisit and validate design choices regularly.
4. Focusing discussions on the problem rather than becoming attached to specific solutions.

Conclusion

The debate between Agile and Waterfall need not be binary. By taking an architecture-first approach that uses the strengths of both methods, I maintain a clear long-term vision while adapting to feedback and changing requirements.

The key is balance: enough upfront planning to create a solid foundation and the flexibility to iterate and evolve. I ensure that I build innovative and sustainable products by establishing clear metrics for design stage changes and maintaining open communication between technical and business stakeholders.

For me, the focus is always on the problem, not the solution. When I maintain this perspective, methods become tools to be applied appropriately rather than ideologies to be followed blindly.