A client once asked me why their two-week logo redesign needed daily standups, a sprint board, and a retro. It didn’t. Somewhere along the way, “agile” became the default answer for every project, regardless of size, and Waterfall became the word teams were almost embarrassed to say out loud. Neither reaction is right. The method should follow the project, not the other way around.
The Real Question Isn’t Agile vs Waterfall — It’s Predictability
Every methodology decision comes down to one thing: how much do you actually know about the end result before you start? On a project to migrate a client’s brochure site to a new host, I know exactly what “done” looks like on day one — same site, same content, new server, DNS cut over, done. There’s nothing to discover along the way. That’s a Waterfall project even if nobody on the team calls it that.
Compare that to a project I ran last year: a custom booking flow for a clinic chain. We didn’t know how many appointment types they’d need until we sat with three receptionists for a day. We didn’t know if patients would tolerate a multi-step form until we tested it with real users. That project earned its sprints because the requirements were genuinely unknown at the start, not because “agile” sounded more modern on the proposal.
When Waterfall Actually Wins on Small Projects
Small projects are usually small because the scope is tight and well understood — a marketing landing page, a WordPress plugin update, a one-off data migration, a five-page brochure site. Waterfall fits these for three concrete reasons:
- Less overhead per unit of work. A two-week project doesn’t have room for four sprint ceremonies. If your team spends three hours a week in standups and planning on a 60-hour project, that’s roughly 5% of the budget gone to process before a single line of code ships.
- The client already knows what they want. If the client hands you a signed-off design file and copy deck, there’s no discovery left to do. Sprint reviews exist to surface changing requirements — but there’s nothing changing here.
- A fixed-price quote depends on a fixed scope. I’ve quoted plenty of small jobs at a flat fee. That only works if the scope is locked before you start. Agile’s built-in assumption — that scope evolves as you learn — is the opposite of what a fixed quote needs.
On a recent WordPress-to-Shopify content migration for a 40-product store, we mapped every field on day one, wrote the import script, ran it, QA’d it, and shipped in four days. A sprint board for that would have been theatre.
Where Agile Actually Pays Off — Even on Small Teams
The size of the project isn’t the deciding factor — the size of the unknown is. I’ve run two-person, three-week projects that were fully agile because the client themselves didn’t know what they wanted until they saw a working version.
A good test: if you can’t write the acceptance criteria for the whole project today, without guessing, you’re in agile territory. That was true for a chatbot integration I built for a SaaS client — we didn’t know which of the twelve support queries the bot could actually handle well until we tested it against real transcripts. We shipped in one-week increments, cut three of the twelve use cases after week one, and reallocated that time to fixing the two the client actually cared about. A Waterfall plan would have locked in a spec none of us could have written accurately on day one.
Agile on small projects doesn’t have to mean the full ceremony stack either. I’ve run “agile-lite” on two-person teams: a 15-minute Monday planning call, async daily updates in Slack instead of a standup meeting, and a demo every Friday instead of a formal retro. You get the adaptability without paying for the process.
A Simple Way to Decide, Instead of Debating Frameworks
I stopped asking “agile or Waterfall” as the first question. I ask these three instead:
- Can I write the final acceptance criteria today? Yes, with confidence → Waterfall. No, or only a rough draft → Agile.
- Does the client need to see working versions to know if it’s right? If they’re validating against their own gut feeling rather than a spec, build iteratively.
- What does a mid-project scope change cost me? If a change six days into a ten-day project blows up the budget, you need a process that expects change, not one that treats it as a failure.
Most small projects answer “yes, yes, low cost” to the Waterfall side of those questions. That’s exactly why so many small projects run better as a tight linear plan than a sprint cycle nobody has time for.
The Takeaway
Don’t pick a methodology to look modern or to look disciplined — pick it based on how much you genuinely know about the destination before you leave. Small and well-defined: plan it linearly, execute, ship. Small and genuinely uncertain: keep it agile, but scale the ceremony down to match the team size. The mistake isn’t choosing the “wrong” framework — it’s applying a framework’s full overhead to a project that never needed it in the first place.
