This guide explains each one with an everyday analogy, when to use it, when not to, and an honest rule for choosing. Spoiler: if your team is small and non-technical, you probably don't need a methodology with a name at all.
What is a project management methodology?
It's just an agreed set of rules for deciding what gets done first, how work is divided, and how progress gets reviewed. That's it. The problem is the industry wrapped these ideas in certifications, job titles, and rituals, until it seemed like you need a course to organize five tasks. You don't — you need to understand four basic ideas and pick the one that looks like your actual work.
Waterfall: like building a house
In waterfall, the project moves through phases in strict order: plan everything first, then execute, then deliver at the end. It's like building a house: complete blueprints first, then the foundation, then the walls. Nobody puts up walls "to see how it goes" and decides where the bathrooms go later — changing things mid-construction is brutally expensive.
When to use it
When the outcome is clear from day one and there are hard dependencies: construction, events, office moves, anything with legal deadlines. If step 3 can't start before step 2 finishes, waterfall with a schedule or Gantt chart is your best friend.
When NOT to
When the outcome gets discovered along the way: campaigns, digital products, content. Planning six months of detail for something that will change in two weeks just means throwing the plan away — with extra steps.
Agile: like cooking and tasting as you go
Agile is the opposite philosophy: instead of planning everything and executing in one big push, you work in short cycles, show progress, gather feedback, and adjust. It's like cooking a stew: you don't follow the recipe blindly to the end — you taste every so often and correct the seasoning as you go. Agile isn't a tool or a board: it's the decision to deliver in small pieces and course-correct early, instead of discovering at the very end that the client wanted something else.
When to use it
When the client (or you) doesn't know exactly what they want until they see something: design, marketing, software, content. Shipping progress every week or two prevents end-of-project surprises.
When NOT to
When iterating is impossible or ruinously expensive: you can't build "a small version" of a bridge or file a building permit in two-week cycles. There, the plan rules — not the iteration.
Scrum: agile with fixed rituals
Scrum is the most famous — and strictest — flavor of agile. It takes the taste-as-you-cook idea and adds fixed rules: cycles of exact length called sprints (usually two weeks), a daily 15-minute standup meeting, a planning session at the start of each sprint, a demo at the end, and a retrospective. It also defines roles: the scrum master guards the process and the product owner sets priorities. It's that same kitchen, except now there's a daily cooks' huddle, a menu locked in for two weeks, and a formal review of every dish.
When to use it
Software development teams of 5 to 9 people dedicated to one product, where daily coordination earns back its cost. That's where scrum was born, and that's where it works best.
When NOT to
Small or non-technical teams. The rituals (dailies, sprints, retros, roles) eat hours every week; if your team does varied work for multiple clients, the process weighs more than the benefit.
Kanban: the auto shop's whiteboard
Kanban is a board with columns — typically "to do," "in progress," and "done" — where every task is a card moving left to right. Like the whiteboard at an auto repair shop: a car comes in, its work order moves from "received" to "in repair" to "ready for pickup," and anyone glancing at the board knows the status of every car without asking. Its one important rule: limit how much work is "in progress" at once, because ten half-finished tasks are worth less than three finished ones.
When to use it
Work that flows continuously: agencies, support, operations, design — any team where requests arrive all the time. It takes five minutes to learn and adds zero new meetings.
When NOT to
As your only tool on projects with hard deadlines and long dependency chains. The board shows today's flow, but it won't warn you that week 6's step depends on week 2's — for that you need a schedule.
A simple (and honest) rule for choosing
Forget the methodology wars. Choose based on what your work looks like, not on what's trendy:
- Team of 5 at an agency, studio, or consultancy: kanban. One shared board, a work-in-progress limit, done. No sprints.
- Construction, an event, or any project with hard dependencies and a fixed deadline: waterfall with a Gantt chart. The order of the steps is the essence of the project.
- A product or campaign where the outcome emerges through iteration: an agile mindset (short deliveries, frequent feedback) on top of a kanban board. You don't need full scrum to iterate.
- Scrum only if you have a technical team dedicated to a single product. For non-technical teams, the rituals almost always cost more than they return.
And here's the uncomfortable truth most articles skip: most small teams don't need a named methodology at all. They need a kanban board to see today's work, a schedule for committed dates, and someone (or something) doing the follow-up. That's it. Running both views on the same tasks isn't "doing it wrong" — it's exactly what functional teams do.
Follow-through matters more than methodology
Every methodology dies the same death: nobody updates the board or chases the open items. That's why Doku puts AI into the follow-through, not the ceremony: describe your project in your own words — or out loud — and the AI builds the tasks with dates and owners, lets you view them as kanban, list, or Gantt depending on the project, and handles the reminders, follow-ups, and progress summaries. No certifications, no scrum master required.
Less methodology, more progress
Describe your project and Doku builds the kanban board and the schedule for you, with reminders and automatic follow-up. Free, no credit card, and no new jargon to learn.
Organize my project for freeFrequently asked questions
Which project management methodology is best?
There's no single best one — it depends on your type of work. If the outcome is fixed and dependencies are hard, use waterfall with a Gantt chart; if work flows in continuously, use kanban; if the outcome emerges through feedback, use an agile approach. For most small teams, a kanban board plus a simple schedule is enough.
What's the difference between agile and waterfall?
Waterfall plans the entire project upfront and executes it in ordered phases, like building a house from blueprints. Agile works in short cycles with frequent deliveries and adjustments, like cooking and tasting as you go. Waterfall fits when mid-project changes are expensive; agile fits when the outcome is discovered through feedback.
Do I need a scrum master?
Almost certainly not. The role makes sense on software teams dedicated to a single product, where scrum's rituals justify having someone facilitate them. On small or non-technical teams, a project owner who reviews the board weekly is enough — or a tool that does the follow-up automatically.
Can I mix methodologies?
Yes — and real teams do it all the time. Many use a kanban board for daily work and a Gantt schedule for the committed dates of the same project. Methodologies are tools, not religions: take from each one whatever solves a concrete problem for your team.
Which methodology is best for non-technical teams?
Kanban, almost always: it's understood in five minutes, adds no meetings, and makes everyone's work visible. If the project has deadlines and dependencies, pair it with a simple schedule. Scrum rarely pays off outside technical teams, because its rituals weigh more than the benefit.