A 12-person design agency I've watched operate runs two playbooks at once. Their brand and website work is quoted, scheduled, and invoiced against fixed milestones, because clients buying a rebrand want to know the number and the date before they sign. Their ongoing product design retainer for a fintech client runs in two-week sprints with a shifting backlog, because that client's priorities change every few weeks and nobody wants to renegotiate a contract every time. Same agency, same delivery team in some cases, two completely different models. That's the real decision in front of most services firms: not which methodology is superior, but which one matches the kind of work and the kind of client sitting in front of you.
In this guide
What Waterfall and Agile actually ask of your team Where Waterfall still wins the client conversation Where Agile earns its keep The hybrid most agencies actually run Frequently asked questions
What Waterfall and Agile Actually Ask of Your Team
Waterfall asks you to know the whole shape of the work before anyone starts. Requirements get gathered, a scope document gets signed, a schedule gets built with dependencies laid out end to end, and then the team executes phase by phase: discovery, design, build, test, launch. The client signs off at each gate. This only works if the thing being built is well understood on day one, a compliance-driven system migration, a fixed-scope integration, a government RFP with a defined deliverables list attached to it.
Agile asks the opposite. Instead of a full plan up front, you commit to a short cycle, usually one or two weeks, ship something real at the end of it, and let what you learn from that cycle shape the next one. The backlog is a living list, not a locked contract exhibit. This works when the team, and often the client too, doesn't fully know what "done" looks like until they've seen a version of it. Product teams live here almost by default. So do a lot of marketing and growth engagements where the plan for month three depends entirely on what month one's data says.
The mistake most firms make isn't picking the wrong model, it's picking a model and then running it half-heartedly. A Waterfall project with a scope document nobody enforces is just an Agile project with worse tooling and an angrier client. An Agile project where the client still expects a fixed final price and a fixed feature list on day one isn't Agile, it's Waterfall with extra meetings. Whichever you choose, you have to actually staff, template, and track projects to match it, which is usually the part that falls apart first when a firm is still running everything out of spreadsheets and a shared inbox instead of a proper project tracking setup.
Where Waterfall Still Wins the Client Conversation
Picture a 40-person IT services firm quoting a legacy ERP migration for a manufacturing client. The client's finance team needs a number for a budget approval meeting next Tuesday, and that number needs to hold. Nobody on that finance committee wants to hear "we'll know more once we start sprinting." They want a scope document, a fixed price, a go-live date, and a payment schedule tied to milestones. Waterfall isn't a limitation here, it's the product the client is actually buying: certainty.
Waterfall also wins any time the cost of being wrong late is high. Regulatory filings, safety-critical systems, anything where "we'll fix it in the next sprint" isn't an acceptable answer because there is no next sprint after go-live, not without a formal change order and a re-signed contract. Audits, data migrations with a hard cutover date, anything with a single irreversible launch moment tends to want a plan that's been fully thought through before the first line of work starts, not one that's still being discovered in week six.
- The client needs a number for a budget committee, before work starts, that number has to be defensible and fixed
- The scope is genuinely well understood, a migration, an integration, a build against a spec that isn't going to change
- There's a single hard launch moment, a cutover, a filing deadline, a go-live date that isn't movable
- Procurement or legal requires it, some public-sector and enterprise buyers simply won't sign a contract without a fixed deliverables schedule attached
Where Agile Earns Its Keep
Now picture a software team of eight building a new customer portal for a mid-size logistics company. The client has a rough idea of what they want but admits, honestly, that priorities will shift once real users touch the first version. Locking a 400-line spec today and building against it for six months would guarantee that by month four, half of it is wrong. This is where Agile stops being a buzzword and starts being the only sane choice: ship a working slice every two weeks, get it in front of real users or stakeholders, and let that feedback set the next sprint's priorities.
Agile also earns its keep on retainers and ongoing engagements where there's no single finish line at all, an SEO retainer, a product design partnership, an IT managed-services contract. There's nothing to "finish," so a phase-gated plan doesn't even make sense. What you need instead is a repeatable rhythm: plan a sprint, run it, review it, plan the next one. If your team hasn't nailed that rhythm yet, a solid sprint planning process is worth fixing before anything else, because a sloppy sprint cadence undermines client trust in Agile faster than almost anything else.
Agile fails with clients when the commercial terms don't match the delivery model. If you're running two-week sprints but the client still expects a fixed total price and a fixed final feature set agreed on day one, you haven't adopted Agile, you've just added standups to a Waterfall contract. The methodology and the contract have to move together, or the flexibility becomes a source of conflict instead of an advantage.
The Hybrid Most Agencies Actually Run
Very few firms are purely one or the other once they've been operating for a few years. The pattern that actually holds up in practice looks like this: sell and contract the engagement in Waterfall terms, phases, milestones, a payment schedule the client's finance team can plan around, then run the actual delivery underneath in Agile sprints. The client sees three or four big milestones on a calendar. The team, day to day, is working a backlog in two-week increments, adjusting the plan as they go without needing to renegotiate the contract every time priorities shift slightly.
This only works cleanly if your billing model matches. Fixed milestones paired with time-and-materials sprint work underneath means you need visibility into hours burned against each milestone in near real time, not a reconciliation exercise at invoice time. A firm billing a mix of fixed-fee phases and hourly sprint work needs those numbers to reconcile automatically rather than getting rebuilt in a spreadsheet every month; it's worth comparing plans on the pricing page against how your firm actually structures contracts before assuming one flat billing model fits everything you sell.
The failure mode to watch for is silent scope drift on the Waterfall side wrapped around Agile flexibility underneath. If sprints are genuinely adjusting priorities, someone needs to be tracking whether that drift is still inside the milestone the client already paid for, or whether it's quietly becoming a change order that nobody's flagged yet. That tracking has to happen at the project level, weekly, not discovered at the final invoice.
Run fixed milestones and Agile sprints from the same project
See how Autovella tracks time, budget, and billing against both delivery models without forcing your team into spreadsheets to reconcile the two.
Frequently asked
Yes, and most mid-size agencies already do without naming it. A common pattern is a fixed-scope, Waterfall-style contract and payment schedule wrapped around Agile execution underneath, sprints and backlogs for the team, milestone dates and deliverables for the client and the invoice. The client sees predictability, the team gets the flexibility to adjust the plan as they learn.
Waterfall pairs more naturally with fixed-price contracts because the scope is locked before pricing is set, so both sides know what they're agreeing to. Agile can still work under a fixed price, but it requires capping scope tightly, usually to a fixed number of sprints or a fixed budget of hours, rather than a fixed feature list, since the whole point of Agile is that the feature list is allowed to change.
Don't switch mid-project if you can avoid it, the contract and the client's expectations were set around one model and changing methodology without changing the commercial terms usually causes more confusion than it solves. If a switch is unavoidable, renegotiate the statement of work at the same time, moving from a fixed deliverables list to a sprint cadence with a revised billing structure, so the change is explicit rather than something the client discovers three weeks in.