IT Project Management Methodologies — Scrum, Kanban, or Waterfall?

Scrum works for products developed continuously with an uncertain scope, Kanban for work with a continuous inflow of tasks without fixed sprints, and Waterfall for projects with a clearly defined, stable scope from the start (e.g. regulatory requirements). Choosing a methodology isn’t a matter of trend — it depends on how much your project’s scope can change along the way.

How do Scrum, Kanban, and Waterfall differ?

Methodology	Work structure	Scope change mid-project	Best for
Scrum	Fixed-length sprints (1-4 weeks), planned at the start of each	Possible between sprints, not mid-sprint	Continuously developed products, uncertain scope
Kanban	Continuous flow of tasks, work-in-progress (WIP) limit	Possible anytime, no fixed cycles	Support teams, maintenance, teams with a continuous inflow of requests
Waterfall	Sequential phases — analysis, design, build, test, deploy	Costly, requires formal change control	Projects with a stable, clearly defined scope (regulations, fixed-price contracts)

When should you choose Scrum?

Scrum makes sense when you’re building something whose final shape emerges along the way — a new product, a feature that needs testing with real users. Regular sprints give you checkpoints to change direction without waiting until the project ends.

When should you choose Kanban?

Kanban fits where work arrives irregularly and can’t be meaningfully boxed into sprints — support teams, system maintenance, teams handling many small requests at once. A work-in-progress (WIP) limit prevents overload without a rigid schedule.

When should you choose Waterfall?

Waterfall makes sense when scope is known and stable from the start — regulatory projects, fixed-price contracts with a detailed spec, systems where mid-build change costs more than careful upfront planning. Rarely used in pure form in digital products today, more common in large integration or enterprise implementation projects.

Can methodologies be combined?

Yes, and in practice most teams do — for example, Scrum at the product team level, Kanban for the support team handling requests for the same product. On the Octopus CRM implementation for a football club, we used an iterative approach closer to Scrum during the build phase, with Kanban elements for ongoing support after launch — a different rhythm for different phases of the same project.

FAQ

Is Scrum better than Kanban? There’s no better methodology in isolation from context — Scrum wins with uncertain scope and iterative work, Kanban with a continuous inflow of tasks without natural cycles.

Is Waterfall outdated? It isn’t outdated, it’s right for a specific type of project — stable scope, regulatory requirements. The problem is applying it to projects with uncertain scope.

Can you change methodology mid-project? Yes, though it costs time to reorganize the team and process — usually done at a phase boundary, not mid-sprint or mid-phase.

Which methodology fits a CRM implementation? Usually an iterative approach closer to Scrum during implementation (scope gets refined working with users), shifting to Kanban for ongoing support after launch.

How do you start an Agile implementation in a company? Start with one team and one project rather than the whole organization: pick a methodology (usually Scrum or Kanban), set a short iteration and regular reviews, and extend the practices to other teams only after a few cycles.

Wondering which methodology fits your project? Get in touch — we’ll match the approach to your project’s real scope and uncertainty.