The Critical Path · Issue 2 · 2026-10-29

Waterfall, Agile, or Hybrid: picking a method for a small team

Ask five project managers whether to run a project in Waterfall or Agile and you'll often get five confident, contradictory answers. The honest answer is that the methodology should follow the project's shape, not a team's loyalty to a framework. On a small team, picking the wrong one costs you more than it would on a large one, because you don't have the slack to absorb a bad fit.

Here is a practical way to decide, rather than a case for either side.

What each one is actually good at

Waterfall plans the whole project up front: scope, schedule, and budget are set early, and the team works through phases in sequence. Its strength is predictability. If you can define the destination clearly before you start, Waterfall lets you commit to a firm date and price with real confidence.

Agile plans in short cycles and expects the plan to change. Instead of defining everything up front, the team builds a small piece, shows it to someone who'll use it, and adjusts. Its strength is responsiveness. If you genuinely don't know what the final product should look like until people react to early versions of it, Agile gives you a structured way to find out.

Hybrid borrows from both: a fixed outer scope and schedule, agreed with the client up front like Waterfall, with Agile-style short cycles inside each phase for the work that's genuinely uncertain. In practice, hybrid is closer to how most small teams actually work, whether or not they'd call it that.

The question that actually decides it

Before picking a methodology, ask one question honestly: how much of this project's scope could change once the client sees real work?

• If the answer is "almost none" — a fixed migration, a well-specified build, a project where the deliverable is contractually locked — Waterfall's up-front planning is a genuine advantage, not bureaucracy.
• If the answer is "a lot" — new product design, anything where "we'll know it when we see it" is a realistic client response — Agile's short feedback loops will save you from building the wrong thing at full speed.
• If the answer is "the big picture is fixed but the details inside each phase aren't" — which describes most client services work — hybrid is usually the honest fit.

Teams get into trouble running Waterfall on a project that was actually uncertain (the plan quietly rots as reality diverges from it) or running pure Agile on a project the client expected to be fixed-price and fixed-scope (the client feels the ground keep moving under them). Match the method to the actual uncertainty, not to which one is currently fashionable.

What this looks like on a small team

A five-person team doesn't need a certified Scrum setup or a four-phase stage-gate process to get the benefit of either approach. The useful parts are smaller than the methodology:

• From Waterfall: write down scope, budget, and the rough timeline before work starts, and get it agreed in writing. This alone prevents most scope disputes, regardless of what you call the rest of the process.
• From Agile: show the client something real, early and often, instead of waiting until a big reveal. Short feedback loops catch misunderstandings while they're still cheap to fix.
• From hybrid: lock the outer shell (what, roughly, by when, for how much) and leave room to adjust inside it as you learn more.

You can run this with a shared document and a weekly call. The method is a set of habits, not a piece of software.

Signs you picked the wrong one mid-project

It's fine to switch. The signal is usually plain once you're looking for it:

• Running Waterfall: the plan needs a major revision every couple of weeks, and the client keeps changing their mind about requirements you thought were locked.
• Running Agile: the client is anxious about not having a fixed date or total cost, and keeps asking "when will this actually be done."
• Running hybrid: either the outer shell keeps moving (you've drifted into pure Agile without saying so) or the inner cycles have stopped actually changing anything (you've drifted into pure Waterfall with extra meetings).

Naming the drift out loud to the client, and adjusting on purpose, is better than quietly limping along with a method that's stopped fitting the work.

Don't decide this alone, and don't decide it once

The methodology choice affects how the client experiences the whole project, so it's worth a short conversation with them rather than a decision you make and never mention. A client who understands why you're running short cycles, or why the schedule is fixed up front, is a calmer client later when either thing is tested.

It's also worth revisiting at major milestones, not just at kickoff. A project that started genuinely uncertain can become well-defined by month two; a project that started fixed can run into a client who keeps changing direction. The method should be allowed to change when the underlying uncertainty does.

Full disclosure, I'm the founder of ConfidantPM. Its assistant asks about your project's scope and goals up front and suggests Waterfall, Agile, or Hybrid based on your answers, which is a reasonable way to get a first-pass recommendation if you're deciding this cold. It's a starting point, not a substitute for the conversation above.

A quick way to decide

1. How much could the scope realistically change after the client sees real work: almost none, a lot, or just the details?
2. Does the client need a fixed date and price, or room to adjust as you learn?
3. Is the team small enough that a lightweight version of either approach is more realistic than a formal one?
4. Have you agreed the method with the client, not just picked it internally?
5. Is there a planned point to revisit the choice if the project's uncertainty changes?

Answer those honestly and the right method is usually obvious, even if it's not the one you started the conversation expecting to pick.