You have probably heard it before:
“Most companies end up using some sort of Hybrid Model halfway between Agile and Waterfall.”
Wait. What?
In this article, I want to challenge the idea that there is such a thing as a hybrid model. I will describe three distinct models that often appear in organizations. These models may coexist within the same company, but they are not blended, because they cannot be blended. Each model makes different assumptions and demands different behavior from people and systems.
Waterfall – Phased Gate Software Delivery Lifecycle
Let us begin with a common misunderstanding. Many people use the word “Waterfall” without knowing what it means. They assume it simply refers to having project managers or a top-down approval process. But Waterfall refers to a specific kind of software delivery lifecycle built around phased gates.
Waterfall is a model designed to keep everyone busy all the time. It is a tightly controlled pipeline in which a large batch of work moves through a series of phases guarded by gates: requirements, design, implementation, testing, deployment. Each phase must be completed and approved before the next one begins. Projects are batched into releases and the releases move through the phases with each release occupying a phase of work. Functional silos are always working on a release.
This model is rare today, but where it exists, it often causes:
- Long time-to-market due to overutilization
- Large queues and bottlenecks
The Phased Gate SDLC is optimized for efficiency using control to create savings through economies of scale.
Project-Based Product Development
This is the dominant model in most companies today. It is not Waterfall. The work begins as a project, often with upfront planning, and is later handed off to delivery teams. At that point, the work is broken into smaller pieces. Those pieces may be deployed independently, or they may be stitched back together and released as a batch.
This model introduces many of the same risks as Waterfall, even if the mechanics look different:
- Work is batched, increasing complexity
- Testing and integration become difficult
- Time-to-market slows due to high WIP
- Queueing increases as functional silos and management layers coordinate handoffs
- Higher overhead from needing more coordination
- Employees feel disempowered and disengaged
- Releases are risky and hard to support
- Feedback loops are long leading to infrequent learning
- Continuous improvement stalls because teams do not own the process
The biggest issue is that project-based models rely on the illusion that we can know the future. Scope, budget, and deadlines are all defined upfront. Change is not expected and is often resisted through burdensome change control processes.
Ask any project manager to bet you $1,000.00 that they will deliver their software project on-scope, on-time, and under budget without any changes needed. They will not take the bet. They know that long-range planning like this does not work. PMI did not design Integrated Change Control to help a project change plans frequently and easily. They designed it to control change.
The Project Model is designed to allow large batches of ideas to compete against each other in a free-market economy of product development capacity. Energy is spent on control activities such as escalations, status reports, jeopardies, deadlines, gold-plating, and budget constraints. The Project Model rejects uncertainty.
Empirical Product Development
In an empirical model, change is expected. Uncertainty is acknowledged and embraced. Rather than planning everything far in advance, the focus shifts to the near future. Small batches are delivered quickly and evaluated. Each delivery is treated as an experiment. The team observes the results and uses them to guide the next step. This rapid feedback loop is critical to learning and adapting. The goal is not to stay on plan but to discover a better plan.
To succeed in this model, teams must be empowered. They must be able to make decisions, solve problems, and interact directly with users or customers. This is not possible in an organization dominated by approval-seeking, siloed functions, or command-and-control structures.
Advantages:
- Better outcomes through experimentation
- Less waste on bad ideas
- Easier course correction
- Smaller batches that reduce risk and speed delivery
- Lower queueing
- True continuous improvement driven by team ownership
Co-Existence
When an organization begins experimenting with empiricism, it may start with a single team. That team becomes a test case, surrounded by traditional processes and structures. Co-existence is possible, but only if the team is protected and allowed to operate differently.
At that moment, the organization faces a choice.
Either the team is empowered to work empirically, or it is folded back into the legacy process. What empowerment looks like:
- The team controls its own intake
- Skills and capabilities are placed on the team or made easily accessible
- Team members are dedicated to the team’s work
- The team chooses what to work on from its backlog
- Work is framed as problems to solve, not tasks to complete
- Meetings and status reporting are rethought or removed
- The team talks directly with users and stakeholders
- Tools are selected and configured by the team
If these conditions are met, the team can thrive. If not, it will be agile in name only – another Zombie Scrum or Kanban team going through the motions while producing none of the benefits that lead toward agility.
The “Hybrid Model”
What usually happens looks something like this:
- Scrum (or some other way of working) is adopted in name only, with meetings and roles defined centrally
- Projects are still handed to teams in large batches
- Testing is outsourced
- Tooling is controlled outside the team
- Customer contact is restricted
- The team receives requirements instead of problems
- Team members are shuffled around to solve management problems
- Multiple sources assign work to the team
- Plans and roadmaps are fixed upfront
- Work is released at the end of the project
This is not a hybrid of Waterfall and Agile. It is a traditional project model wearing a thin Agile veneer. There is no empiricism. There is no feedback loop. There is no team ownership. The core system has not changed.
There is no Hybrid
If a company has short cycles, small batches, low WIP, direct user feedback, and fast learning, then agility is beginning to take root. If it does not measure cycle times, manage queues, or enable teams to inspect and adapt, then no matter what roles or meetings it has adopted, it will not produce agility.
I don’t know how there can be a hybrid model. If the team is using empiricism, and is slowly working their way to more frequent feedback, then it is not a hybrid team. It is an agile team working to improve agility. If the team is caught in a traditional organization and not allowed to work that way, then it isn’t working that way. How is that a hybrid? That is only the old system dressed up to look modern.
It is empirical, or it isn’t.
The Journey
Every organization starts from where it is. There is no shame in that. Moving toward empiricism is hard work. It requires discipline, leadership, and commitment. That journey should be honored. But calling a project-driven system a “hybrid model” only obscures the truth. It suggests a compromise has been struck when no real change has taken place.
I believe this thinking is spawned by thinking that Agile means Scrum. When I say agile, I mean maneuverable. A team is not agile because it has meetings and roles. Agile is the outcome that leads to greater outcomes. It isn’t a thing you do. It is the reason you do the things.
If we want to improve, we must first be honest about where we are. And, because this is a Journey, Don’t Stop Believin’.
