Project Management Methodologies
A methodology is a bet about how much you know before you start. The six covered here differ mainly in how confident that bet is allowed to be.
What "methodology" means here
A project management methodology is a set of rules for how work gets planned, sequenced and reviewed: who decides what, in what order, and how much the plan is allowed to move once work starts. The methods below differ mainly along one axis: how much they assume you already know about the outcome before you begin.
Waterfall assumes you know almost everything up front. Agile-family methods assume you know comparatively little and plan to learn as you go. Everything else sits somewhere between those two poles, and most real teams end up running a blend rather than any single method exactly as documented.
The main methodologies, at a glance
Six approaches to the same five problems (scope, sequence, capacity, progress, communication), solved in a different order each time.
Plan the whole project in sequential phases (requirements, design, build, test, release) before work starts. Suits domains where requirements are genuinely stable and late change is expensive: construction, regulated hardware, compliance-bound rollouts.
A set of values, not a specific process: favour responding to change over following a fixed plan, and a working result over exhaustive documentation of one. Several concrete frameworks are built on it; it isn't itself a schedule you can follow.
The most widely used agile framework: fixed-length sprints, three defined roles, and a small set of recurring ceremonies. Fits product work that evolves through user feedback and benefits from a regular delivery rhythm.
Continuous flow, no fixed cycles. Work is pulled through a board with a hard cap on how much may sit in any column at once. Suits support queues, operations and any stream of requests that never really stops.
Not a scheduling method so much as a lens: identify and remove the work, waiting and handoffs that don't contribute to what's actually delivered. Usually layered on top of whichever method a team already runs, rather than replacing it.
What most teams actually run: kanban discipline for ongoing work, sprint commitments where a release date needs one, a lightweight roadmap over the top for people who need to see months rather than weeks.
What actually decides the choice
How well is the outcome already understood?
If you could write the final specification today and be confident it's right, waterfall's up-front sequencing is efficient: there's no benefit to paying for flexibility you don't need. If "done" genuinely isn't known until users see a version of it, planning the whole thing in advance just produces a confident wrong answer with a schedule attached.
How expensive is a change discovered late?
Pouring a foundation to the wrong dimensions is expensive to fix. Shipping the wrong onboarding flow to a beta group isn't. That asymmetry, not industry, not company size, is the real variable most methodology choices are optimising for.
Does the work arrive as a stream, or as a project?
Feature development usually has a start and a finish, which suits a sprint-based method. Support, operations and maintenance work rarely stops: new requests just keep arriving, which is exactly what kanban's continuous-flow model was built to handle. Applying sprint cadence to a queue that never empties is a common and avoidable mismatch.
How much experience does the team already have with the method?
A framework run well by an experienced team beats a theoretically better-suited one run by a team that's never done it before, at least in year one. Scrum's ceremonies take a few sprints to stop feeling like overhead; kanban's WIP limits take a few weeks to stop feeling arbitrary. Switching methods and switching teams at the same time makes it hard to tell which change caused which result.
Signs the current methodology is wrong for the work
These are more reliable than a gut feeling, because each has a factual answer:
- Change requests keep arriving mid-sprint into a process that assumed they wouldn't
- Work sits idle waiting for the next planning ceremony instead of being pulled when capacity frees up
- A commitment made months ago is now the reason nobody will say what's actually true today
- More items are in progress than there are people to work them, and nobody can explain why
- Status meetings have multiplied to fill the gap the methodology left
None of these mean the method is wrong in general, only that it's wrong for this particular shape of work, which is a narrower and more fixable problem. Fixing it is often a matter of adjusting one setting (a shorter sprint, a lower WIP limit, an explicit change-request lane) rather than abandoning the method and starting over with a different one.
Whichever you choose, the tool should follow it, not the reverse
A tool built around one rigid workflow forces every team onto it regardless of fit. ShipSprint's boards carry per-column WIP limits, so a kanban-run team can enforce a real cap rather than a suggested one, while the same board supports a sprint commitment when a release genuinely needs one, with delivery forecasts calculated from the team's own measured velocity as sprints complete, rather than from anyone's optimism. New requests land in a triage inbox instead of someone's messages, which matters most for stream-based teams but costs nothing for project-based ones either. None of this requires committing to a single named methodology and running it exactly as written. Most teams shouldn't, and the tool underneath shouldn't force it.
Common questions
No. Each is a better or worse fit for a specific shape of work, not a better or worse idea in the abstract. A construction firm running kanban and a support team running waterfall would both be fighting their own process daily.
Yes, and most do without naming it. It's common for one part of a team to run continuous kanban-style flow for support and maintenance while another part of the same team commits to sprints for planned feature work, sharing the same board and the same people.
In practice the terms overlap, but "methodology" usually means the practical day-to-day rules for sequencing and reviewing work, while "framework" tends to describe something more formal: a structured, often certification-adjacent system of processes and governance, such as PRINCE2 or the PMI process groups.
Whenever the shape of the work changes materially: a support team taking on a large fixed-scope project, or a product team's roadmap settling into a predictable cadence. Outside of that, revisiting it more than once or twice a year is usually a symptom of something else, not a methodology problem.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required