Waterfall, Scrum, Kanban and hybrid: choosing an approach
The “waterfall or agile” argument is rarely useful: you pick the approach for the project, not the other way round. Here is a short description of the main approaches and the signs that tell which one fits.
Waterfall
Work runs in sequential phases: requirements, design, implementation, verification, handover. Each phase starts when the previous one ends. At the centre is a plan with dates and dependencies, usually a Gantt chart.
Fits when the result is known up front and expensive to redo: construction, manufacturing, hardware roll-outs, projects with fixed dates and external contractors.
Weak spot: change. If requirements shift halfway through, the plan has to be rebuilt.
Scrum
Work runs in short iterations — sprints of one to four weeks. At the start of a sprint the team picks items from a prioritised backlog; at the end it shows a working result and holds a retrospective. There are three roles: product owner, developers and Scrum Master.
Fits when the result cannot be fully described up front and frequent feedback matters: products, services, user interfaces.
Weak spot: long commitments. Scrum answers “what will we do this sprint” well, and “when will the release six months out be ready” less well.
Kanban
No iterations: work items flow through stages on a board (say “queue → in progress → review → done”), and the number of items in progress at each stage is limited. The point is to see the flow and remove bottlenecks.
Fits flow work: support, operations, request handling, content.
Weak spot: projects with a shared deadline and dependencies between tasks — the board does not show what will move the end date.
PRINCE2
Less a way to do the work than a system for governing a project: the project is split into management stages, and at each stage boundary a decision is made to continue, change or stop; roles and authority are clearly defined; changes and risks follow formal procedures.
Fits large organisations and the public sector, where control, reporting and clear decision points matter.
Weak spot: bureaucracy on small projects if applied in full without tailoring.
Hybrid
One workable option is a combination: a plan at the top with phases, milestones and critical dependencies, and agile work below — teams in sprints or on boards.
A device launch, for example, has hard milestones — factory firmware, certification, start of sales. They sit well on a Gantt chart, while feature development inside each phase runs in sprints in the issue tracker.
How to choose: a short table
| Situation | What fits |
|---|---|
| Result known, rework expensive, contractors involved | Waterfall |
| Result emerges as you go, frequent feedback needed | Scrum |
| A stream of similar requests with no shared deadline | Kanban |
| Large organisation needing formal decisions and reporting | PRINCE2 (tailored) |
| Hard milestones on top, agile development inside | Hybrid: plan + sprints |
The main point
A methodology is a tool, not a goal. If the team runs Scrum and management needs a release date, you need a plan above the sprints. If the project is waterfall but requirements keep changing, short cycles of checking the result help.
Where to run it
Etapero holds the top level of a hybrid project — the work breakdown, milestones, critical path and baseline — while the teams’ issues stay in Jira and their statuses flow into the plan. More in “Jira and the project plan”.