Project Management Methodologies Compared: Agile, Scrum, Kanban, Waterfall

A project management methodology is an agreed way of deciding what to work on, in what order, and how you will know it is done. The ones you will meet most are Waterfall, which plans everything first and runs in phases; Agile, a set of values for delivering in small pieces; Scrum and Kanban, the two most common ways of practicing Agile; and Lean and XP, which contribute ideas about waste and engineering discipline. The short version for choosing: fixed scope and a fixed order of work point to Waterfall; a product you learn about by building points to Scrum; a steady stream of unplanned work points to Kanban. Most small teams end up with a light mix, and that is fine as long as the mix is chosen rather than drifted into.

Methodology, framework or method: does it matter?

Not much, but the words cause confusion. Agile is a philosophy, not a process: it tells you what to value and leaves the how to you. Scrum calls itself a framework. Kanban calls itself a strategy. Waterfall is a lifecycle model. Lean is a way of thinking that started in manufacturing. People lump them all together as “methodologies,” and this post does too, but the difference explains why “Agile vs Scrum” is not a fair fight: Scrum is one way of being Agile.

The methodologies in one table

Method     Core idea                     Roles & events          Best fit
Waterfall  Plan all, then run phases     PM, phase sign-offs     Known scope, fixed order
Agile      Values: deliver small, adapt  None prescribed         Umbrella for the below
Scrum      Fixed Sprints, Sprint Goal    PO, SM, Developers;     Product work you can
                                         5 events                plan 2-4 weeks ahead
Kanban     Visualize flow, limit WIP     None required           Unplanned, continuous
                                                                 work: support, fixes
Scrumban   Sprints plus WIP limits       Borrowed from Scrum     Scrum teams with lots
                                                                 of interrupts
Lean       Deliver value, cut waste      None prescribed         Improving any process
XP         Engineering practices:        Whole team, customer    Software teams that
           tests first, pairing, CI      on hand                 need quality habits

Waterfall

Waterfall runs a project as a sequence: requirements, design, build, test, deploy. Each phase is finished and approved before the next begins, and changes after approval go through a change request. It fits projects where the requirements are stable and the order is physical, such as construction, hardware, events and fixed-price contracts. It struggles when the people asking for the work do not yet know what they need, because it shows them results only at the end. Agile vs waterfall covers the choice between the two in detail, including the hybrids most organizations use.

Agile

Agile is the umbrella. The Manifesto for Agile Software Development↗ (opens in a new tab) sets out four values, among them working software over comprehensive documentation and responding to change over following a plan, and twelve principles such as delivering working software every few weeks. It prescribes no roles, meetings or tools. When someone asks “what is agile project management methodologies,” the honest answer is that Agile is the goal and Scrum, Kanban and XP are the common ways of reaching it.

Scrum

The Scrum Guide↗ (opens in a new tab) defines a small team with three accountabilities, a Product Owner, a Scrum Master and Developers, working in Sprints of one month or less. Each Sprint has a Sprint Goal and four events inside it: Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. It fits product teams that can plan a few weeks ahead and benefit from a regular review with the people who asked for the work. It fits poorly when most work is unplanned, because the Sprint plan is torn up every week.

Kanban

The Kanban Guide↗ (opens in a new tab) defines Kanban as a strategy for optimizing the flow of value through a process, built on three practices: defining and visualizing a workflow, actively managing the items in it, and improving it. It requires no roles or events, but it does require that the team explicitly controls work in progress and tracks four measures: work in progress, throughput, work item age and cycle time. It fits support, operations, bug fixing and any work that arrives unpredictably. Kanban vs Scrum compares the two side by side, and cycle time vs lead time explains the measures.

Scrumban

Scrumban keeps Scrum’s iterations and adds Kanban’s pull system and work-in-progress limits. It is common in teams that started with Scrum and found that interruptions kept breaking their Sprints. What is Scrumban covers it fully.

Lean

Lean came from manufacturing, and the Lean Enterprise Institute describes it as a way of thinking about creating needed value with fewer resources and less waste↗ (opens in a new tab). It is less a project method than a lens: look at the work from the customer’s point of view, find the steps that add nothing, and remove them. Kanban grew out of Lean ideas, which is why the two share their emphasis on flow. On a small team, Lean usually shows up as a habit of asking “does anyone actually use this?” before building it.

XP (Extreme Programming)

The Agile Alliance describes Extreme Programming↗ (opens in a new tab) as an agile framework that aims to produce higher quality software and a higher quality of life for the team. Its practices are mostly about engineering: test-first programming, pair programming, continuous integration, small releases, and a weekly cycle where the team picks the stories to finish. Many teams that say they “do Scrum” quietly run on XP’s engineering practices, because Scrum itself says nothing about how to write code.

When each methodology fits

• Requirements are fixed, the order is physical, and the contract names deliverables: Waterfall, with a Gantt chart for the dependencies. Gantt chart vs Kanban shows where each picture helps.
• You are building a product, stakeholders want to see progress on a rhythm, and you can plan two to four weeks ahead: Scrum.
• Work arrives continuously and its order changes daily: Kanban.
• You run Scrum but interrupts keep wrecking the Sprint: Scrumban.
• The team ships, but quality keeps slipping: add XP’s practices to whatever you already run.
• The process has grown steps nobody can explain: apply Lean to it before switching methods.

Mixing methodologies without making a mess

Almost every real team mixes. A product team runs Scrum for features and a Kanban lane for production bugs. An agency plans each client engagement Waterfall-style for the contract, then delivers it on a board. A startup ignores all of it for a year, then adopts a daily standup and a weekly review and calls it Agile. None of that is wrong. What goes wrong is mixing by accident: keeping every meeting from Scrum, every column from Kanban and every document from Waterfall, until the process is heavier than any single method would have been.

1. Start from the problem. Missed dates, too much in progress, poor quality and unclear priorities each point to a different practice.
2. Borrow one practice at a time: a WIP limit, a review every two weeks, a Definition of Done, a written plan per task.
3. Keep it for a month before judging it.
4. Drop anything nobody would miss. Every meeting and every field should earn its place.
5. Write the result down in a paragraph, so a new team member, or an AI assistant, can follow it.

What small teams actually use

Teams of two to eight people rarely need a full framework. What tends to stick is a board with a prioritized queue, a short weekly review, a one-page plan with a few dated milestones, and one or two engineering habits such as code review and automated tests. That is Kanban plus a little Scrum cadence plus a little XP, and most people would just call it “how we work.” A simple project management tool for small teams goes through the setup, and project management for startups covers how much process an early company needs.

Where fenbs fits

fenbs is built for the Kanban end of this table. A board has four fixed lanes, To Do, Next Up, In Progress and Completed, and tasks are features, enhancements or bugs with a priority from 1 to 10. There are no sprints, due dates, story points or WIP limit settings; a Scrum team can still treat Next Up as its current Sprint, and a limit can be written as a rule. That rule has a home: the Decisions and rules page records what the team decided, the decider is always a person, and every AI assistant connected over MCP reads the rules first. AI context holds the notes every assistant reads, so “we review work every Friday” or “no more than three tasks in progress” reaches people and assistants alike.