Project Management Methodologies Compared: Waterfall, Agile, Kanban and Friends (Without the Bar Fight)

Picture a conference bar at eleven at night. Four project managers are arguing. One says that planning everything up front is the only grown-up way to build anything. Another says that plans are fiction and the only honest thing is to ship something small on Friday. A third has drawn a board of sticky notes on a napkin and is explaining, with the calm of a monk, that all of this could be solved by limiting how many things are in progress. The fourth, who has a certificate on the wall of the office he is not in, quietly orders another coffee and says, "Well, it depends."

That fourth person is right. He is also the most annoying person in the bar, because "it depends" is not an answer until you say on what. This article is my attempt to say on what.

If you run a business, a building project or a team of five, you do not need to join a fan club. You need a way of working that matches your project, one that your people will actually follow on a Tuesday afternoon when nobody is watching. So let us walk through the main methods in plain English, see where each shines and where each one breaks, and finish with a short tool that suggests where to start.

Why there are so many methods

Projects are not all the same animal. Building a bridge, launching a mobile app and opening a restaurant share a vocabulary, but they behave very differently when something changes. If you decide late that the bridge should be wider, you will have a very bad week. If you decide late that the app's button should be blue, you will have a very good one.

Almost every method grew out of one industry's pain:

• The sequential approach (nowadays called waterfall) comes from engineering and construction, where you cannot pour the roof before the walls. A famous 1970 paper by Winston Royce described this sequence of phases for software, and, funny enough, argued that running it as one straight line was risky and needed feedback loops. The name waterfall was attached later, and the straight-line part stuck more than the warning.
• Kanban comes from Toyota's factories. Taiichi Ohno developed the card-based system in the late 1940s and 1950s to make sure each step made only what the next step needed. The word means something like "signboard" in Japanese.
• Scrum was presented to the software world in 1995 by Ken Schwaber and Jeff Sutherland, and it describes short cycles called sprints with a few roles and meetings.
• Agile is an umbrella idea, not a method. In February 2001, seventeen software developers met at a ski lodge in Snowbird, Utah, and wrote the Agile Manifesto: four values and twelve principles about people, working results, collaboration and responding to change. Yes, one of the most famous documents in project work was written about forty minutes from Salt Lake City.
• Lean grew from the Toyota Production System and was popularized in the West around 1990 by a book called The Machine That Changed the World. Its main idea is to remove waste and keep work flowing.
• PRINCE2 was developed for UK government projects (its first version, PRINCE, dates from 1989, and PRINCE2 from 1996) and is organized around a business case, defined roles and stages with checkpoints.

Notice what is happening. Each of these tools was built to fix a specific headache: late surprises, overloaded factories, software nobody wanted, public money without control. The headache you have is the one that should choose the tool.

The six main contenders, in plain English

1. Plan-driven (waterfall): build the house from the drawings

You define the scope, plan the whole project, get approvals and then execute in phases: design, build, test, deliver. Changes go through a formal process, because changing a foundation after the walls are up costs real money.

Where it shines: construction, manufacturing, regulated work, anything with fixed contracts, expensive changes and dependencies on outside parties. If you are building a clinic, you want the electrician to know where the walls are going.

Where it breaks: when you do not really know what you want yet. A plan made on day one with beautiful certainty is a very elegant guess. Another weakness is that problems can hide for months and appear at the end, like a surprise party nobody wanted.

Healthy habit: add checkpoints and demos before the end. Inspect early, as in the quality gates a good construction project uses, and read your schedule with the critical path method, not just a Gantt chart.

2. Agile and Scrum: cook with a spoon in your hand

You work in short cycles, usually one to four weeks. At the end of each one, you show something that works, collect feedback and decide what comes next from a prioritized list. In Scrum there is a product owner who sets priorities, a team that does the work and a facilitator who clears obstacles, plus a few regular meetings.

Where it shines: products and services where customers' needs are discovered by showing them things: software, websites, marketing campaigns, new offers. Anywhere that being wrong in week two is cheap and being wrong in month six is not.

Where it breaks: when the sprints become a treadmill and nobody can say what the whole project will cost or when it will finish. Also when the "product owner" is a committee of seven people who all disagree. Or when a contract says "fixed price, fixed scope, fixed date" and the team insists on discovering the scope as they go. That conversation does not end well.

Healthy habit: keep a clear goal and a budget limit above the sprints, so flexibility lives inside a frame.

3. Kanban: a restaurant with a ticket rail

You draw a board with columns, such as To do, Doing and Done, and every task is a card that moves across. The one rule that makes it magical is a work-in-progress limit: no more than a set number of cards in the Doing column at once. Think of a restaurant kitchen. The tickets hang on the rail, the cooks finish one before grabbing the next, and the head chef does not take new orders when the rail is full.

Where it shines: teams whose work arrives continuously and unpredictably: support, operations, maintenance, small agencies, a consultant's week. It needs almost no training and shows overload immediately. I wrote a full practical guide to kanban for small teams, including a calculator for the limit.

Where it breaks: when it has no limit and becomes a graveyard of sticky notes. Also when work needs a fixed end date and a budget, and nobody is looking at the clock.

Healthy habit: count how many days a card takes from start to finish, and look at the number every week.

4. Lean: wash less water, not more dishes

Lean is less a method than a mindset: look at the flow of work from the customer's point of view and remove whatever does not help. Waiting, rework, handovers that lose information, work nobody asked for, meetings with no decision. The famous list of wastes comes from Toyota, and anyone who has sat through a status meeting that could have been an email knows at least five of them by heart.

Where it shines: repeating processes: onboarding, ordering, delivery, billing, a clinic's patient flow, a restaurant's service. It pairs beautifully with kanban.

Where it breaks: when "cut waste" becomes "cut everything that looks slow", including the review that was stopping the expensive mistake.

5. PRINCE2: a project with a dress code

PRINCE2 (Projects in Controlled Environments) gives you a structure: a business case that must stay valid, defined roles, work split into stages and a decision at the end of each stage on whether to continue. It is common in the UK and in public-sector and large organizational settings in Europe, Australia and elsewhere.

Where it shines: large or publicly funded projects where governance, accountability and an audit trail matter, and where several organizations must share a common language.

Where it breaks: in a five-person company, if you apply every document and every role. The method itself says it should be tailored. The failure is usually the copy-paste of the full ceremony onto a tiny project.

6. Hybrid: half and half, like a pizza with opinions

Hybrid means what it says: use plan-driven control where the work is predictable and short cycles where it is not. A building owner might fix the budget, the permit dates and the contract with a plan-driven frame, then run the fit-out of the dining room in two-week cycles, reviewing mock-ups with the chef. A software company might budget a project in quarters and build in sprints.

Hybrid has a reputation problem, because bad hybrid is the worst of both worlds: the paperwork of waterfall and the uncertainty of agile. Good hybrid starts from a clear rule: the goal and the limits are fixed; the way to reach them can adapt. I explain the thinking behind that in agile, waterfall or hybrid.

Five questions that choose for you

When someone asks me "which method should we use?", I ask five things. Count your yeses and noes, and the answer usually appears without anyone raising their voice.

1. How clear are the requirements today? If you can write the finished result on one page and nobody will disagree, planning ahead pays off. If the honest answer is "we will know it when we see it", you need short cycles that let you see it sooner.

2. How expensive is a change? In concrete, steel and signed contracts, changes are costly, so you decide carefully and early. In a website, a menu or a marketing message, changes are cheap, so you can learn by trying. This is the single most useful question of the five.

3. Who gives feedback, and when? If customers can react to something small every two weeks, iterate. If nobody can react until the finished building opens, you need inspections along the way instead.

4. What does a contract, a lender or a regulator require? If approvals, permits and documents must exist before a phase begins, your frame is plan-driven whether you like it or not. You can still iterate inside the frame.

5. How experienced is the team with this kind of work? A crew that has built twelve identical storage buildings can follow a detailed plan. A new team on a new type of project needs fast feedback and a safe place to be wrong.

Here is a rough rule of thumb. Many yeses to questions two and four push you toward plan-driven. Many yeses to questions one and three push you toward short cycles. A mixture means hybrid. And work that arrives as a stream of requests, rather than as a project with an end, usually wants kanban whatever you answered.

Three small stories (illustrative)

These examples are invented to show how the questions work. They are not real clients.

The bakery that wanted a second location. The owners know exactly what they want: the same shop, a new address, an opening date that matches a lease. Costs are high, the landlord needs permits, and the equipment takes weeks to arrive. They chose a plan-driven frame with a critical path and a weekly review. Inside it, the menu for the new shop was tested in short trial weekends at the old one. Hybrid, without anyone using the word.

The clinic's front desk. Work arrives all day: calls, messages, forms, insurance questions. There is no end date, only a flow. A kanban board with a limit of five cards per person, plus a weekly look at the slowest card, did more than any plan could. They never opened a Gantt chart.

The startup with a mobile app. Nobody knows which feature customers will love. They run two-week cycles, show a working version to ten users at the end of each, and keep a fixed monthly budget so the experiments cannot eat the company. Scrum, with a frame.

The hall of fame of method mistakes

Every method has its characteristic way of going wrong. Here are the greatest hits, in the spirit of affectionate roasting.

• "Scrum-but." "We do Scrum, but we skip the retrospective, the product owner is on vacation, the sprints are six weeks and the requirements are in a 200-page document." Congratulations, you are doing waterfall with extra meetings.
• The kanban graveyard. A board with 94 items "in progress", some since March. A board without a limit is a to-do list with better lighting. Use the work-in-progress calculator and pick a number.
• Waterfall in a clever disguise. A project calls itself agile because it has stand-up meetings, but the scope, the date and the budget were fixed in a contract signed before anyone talked to a user. The meetings are standing, the project is lying down.
• The method shopping spree. The team has changed methods three times this year. Each change comes with new vocabulary, new training and new software, and none was given long enough to show results. Pick one and keep it for ninety days.
• The tool as a method. "We use [fashionable software], so we are agile." A tool is a place to put your habits. If you have no habits, you have a very expensive place to put nothing.
• Ceremony over outcome. The plan is perfect, the board is beautiful, the meeting is on time, and the customer is still waiting. Methods exist to deliver results. If a ritual does not help deliver, question it.
• Copy-paste governance. The five-person project gets the documents designed for a five-hundred-person program. The paperwork now takes longer than the project. If your method is heavier than the work, tailor it down. Lightweight project governance is the polite way to do it.

How to switch without causing a revolt

Changing how a team works is a change project, and it deserves a little project management too.

1. Name the pain. "We are late and surprised" and "we never finish anything" lead to different solutions. Write the pain in one sentence.
2. Change one thing. Not the whole method. Add a work-in-progress limit, or a two-week review, or a checkpoint before each phase.
3. Set a ninety-day trial with two numbers. For example: how long a task takes from start to finish, and how many surprises reached the customer. This is the same logic as the 90-day sprint.
4. Decide who owns the experiment. Someone must be accountable for the rhythm. The RACI chart makes that painless.
5. Review honestly, then keep, change or drop. Pull in the team's view. The people living the method know where it hurts.
6. Write the rules on one page. What we do each week, what the board columns mean, what "done" means. If it does not fit on a page, it is too heavy for a small team.

If your project has a sponsor, bring them into the decision and show them the two numbers. A method nobody sponsors becomes a rumor.

Find your starting point

The tool below is a simple finder. Choose the situation closest to yours, and it shows where I would start, with the guide on this site that goes deeper. It is a starting point, not a verdict: your project is allowed to be a hybrid.

Interactive tool

Find your starting method

Loading the tool…

What to do this week

Write on one page: the project, how clear the requirements are, how costly a change is and who gives feedback. Answer the five questions above and decide whether your frame is plan-driven, short-cycle, stream-based or a mix. Then change one habit, and put a date ninety days from now on the calendar for the honest review. That is the whole job.

If you would like a second pair of eyes on how your team works, choosing the right method and writing it on one page is the kind of work I do through Project Focus and the project consulting service. You can start with the free diagnostic, download a template from the toolkit, browse the guides by topic or just write to me.

What is the method your team uses today, and does it really fit the work? Tell me in the comments, and tell me what your own bar-argument would be.

General information, not professional or legal advice. PMBOK, PMP and PMI are registered marks of the Project Management Institute, Inc. PRINCE2 is a registered trade mark of its owner. This site is independent and is not affiliated with or endorsed by either.

Frequently asked questions

What is the best project management methodology?

There is no single best one. Plan-driven (waterfall) suits projects with clear scope and expensive changes, such as construction. Agile and Scrum suit work where needs are discovered along the way. Kanban suits a steady stream of requests. Most real projects use a hybrid. Choose by asking how clear the requirements are and how costly a change would be.

What is the difference between waterfall and agile?

Waterfall plans the whole project first and delivers in sequential phases, with formal change control. Agile works in short cycles, delivers something usable each time and adjusts the plan from feedback. Waterfall rewards certainty and agile rewards learning. Many teams combine them: a fixed goal and budget with short cycles inside each phase.

Is the PMBOK Guide a methodology?

No. The PMBOK Guide from the Project Management Institute is a reference of concepts, tools and good practices rather than a step-by-step method. You can use its ideas, such as a charter, a risk register or earned value, inside waterfall, agile or hybrid ways of working.

Which method is best for a small business?

Usually a light hybrid: a one-page charter with a goal, a budget and a date, plus a simple kanban board with a work-in-progress limit and a short weekly review. It gives control without heavy paperwork. Try it for ninety days, measure how long tasks take from start to finish and adjust.

Join the conversation

Did this help? A quick reaction tells me what to write next.

Useful Made me smile Go deeper on this

Be the first to react.

Comments

Loading comments…

Leave a comment

NameEmail (required, never shown)

What is the method your team uses today, and does it really fit the work? Post comment

Your name and email create a small profile that shows you are a real person. The email is never shown. The first time, I send you a confirmation link, and every comment is reviewed before it appears. Please keep it respectful and leave links out.