It makes for a good post. It does not make for a good understanding.
The problem is not that these models are useless. The problem is that they are often presented as stereotypes instead of operating models. In reality, most organisations do not run pure Waterfall or pure Agile. They blend practices depending on the level of uncertainty, regulatory pressure, stakeholder maturity, and delivery risk.
Waterfall Is Not "Just Old"
Waterfall is often described as a linear sequence of phases — requirements, design, implementation, verification, and maintenance handled in order. That sequential structure is why it can feel slow, especially when governance and approvals are heavy. But Waterfall still has an important place in environments where scope needs to be locked down early, documentation matters, and compliance or auditability cannot be compromised.
That is why Waterfall is still widely used in regulated industries and large enterprises. Its weakness is not that it is "wrong"; its weakness is that late change is expensive and misalignment can surface only near the end. Used well, it is a discipline for clarity. Used badly, it becomes bureaucracy.
Agile Is Not Chaos With Nicer Branding
The Agile Manifesto says the highest priority is "early and continuous delivery of valuable software," and it values "working software over comprehensive documentation" and "responding to change over following a plan." The principle is not to build a skateboard and hope it becomes a car. The principle is to deliver working software frequently in small increments, with close collaboration and continuous adjustment.
That distinction matters. Agile is about slicing value, not abandoning structure. It still needs prioritisation, architectural thinking, technical excellence, and a sustainable pace. The challenge is that many organisations do not have the capacity, product discipline, or stakeholder availability to keep feeding the backlog fast enough to make Agile work at its best.
Spec-Driven Development Is Not Spec-Only Delivery
Spec-driven development is being talked about more now, especially with AI-assisted engineering, but it is often oversimplified. In practice, it still depends on clear requirements, design intent, and technical constraints being defined early enough for implementation to be coherent. The point is not to remove architecture or documentation. The point is to make the specification authoritative enough to reduce ambiguity and drift.
That can improve speed and reduce rework, but it does not eliminate maintainability concerns. If anything, it can increase the need for discipline around contracts, documentation, and long-term ownership. Early technical involvement reduces risk, but it does not magically remove complexity.
The Real Answer Is Usually Hybrid
The research on project delivery is clear: hybrid governance is common, and often effective. PMI reports that most organisations use a combination of agile and traditional practices, and that hybrid approaches are a natural evolution rather than a weak compromise. The same research found hybrid approaches can perform well on schedule, budget, and scope, while also improving stakeholder outcomes. PMI's guidance on blending Agile and Waterfall also emphasises governance, predictability, and timely response to feedback as reasons to combine methods.
That matches what most practitioners already know. Different parts of a delivery lifecycle need different levels of certainty. Some work benefits from upfront definition. Some benefits from iteration. Some benefits from close technical collaboration early. Very few real-world problems fit neatly into one box.
A Better Way to Frame It
Instead of asking "which methodology is best?", ask:
- How stable are the requirements?
- How much change do we expect?
- How much compliance or audit control do we need?
- How mature is the team and the product owner function?
- How much technical risk exists early in the solution?
Those questions usually lead to a more honest answer than any cartoon ever will.
The best organisations are not dogmatic. They are selective. They use Waterfall where clarity and control matter, Agile where adaptation and feedback matter, and spec-driven thinking where ambiguity and technical risk need to be reduced early.
Delivery is not a religion. It is a design choice.
#SoftwareDelivery #Agile #Waterfall #SolutionArchitecture #EngineeringLeadership #DigitalTransformation #TechnologyStrategy
The views expressed in this article are those of the author and reflect independent practitioner analysis based on publicly available research and general professional experience. They do not represent the views of any employer, client, or organisation. All frameworks and patterns referenced are illustrative in nature.