The short version: Waterfall, Agile (Scrum and Kanban), Lean, Six Sigma, PRINCE2 and Critical Path are the methodologies you’ll meet in real workplaces, and none of them fix a project on their own. The framework matters far less than most consultants want you to believe. Pick one that matches how your team works, run it for one real project before you buy any training, and be honest about which bits you’ll quietly drop after week three, because you will drop some bits.
Why this list gets oversold
I’ve sat through more “which methodology should we adopt” workshops than I can count, run by people who make their living selling the workshop. Here’s the bit they leave out: the methodology is rarely the reason a project fails. Poor ownership, unclear decision rights and a founder who still wants to approve every piece of copy personally will sink Scrum, Waterfall, PRINCE2 or anything else you bolt on top of it.
I saw this close up in 2019 with a 40-person marketing agency near Reading. They’d just spent about 12,000 pounds sending the whole team on Scrum training, complete with certified Scrum Master. Two months later, the daily standups had turned into status reports read out loud to the founder, and the sprint retrospectives had quietly stopped happening at all. The problem wasn’t Scrum. The problem was that the founder still signed off every piece of content herself, which is the opposite of what self-organising teams need. You can’t run Agile with a Waterfall approval chain sitting on top of it, and no framework fixes that.
So read the list below as a set of tools, not a religion. Here’s what each one is, where it comes from, and where it falls apart in practice.
Waterfall: the one everyone claims to have abandoned
Waterfall is the original linear model: you scope everything up front, then move through phases (requirements, design, build, test, launch) in strict order, one after the other, with sign-off between each stage. It came out of manufacturing and construction, where you can’t build the second floor before the foundations are set.
It works well when:
- the requirements are stable and unlikely to change (a compliance filing, a fixed-scope website build with a signed contract)
- the client or stakeholder needs a fixed price and fixed date before work starts
- you’re managing physical or regulated work where redoing a stage is expensive or unsafe
It falls apart when the market moves faster than the plan, which is most marketing, product and AI-adoption work today. PMI’s Pulse of the Profession research has repeatedly put average waste from poor project performance at around 10% of every pound spent, and rigid Waterfall projects are where a lot of that waste hides, because nobody wants to reopen a “finished” phase even when the assumptions behind it are now wrong.
Here’s the uncomfortable bit: most organisations that say they’ve “moved to Agile” are still running Waterfall underneath. They have a project charter, a fixed budget, a fixed launch date agreed six months out, and a single big sign-off at the end. Calling the daily meeting a “standup” doesn’t change any of that. If your budget and deadline were fixed before anyone did any discovery work, you’re running Waterfall with Agile vocabulary, and that’s fine, but be honest with the team about it.
Agile: Scrum and Kanban are not the same thing
Agile isn’t a methodology on its own, it’s a set of values from the 2001 Agile Manifesto, favouring working software over documentation, responding to change over following a plan, and people over processes. Scrum and Kanban are the two frameworks people run underneath that umbrella, and they behave very differently.
Scrum
Scrum organises work into fixed-length sprints, usually one or two weeks, with a defined set of roles: Product Owner (decides what gets built), Scrum Master (removes blockers, protects the process), and the delivery team. Each sprint ends with a review of what shipped and a retrospective on how the team worked. It suits product and software teams with a backlog that changes based on user feedback.
Where it breaks: teams whose work is dominated by external, unpredictable requests, like a client services team fielding urgent briefs, or a small agency where the founder is also the main salesperson bringing in new fires every day. Scrum needs a stable, protected sprint, and if leadership keeps interrupting it with “urgent” work, the framework collapses within a month, which is exactly what happened at that Reading agency.
Kanban
Kanban is a visual pull system: a board with columns (To Do, In Progress, Review, Done), a limit on how many items can sit “In Progress” at once, and continuous flow instead of fixed sprints. No prescribed roles, no mandatory ceremonies. It came from Toyota’s manufacturing lines in the 1940s, where the idea was to only pull the next part when there was capacity to work on it.
Kanban suits support teams, content pipelines, and anywhere work arrives unpredictably. I run most of my own content production on a simple three-column Kanban board, because a fixed two-week sprint doesn’t match how a guest podcast invite or a breaking industry story lands in my inbox.
Lean: cutting anything that doesn’t add value
Lean, also from Toyota, is built around identifying and removing waste: waiting time, unnecessary approvals, rework, and features nobody asked for. In a project management context it means mapping the full value stream of a piece of work and cutting every step that doesn’t directly serve the end result.
Practically, this looks like asking, for every stage of a project: does the client or end user care about this step, or does it only exist because that’s how we’ve always done it? I’ve killed internal approval steps in client campaigns purely by asking that question out loud in a review meeting, and watched turnaround times drop from ten days to four, with nobody able to explain what the extra six days had ever added.
Six Sigma: the statistics-heavy cousin
Six Sigma focuses on reducing defects and variation using data, following a structured cycle called DMAIC: Define, Measure, Analyse, Improve, Control. It comes from Motorola in the 1980s and got popularised hard by General Electric under Jack Welch. Practitioners earn belts (Green Belt, Black Belt) much like martial arts, with training courses typically running from a few hundred pounds for online Green Belt courses up to several thousand for in-person Black Belt certification.
It’s built for high-volume, repeatable processes where a small defect rate has a big cost, think manufacturing lines, call centre quality, or claims processing. It’s overkill for a five-person marketing team launching a new landing page, and I’ve seen it imposed on teams like that purely because a new operations hire had a Black Belt and wanted to use it. If your “defects” are one-off creative decisions rather than repeated process errors, Six Sigma is the wrong tool.
PRINCE2: the UK’s preferred framework for a reason
PRINCE2 (PRojects IN Controlled Environments) is a structured, stage-gated methodology built by the UK government and still required or preferred across most UK public sector and many corporate projects. It defines seven processes, seven themes and seven principles, with heavy emphasis on the Business Case, clear roles (Project Board, Project Manager, Team Manager), and formal stage boundaries where the project must justify continuing.
Foundation certification in the UK typically costs somewhere between 500 and 900 pounds depending on provider, and the qualification doesn’t expire, unlike PMP which requires ongoing professional development hours to maintain. PRINCE2 suits larger, higher-risk projects where governance and audit trails matter, government contracts, regulated industries, anything with multiple external stakeholders who need documented sign-off.
For a small business rolling out a new CRM or running an AI pilot with six people, full PRINCE2 is usually far more paperwork than the project deserves. I’ve watched a client team spend more hours writing the Project Initiation Document than they spent on the actual pilot, which is exactly backwards.
Critical Path Method: the bit nobody explains well
Critical Path Method (CPM) is less a full methodology and more a scheduling technique that sits inside Waterfall and PRINCE2 projects. You map every task, how long each one takes, and which tasks depend on which others. The “critical path” is the longest chain of dependent tasks that determines your minimum project length. Delay anything on that path and the whole project slips. Delay a task off that path and, up to a point, nothing happens.
Here’s a simple example. Say you’re launching a new website with five tasks: content (5 days), design (7 days), development (10 days), which can’t start until design finishes, testing (3 days) after development, and legal review (2 days) which can run at the same time as testing. The critical path is design then development then testing: 7 plus 10 plus 3 equals 20 days. Content and legal review both have slack, so as long as they finish before their dependent task starts, they’re not driving your deadline. Knowing this stops you panicking about the wrong delay and wasting management attention on a task that doesn’t move the launch date.
Hybrid: what most working teams run without saying so out loud
Almost nobody runs a pure version of any of these once a project has been live for six months. Real teams mix a Waterfall-style fixed scope and budget at the top with a Kanban or Scrum-style delivery process underneath, add a lightweight stage gate borrowed from PRINCE2 for anything over a certain budget, and drop most of the ceremony that doesn’t earn its keep. That’s not a failure to commit to a “proper” framework, it’s what happens when a framework meets the mess of actual work.
The uncomfortable truth is that most methodology adoption in small and mid-size businesses is theatre. Teams add the vocabulary, the board, the standup, sometimes the certification, without changing who holds decision-making power. If the same one or two people approve everything regardless of what the framework says about self-organising teams, you’ve changed the wallpaper, not the house. I’d rather see a business run an honest, undocumented, slightly messy process where everyone knows who decides what, than a fully certified PRINCE2 rollout where the Project Board rubber-stamps whatever the CEO already decided in the corridor.
How to pick one, step by step
- Write down whether your scope and budget are fixed before work starts, or expected to change as you learn. Fixed points toward Waterfall or PRINCE2. Changing points toward Agile.
- Count your team size and how work arrives. Small team, unpredictable incoming requests: Kanban. Product team building toward a roadmap: Scrum.
- Check whether your risk is regulatory or reputational (government contract, financial services, healthcare admin, not clinical content): lean toward PRINCE2 for the governance layer.
- Check whether your problem is repeated errors in a high-volume process: that’s Lean or Six Sigma territory, not a delivery framework at all.
- Run one real project on your chosen framework for four to six weeks before buying any training or certification for the whole team.
- After that trial, hold one honest retrospective and ask which ceremonies got used and which got quietly skipped. Keep only what got used.
If you’re weighing this up because you’re bringing in outside help to get a new system or an AI-driven workflow off the ground rather than just picking a framework off a shelf, it’s worth reading through what working with an AI implementation coach involves before you commit budget to either the tooling or the training.
Frequently asked questions
Which project management methodology is best for a small team?
For teams under ten people with unpredictable incoming work, Kanban usually fits best because it has almost no ceremony overhead and adapts as requests arrive. If the team is building toward a fixed product roadmap with a stable backlog, Scrum works better despite the extra structure.
Is Agile always better than Waterfall?
No. Agile suits work where requirements are likely to change and stakeholders can review often. Waterfall still suits fixed-price contracts, regulated builds, and physical work where redoing a completed stage is expensive, which is exactly why construction and much government procurement still uses it.
Do I need a certification to use these methodologies with my team?
No certification is required to start. PRINCE2 Foundation, Scrum Master, and Six Sigma Green Belt courses all add credibility for client-facing or regulated work, but a team can run a working Kanban board or a basic sprint cycle with nothing more than a shared board and an agreed set of rules everyone follows.
Can you combine two methodologies on the same project?
Yes, and most established teams do, usually a fixed top-level scope and budget borrowed from Waterfall or PRINCE2 with a Kanban or Scrum delivery process underneath it. The combination only fails when the ceremonies from each framework contradict each other, such as demanding weekly fixed sprints while also promising stakeholders a fully fixed scope agreed six months earlier.
