Agile vs Waterfall: How to Choose for Your Project

Choose waterfall when the scope is known, the requirements will not move, and the work has to happen in a fixed order: a building, a hardware run, a fixed-price contract with dated deliverables. Choose agile when you will learn what is needed by building it: most software, most websites, most internal tools. The real difference is not the paperwork or the meetings. It is when you find out you were wrong. Waterfall finds out late, at testing or at handover, and pays for it once. Agile finds out every couple of weeks, and pays a little each time. Most small teams end up with a mix: a handful of fixed dates on top, and small increments of work underneath.

What waterfall means

Waterfall runs a project as a sequence of phases, each finished and signed off before the next starts. A typical software version goes requirements, design, build, test, deploy, maintain. The requirements document is the contract: once it is approved, a change goes through a change request, is estimated, and is approved or refused. Progress is measured by which phase you are in and whether its gate has been passed.

That structure has real strengths. Everyone knows the scope, the budget and the date before work starts. The documents outlive the team, which matters when a system will be maintained by someone else for ten years. And for work where a late change is physically expensive, such as poured concrete or a manufactured part, deciding everything first is simply correct.

The weakness is the same structure seen from the other side. Nobody sees working results until late in the project, so a misunderstood requirement surfaces at testing or at acceptance, when fixing it costs the most. And the plan assumes the people who wrote the requirements knew what they wanted, which for new software is rarely true.

What agile means

Agile is not a process; it is a set of values. The 2001 Manifesto for Agile Software Development↗ (opens in a new tab) puts four of them in one line each: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. It adds that there is value in the items on the right; the authors simply value the items on the left more. That sentence is often forgotten, and it is why agile does not mean “no plan” or “no documents.”

The twelve principles behind the manifesto↗ (opens in a new tab) turn the values into practice. The ones that most separate agile from waterfall: deliver working software frequently, “from a couple of weeks to a couple of months, with a preference to the shorter timescale”; welcome changing requirements, even late in development; and treat working software as the primary measure of progress. Progress is what you can show running, not which phase you are in.

Scrum and Kanban are the two most common ways of putting those principles to work. Scrum uses fixed-length Sprints with set roles and events; Kanban manages a continuous flow and limits work in progress. The comparison between them is its own question, answered in Kanban vs Scrum. For the wider family, including Lean and XP, see project management methodologies compared.

Agile vs waterfall, side by side

                  Waterfall                    Agile
Plans             Everything up front          A little ahead, often
Scope             Fixed; change by request     Expected to change
Delivers          Once, at the end             In small increments
Progress means    Phase gates passed           Working results shown
Finds mistakes    At testing or handover       Every increment
Customer sees     Requirements, then result    Each increment as built
Documents         Primary, signed off          Just enough to work
Best for          Known scope, fixed order     Uncertain, changing needs

Agile vs waterfall project management examples

Take a regional HVAC company that wants customers to book service calls online. Under waterfall, a business analyst spends six weeks writing requirements for booking, rescheduling, payments, technician routing and text reminders. Design follows, then four months of build, then testing. At launch the dispatchers discover that customers book the wrong kind of visit, because the form asks questions only a technician understands. The fix goes into a change request for phase two.

Under agile, the team ships a bare booking form in three weeks, for one ZIP code, with a dispatcher confirming each request by phone. By week four they know which questions confuse people. Payments come in the second month; routing waits, because dispatchers turn out to be happy doing it by hand. The final system is smaller than the waterfall version and fits what people actually do.

Now take the same company fitting out a new warehouse. The racking must be installed before the inventory system is configured, the fire inspection must pass before anyone moves in, and the lease starts on a date. Nothing is learned by building half a warehouse. This is a waterfall project, and pretending otherwise adds meetings without adding information.

When fixed scope wins

• The requirements are known and stable. Repeat work, such as the tenth office move or a standard compliance upgrade, has few surprises left to discover.
• The order is physical. Construction, manufacturing, events and hardware have steps that cannot start until others finish; a Gantt chart is the right picture for them.
• The contract fixes scope and price. A fixed-price engagement needs the scope written down before signing, and a change process after.
• An outside party must approve the design before work starts. Inspectors, regulators and lenders sign off documents, not increments.
• Late change is expensive for reasons you cannot engineer away: tooling, materials, permits, a launch event that is already booked.

When agile wins

• You do not know exactly what users need, and you will only find out by showing them something.
• Software is the main output. Code is cheap to change, so the cost of learning late is mostly the waiting.
• Priorities move with customers, sales or support. A plan written in January would be wrong by March.
• You want to stop early if the value is not there. Increments that each work on their own let you ship the useful half and cancel the rest.
• The team is small and close to its users. Agile assumes frequent conversation, and small teams already have it.

Hybrids: how real projects mix the two

Pure forms are rare. The common hybrid keeps waterfall’s outer frame, a budget, a scope statement and a few dated milestones, and runs the work inside it in short increments. US federal technology practice has moved this way on purpose. The US Digital Service’s Digital Services Playbook↗ (opens in a new tab) makes “build the service using agile and iterative practices” one of its thirteen plays, with a checklist that asks for a minimum viable product within three months and releases several times a month.

Contracting follows the same idea. The Federal Acquisition Regulation’s section on modular contracting↗ (opens in a new tab) describes splitting a large IT acquisition into successive increments, each one a system or solution that does not depend on any later increment to perform its principal functions. That is a waterfall-style contract structure that still delivers in pieces you can use, which is the hybrid in one sentence.

Other hybrids you will meet: a design phase run as waterfall, with build and test run in Sprints; a hardware product planned with a Gantt chart while its firmware team works from a board; and a fixed-date launch where the date and a minimum scope are fixed, and everything beyond the minimum is negotiable. They all share one rule: decide explicitly which parts are fixed and which can move, and write it down.

What small teams actually do

A team of two to eight people rarely runs either method by the book. What tends to work:

1. A one-page plan with the goal, what is out of scope, and five to eight dated milestones. The project plan template has the shape.
2. A board with the work on it, ordered by priority, where anything can be reordered until someone starts it.
3. Something working shown to the customer or the boss every week or two, even if it is small.
4. A weekly look at the milestones against the open work. If they do not fit, cut scope, add people or move the date, and say which.
5. A written record of the decisions that fixed scope, so nobody relitigates them in month three.

That is agile delivery inside a light waterfall frame, and it is honest about both halves. If your team keeps starting things and not finishing them, the fix is a limit on work in progress; Kanban WIP limits covers how to set one.

Where fenbs fits

fenbs is a kanban-style board, so it serves the agile half of a hybrid. A board has four fixed lanes, To Do, Next Up, In Progress and Completed; tasks are a feature, an enhancement or a bug, with a priority from 1 to 10 where 1 is the most urgent. Each task has a note for the problem, a plan for how it will be done, and a test status with test notes, which is where “working results shown” gets recorded. It has no sprints, no due dates and no Gantt view, so the dated milestones of the waterfall frame live in your plan document, not in fenbs.

The scope decisions have a home, though. The Decisions and rules page records what was decided and by whom, the decider is always a person, and every AI assistant connected over MCP reads the rules before it starts work. History records who changed what, whether a person or an AI assistant, so a scope change mid-project leaves a trail.