Delivery & Governance · 10 min read
Agile, Waterfall or Hybrid? Choose the Method That Fits the Work
There is no best method, only the one that fits how much you know and how costly change is. A simple way to choose, with real project examples.
Dennis AlejoBusiness consultant · Project & operations manager · · 2,247 words
Few topics in project management produce as much heat as the choice between agile and waterfall. Teams form camps. Consultants sell one or the other. Job postings treat the words as badges. Meanwhile, the project in front of you does not care about any of that. It cares about whether the work is well understood, how expensive mistakes are and how many things you do not yet know. Those facts, and not loyalty to a method, should decide how you run it.
This article offers a calm way to choose. It explains what each approach really is, the two questions that point you in the right direction, how to blend them in practice and the mistakes to avoid. There is a short quiz in the middle to test your own project, and I show how the choice plays out for very different kinds of work: a building, a software product, an exploration program and a lodge opening.
What waterfall actually is
Waterfall is the idea that you do the work in sequence: gather requirements, design, build, test, deliver, with each phase finished before the next begins. The picture of a waterfall comes from the way the work flows downward in stages. You will often hear that it originated with a 1970 paper by Winston Royce on managing large software systems. It is worth knowing, as a curiosity, that Royce drew the sequential model in order to point out its risks, and recommended iteration and feedback. Still, the sequential approach became a standard way of organizing large projects, particularly in construction, engineering and manufacturing.
Its strengths are real. It gives predictability: you can estimate total cost and time early, sign contracts against defined scope and coordinate many parties around a plan. It fits work where the sequence is dictated by physics, such as foundations before walls, or by regulation, such as approvals before building. Its weakness is also real. It assumes that you can know what you need up front, and it makes late changes expensive. If the requirements turn out wrong, you discover it at the end.
What agile actually is
Agile grew from software development. In 2001, a group of practitioners published the Agile Manifesto, which values individuals and interactions, working software, customer collaboration and responding to change, while still valuing the items on the other side of each comparison. In practice, agile teams work in short cycles, often one to four weeks, delivering a small working piece each time, collecting feedback and adjusting the plan. Frameworks such as Scrum organize this into roles, meetings and cycles, while Kanban focuses on visualizing work and limiting how much is in progress.
Its strengths are learning and adaptation. When you do not know exactly what the user needs, building a little and showing it is far cheaper than guessing for a year. It keeps the team close to the customer and surfaces problems early. Its weaknesses show up when the end state is unclear and nobody is controlling scope, or when a project needs firm commitments on cost and date. Without discipline, "we are agile" can become an excuse for having no plan.
Two questions that decide most cases
Rather than argue about philosophy, ask two practical questions.
How clear are the requirements? If you can describe what you are building, in detail and with confidence, planning ahead pays. If you will only know what is right after people have used something, building in small steps pays.
How expensive is it to change course late? Moving a wall after the concrete is poured is costly. Changing a button in a software product is cheap. When change is expensive, you invest more in planning and review before committing. When change is cheap, you can afford to learn by doing.
Put the two together. Clear requirements and costly change point toward a plan-driven approach. Unclear requirements and cheap change point toward an agile one. Mixed answers point toward a hybrid. This is not a law of nature, but it explains why the same company can sensibly run a building project and a software project with different methods, and why arguing for one method everywhere is a sign of habit more than logic.
Match the method to the work
Let us walk through several kinds of projects to see how this works in practice.
Construction and fit-out. The physical sequence and the cost of change make planning and baselines central, and tools like the schedule and earned value, discussed in earned value in plain English, fit naturally. But the design phase often benefits from iteration: sketches, reviews with the users and adjustments before drawings are final. Teams that treat design as a series of short feedback loops avoid expensive changes later. That is part of the story in how a clinic opens on time.
Software and digital products. Requirements evolve and change is cheap, so iterative approaches dominate. Even so, a release date promised to customers or a launch event requires a plan. Teams often combine short cycles with a roadmap of larger milestones. For a practical view of how small tech teams keep just enough structure, see shipping SaaS without chaos.
Exploration and research. Here you learn as you go, but each step costs real money. The sensible approach is staged: do a small piece of work, review results, decide about the next. It combines iteration with gates, as in the staged programs of Llama Purisima and the strategy pipeline in Trade Arena.
Hospitality openings. A lodge or restaurant opening is two projects in one. The building follows a plan-driven path. The operation, such as the menu, the service routines and the guest experience, benefits from iteration through trial runs and early feedback, a theme in your restaurant is a project and in the opening of Comtury Lodge.
Process improvement. Small, continuous cycles of change work well, which is the heart of the Japanese idea of kaizen. I am developing a book on how this tradition compares with the American approach to planning and control, and you can read the idea at Kaizen vs. Gantt.
Startups. Early on, uncertainty is huge and agility is a survival trait, but a quarter without a plan is a quarter without focus. The 90-day sprint is a hybrid: fixed three-month frame, flexible tactics inside.
What a hybrid really looks like
A hybrid is not a diluted compromise but a deliberate design. Several patterns are common.
Plan the milestones, iterate between them. You fix the big dates and the final outcome, and inside each phase the team works in short cycles, adapting the details. This respects commitments to customers while allowing learning.
Waterfall for the what and when, agile for the how. Leadership sets the objectives and deadlines. Teams decide how to get there in cycles.
Stage-gate with sprints. The project moves through formal gates, with criteria for each, while the work between gates is iterative. This is common in product development and research.
Different methods for different parts. The physical build is plan-driven, the software that supports it is agile, and the operational preparation is a checklist-driven rehearsal.
In all cases, the elements that matter most are a clear goal, a visible plan with honest dates, and a regular rhythm of review. Those work under any label. Use the quiz below to see which style fits your own project. Tick the statements that are true.
Contracts and agile
A frequent concern is that agile does not fit with contracts that require a fixed price and scope. It can, if the structure is designed deliberately. One option is to fix the time and budget and keep the scope flexible within a prioritized list, agreeing that the lowest-priority items will be dropped if time runs out. Another is to contract in phases: a small first phase to discover and define, followed by a decision about the next. A third is time-and-materials with a cap and regular review points. The change process matters in all cases, as described in how to stop scope creep and in contract risks that quietly cost projects.
Making agile work in a small team
If your situation points to iteration, a few practices make it work without heavy ceremony. Keep cycles short, one or two weeks for most small teams. Limit the work in progress, so people finish before starting something new. Show real working results at the end of each cycle, even if small. Hold a short retrospective, asking what to start, stop and continue, and act on one item. And keep a visible, prioritized list of what comes next, with one person responsible for the order.
Retrospectives are a particularly powerful habit, and they connect to the discipline of learning that I discuss in project closeout and lessons learned that actually get used.
A worked example: launching an online course
To see a hybrid in motion, imagine a small team building an online course with a launch date announced to its audience. This is an invented illustration. The date and the main outcome are fixed, so the launch is planned like a project: a calendar with milestones for the outline, the first module, the platform setup, the pilot and the public launch. Those milestones are the plan-driven skeleton.
Inside each milestone, the team works in one-week cycles. In the first, they record a rough version of one lesson and show it to five people from the target audience. The feedback changes the format of the next lessons: shorter videos, more exercises. In the second cycle they test the platform with a handful of learners and fix the confusing sign-up step. In the third they refine the quiz. Every cycle ends with a short demo and a decision about what to do next.
At the pilot gate, the criteria are written down: at least most pilot learners finish the first module and the support questions are manageable. If the criteria are met, the launch goes ahead. If not, the team uses the buffer they planned to improve first. Notice what the hybrid gave them: a date the audience can trust, and the freedom to discover the right format by testing it. Neither a pure plan nor a pure sprint would have done both.
A one-minute decision guide
When you are short of time, use this rough guide. If you can describe the finished result in detail, change is expensive and many parties depend on the order of work, lean toward a plan-driven approach with interim checks. If the result is unclear, users will only know what they want after seeing something and change is cheap, lean toward short iterative cycles with a prioritized list. If you are somewhere in the middle, which is the most common place to be, fix the milestones and the outcome and iterate inside. Whichever you choose, write down why, so that you can revisit the decision when the facts change.
Common mistakes
Fake agile. The team holds daily stand-ups and calls the work sprints, but the scope is fixed, the plan is rigid and the sponsor expects a final delivery on the original date. That is waterfall with new vocabulary, and it combines the weaknesses of both.
Agile without a plan. Iterating without any view of the destination produces busy activity and no arrival. Even agile teams need a goal, a rough roadmap and an honest estimate of how much can be done.
Waterfall without feedback. A long plan with no review points until the end hides problems. Even the most sequential project needs interim checks, demos or inspections.
Method as identity. Some people defend a method as if it were part of who they are. Treat it as a tool. The question is always "what does this project need?"
Switching labels instead of habits. Changing the name of the method without changing how decisions, reviews and priorities work changes nothing.
Measuring progress by method
Different methods call for different measures. In plan-driven work, progress against a baseline, schedule and cost indexes, and milestone completion are central. In iterative work, throughput, which is the number of items finished per cycle, cycle time and quality after release are more meaningful. In hybrids, combine them: milestones for the big picture and throughput for the detail. Whatever you choose, keep the number of measures small and tied to decisions, as in data-driven project management.
Switching methods mid-project
Sometimes you realize halfway that the method is wrong, for instance that a plan-driven project is discovering its requirements as it goes, or an iterative project has grown so large that coordination is failing. It is fine to adjust. Do it deliberately: explain why, agree on what changes, keep what is working and communicate to everyone. A good moment is at a gate or the end of a cycle. The worst response is to double down because "we always do it this way."
Choosing a method is not a matter of taste. It is a short diagnosis: how clear is the work and how costly is change? Answer those honestly, blend where needed and revisit when the facts change. If you want a second opinion on the right structure for a project you are planning, I do this regularly in my startup advisory work and in Project Focus. For a structured way to learn the formal side, the idea behind PMP Academy is to teach the standard framework without losing sight of practice.
Which method does your team use today, and does it really fit the work? Tell me in the comments.
Frequently asked questions
What is the difference between agile and waterfall?
Waterfall completes phases in sequence, planning and designing before building, which gives predictability when requirements are clear. Agile works in short cycles, delivering small pieces and adjusting based on feedback, which suits work where requirements are uncertain.
When should I use a hybrid approach?
When some parts of the project are well understood and costly to change while others are uncertain. A common pattern is to fix the major milestones and iterate inside each phase.
Can agile work with fixed-price contracts?
Yes, with careful design: fix time and budget and keep scope flexible within a prioritized list, contract in phases, or use time-and-materials with a cap and review points. A clear change process is essential.
How do I choose a project method?
Ask how clear the requirements are and how expensive it is to change course late. Clear requirements and costly change favor planning. Unclear requirements and cheap change favor iteration.
Join the conversation
Did this help? A quick reaction tells me what to write next.
Be the first to react.
Loading comments…