When people discuss software development approaches, they tend to use two words as opposites: Agile and Waterfall. When trying to describe a failed adoption of agility in their organization, they tend to use any number of pejorative terms including Wagile, Scrumfall, and Water-Scrum. These terms describe situations where waterfall and agile methods are mixed or co-exist within the same organization.
In this article, I will explain that project management is not waterfall, agile is not the opposite of waterfall, and so-called hybrid working techniques are not mere combinations of waterfall and agile.
Project Management
Project Management Institute (PMI.org) is the global leader in building the Project Management Body of Knowledge (PMBOK), providing training and support for project management, and conducting difficult examinations that are used to certify project managers. The primary certification that they offer to the project management community to validate knowledge of the PMBOK is the Project Management Professional (PMP).
PMI defines projects as:
… temporary efforts aimed at creating unique products, services, or results…
and project management as:
managing scope, time, cost, quality, resources, and risk to ensure successful outcomes.
Neither of these definitions align with what software development professionals recognize as waterfall.
While there are many valid criticisms of the value of managing to scope, schedule and cost and whether or not they indicate positive business outcomes, it does not necessarily mean there will be waterfall management of a software delivery lifecycle.
Waterfall
Waterfall refers to a phased gate software delivery lifecycle (SDLC). A phased-gate SDLC is a very specific way of managing large groups of people who are working on a collection of projects organized into large, planned releases which are scheduled out at least a year in advance.
Features:
- Projects are conceived, business cases are built, and then funding is provided and approvals. A release manager in charge of a big release assigns the project to a release date. Other projects from a similar time period are added to the release until what is thought to be capacity is reached, or more funding is added to increase capacity.
- Projects that are all in the same release travel together through this system rather than moving through separately to done on their own. All of the projects in the illustration above currently in requirements cannot move forward to designs until the design teams are done with release 10.6. They all move together.
- Projects are herded like cattle through gates from one activity to the next
- Teams typically function in isolated silos. While one silo handles coding, another is responsible for testing. One team works on a release while another works on a different release.. The releases all move forward when software is released, allowing all of the environments to be scrubbed and rebuilt for the next release.
This system was designed to maximize resource utilization within siloed teams. Anyone familiar with Kanban can see that removing the release assignments from the projects and allowing them to flow independently through the system without the gates would be superior. However, at the time this was developed, that was inconceivable by large companies.
At the time, this system felt highly organized and logical—until the need arose to respond quickly to market changes. Our hurry-up attempts to build software would inevitably be met with “You have been assigned to release 10.6. Your projected delivery date is 7 months from now.”
Projects Are Not Waterfall
Let’s take it easy on our friends who are project managers. They are not the agents of waterfall. They did not design this. It is not a PMI creation, nor is an organization of silos, projects, and large releases a feature of project management. As agile techniques and agile-thinking people became more numerous, this system was seen as the enemy. Project management for some became synonymous with this system.
But waterfall and project management are not the same thing. You probably do not work in a waterfall environment. If you are under 35 in 2025, you likely have never worked in a true waterfall environment. Seeing projects crowded into release batches, moving in lockstep through a rigid system, probably resembles a dystopian software factory designed to fail.
That’s where most big companies were in between 1995 and 2010. For a long time, this was thought to be the most efficient, effective way of ensuring quality.
Hybrid, Wagile, Scrumfall, & WaterScrum
These terms are still widely used by people to describe the way many large companies have implemented Scrum, xP, Kanban, and SAFe in their organizations. Let’s take a look at them:
- Hybrid aka Wagile – Not a hybrid with actual phased gate software delivery, but more likely a hybrid in that some elements of agile practices were adopted, but many were not in favor of leaving status quo control measures in place such as top-down control of capacity, release, tooling, team assignment, and teams constructed around org charts.
- Scrumfall/WaterScrum – I believe this refers to a particular way of misusing Scrum where each sprint has a different function. If you are doing design sprints, build sprints, testing sprints, then yes, you have a mini-waterfall release system. Scrum teams should release when the product owner deems the increment ready and the company is prepared to support it. Design, build, and test were intended to happen with each work item within a single sprint.
The Future of Software Delivery
The misconception that project management and waterfall are the same has persisted for decades, largely because traditional corporate structures often paired them together. However, as agile practices continue to reshape how software teams work, the rigid, phased-gate approach is becoming an outdated relic of the past. Organizations that cling to control-heavy frameworks under the guise of agility risk stagnation, while those that truly embrace iterative, adaptive workflows stand to thrive. Understanding the distinctions between project management, waterfall, and agile is critical—not just for clarity, but for building systems that actually deliver value instead of merely managing constraints.