task-ops
The agile versus waterfall question almost never arrives as a genuine choice between two methods. It arrives as a symptom. Either a plan that was agreed in month one no longer matches what the team is building, or a team that iterates cheerfully cannot tell a client when anything will be finished. Both problems get labelled as a methodology problem, and neither is solved by adopting a methodology.
There is one variable that decides which shape fits, and it is not team size, industry or seniority. It is how often the scope moves after work has started. Everything else in this comparison follows from that.
Waterfall is a sequence of phases where each one is finished and signed off before the next begins. Requirements, then design, then build, then test, then release. The artifact that connects two phases is a document, and the document is the contract.
What that buys is a date and a number you can defend. If the requirements are genuinely known, a sequential plan produces a schedule, a budget and a scope that a third party can hold you to. Nothing in agile gives you that with the same confidence, because agile deliberately declines to fix all three.
What it costs is the price of being wrong early. A misunderstanding in the requirements phase is cheap to correct in week two and expensive in month five, because everything built on top of it has to move. The sequential structure does not create that cost, but it does delay discovery of it, since the first moment anyone outside the team sees working software is after the build phase.
The second cost is quieter. A sign off makes changing your mind an administrative event. That is exactly the point when requirements are stable, because it stops scope drifting. It is a serious problem when requirements are not stable, because the team will keep building what the document says rather than what is now needed, and everyone involved will know it.
Agile fixes time and resources and lets scope move. Work is broken into iterations, each one ends with something demonstrably working, and the order of what comes next is reset at the end of each iteration based on what was learned.
The commitment being made is not to a faster delivery. It is to a feedback loop, and that loop has a price. Someone with the authority to decide priorities has to be available every iteration, not at the start and the end. Teams that adopt agile ceremonies without that person produce the same plan they would have written up front, executed in two week slices, with more meetings.
The second commitment is to working increments. If the thing produced at the end of an iteration is a design document or a half wired feature behind a flag nobody can click, the loop is not closed and the feedback does not arrive. Iterating on unverifiable output is the most common way an agile adoption produces waterfall results at a higher meeting cost.
Inside agile, two different structures get used interchangeably and should not be. Scrum fixes a time box and a committed set of work, then protects both. Kanban does not use a time box at all. It limits how much work is in progress at once and pulls the next item when capacity opens up.
The choice between them also follows from scope stability, one level down. Scrum suits work that can be planned two weeks at a time and protected from interruption. Kanban suits work that arrives when it arrives, such as support, operations or a small agency handling client requests, where a two week commitment would be broken by Wednesday.
| Waterfall | Agile | |
|---|---|---|
| What is fixed | Scope | Time and capacity |
| What moves | Time and cost | Scope |
| How change is handled | Change request, re-approval | Reordering the backlog |
| When working output first appears | After the build phase | End of every iteration |
| Definition of done | Phase signed off | Increment works and is accepted |
| Who sets priority | Agreed once, up front | Someone available every iteration |
| What reporting looks like | Percent complete against plan | What shipped, what carried over |
| Where it fails | Requirements turn out to be wrong | Nobody can say when it will be done |
| Best suited to | Known scope, external deadline, fixed price | Unknown scope, product work, ongoing service |
The row that matters most is the last but one. Both methods fail, and they fail in opposite directions. Choosing between them is choosing which failure your organisation can absorb.
Here is a practical way to answer it, using evidence you already have rather than a preference.
Look back at the last three projects the team finished. For each one, count how many times a requirement changed after the work on it had started. Not how many small clarifications, but how many times something built had to be redone or abandoned because the understanding of what was wanted changed.
If the answer is zero or one, the scope was stable. A sequential plan with a gate before each phase will cost less in overhead and will give the organisation the date and figure it wants. Running iterations over stable requirements adds ceremony without buying information.
If the answer is three or more, the scope was not stable, and a sequential plan did not fail because it was executed badly. It failed because it was asked to commit to something nobody knew yet. Shortening the loop is the fix.
If the answer is two, the honest reading is usually that part of the work was stable and part was not, which is the situation most small teams are actually in.
There is a second test worth running. Ask who will decide priorities in week six. If the answer is a named person who will be reachable, agile is available. If the answer is a committee that meets monthly, the feedback loop cannot close faster than the committee, and a sequential plan at least admits that.
Iterations are not free, and there are situations where the sequential shape is straightforwardly correct.
Work with an external approval step. A regulatory filing, a safety certification or a legal review is a gate whether you name it one or not. The approval cannot be iterated, so the work leading up to it is sequential by nature.
Fixed price contracts. If the price is agreed against a scope, then scope is fixed by the contract, not by the method. A team can still work in iterations internally, but the commercial frame is sequential, and pretending otherwise makes the change conversation harder, not easier.
Physical or irreversible dependencies. Hardware orders, print runs, venue bookings and construction sequences cannot be reordered because the backlog changed. Anything with a lead time behaves like a phase.
Handoffs between organisations. When a different company builds the next stage, the document is the interface, and the document has to be finished.
The useful habit is to identify the gates that genuinely exist and stop apologising for them. A plan with three real gates and iterative work between them is more honest than either label on its own.
Both shapes fail for the same reason more often than for any technical one: the role the method depends on is vacant.
A sequential plan depends on someone who can say what is wanted, in enough detail to be built from, before anything is built. That is a harder job than it sounds, and it is a different skill from approving work once it exists. When the requirements phase is run by people who will recognise the right answer when they see it but cannot describe it in advance, the document produced is a guess with signatures on it. The gate then does damage rather than preventing it, because it converts a guess into a commitment.
An iterative plan depends on someone who will choose, repeatedly, in public, what not to do next. That is the part organisations underestimate. Every iteration boundary is a small act of saying no, and if the person who is meant to do it defers instead, the backlog grows and the team ends up carrying every stakeholder's priority at once. The symptom is an iteration that finishes with most items partly done.
There is a third role both shapes need and neither names well: whoever keeps the plan and the reality in the same document. In a sequential project that is schedule maintenance. In an iterative one it is grooming. It is unglamorous, it takes a few hours a week, and it is the first thing dropped when the week gets busy. Naming it as someone's job, rather than assuming it happens, changes the outcome more than the choice of method does.
In practice, a team of eight delivering client work runs a fixed outer layer and a moving inner layer. The launch date, the budget and the broad scope are committed to someone outside the team. Inside that envelope, the order of work is reset every week or two based on what testing and review revealed.
This is a legitimate structure and it has one real failure mode: the two layers are maintained in two different places. The committed dates live in a schedule that a manager updates, and the moving work lives on a board that the team updates. Within a month they disagree, and the version the client sees is the one that is out of date.
The requirement that follows is not a methodology. It is that both layers read from the same data. When a card's dates change on a timeline, the board reflects it, and when a card is finished on the board, the timeline knows. Any arrangement where a person is the synchronisation mechanism between a Gantt chart and a kanban board will drift, because the synchronising is invisible work that gets dropped first in a busy week.
That is worth checking before the next project rather than during it. A tool where kanban, Gantt and calendar are three views of one card set removes the reconciliation step, and a tool where they are separate modules does not. The full comparison set lays out where several common products put that boundary, and the Features page shows what one card set carrying every view looks like in practice.
Count the scope changes in the last three projects, decide from that number rather than from preference, and then write down which gates in your process are real external approvals and which are habit. Once the layers are named, put the committed dates and the moving work in the same place so nobody has to reconcile them by hand, which is the one thing Pinateca is built to remove.
Yes, and for most small teams delivering client work that is what already happens. The outer commitment to a date and a budget behaves sequentially, while the order of work inside the envelope is reset each iteration. The risk is keeping the two layers in separate tools, which makes them disagree within weeks.
If a price has been agreed against a defined scope, the commercial frame is sequential regardless of how the team works day to day. Iterating internally is still useful for reducing risk, but scope changes will need a change request, because the contract fixed the scope rather than the time.
No. It means the plan is revised on a cadence rather than approved once, and documentation is produced where it is read rather than as a phase deliverable. Teams that drop documentation entirely usually discover the gap at handover, when someone new has to understand a decision made a year earlier.
Report what shipped and what carried over, per iteration, rather than a percentage against a plan. Clients who ask for percent complete are usually asking whether a date is still reachable, so pair the iteration record with a timeline view of the committed dates. That answers the real question without inventing a number.
Requirements changing more than twice after work on them had started, across several projects. At that point the plan is not being executed badly, it is being asked to commit to information nobody had. Shortening the loop between building something and showing it to whoever decides is the fix.