Agile vs. Waterfall vs. Kanban vs. Scrum
- Waterfall works best for projects completed in a linear fashion and does not allow going back to a prior phase.
- Agile focuses on adaptive, simultaneous workflows. Agile methods break projects into smaller, iterative periods.
- Kanban is primarily concerned with process improvements.
- Scrum is concerned with getting more work done faster.
If you haven't learned in depth about project management methodologies, it can be hard to tell the difference between a Kanban board and a Scrum board or to understand why the differences between Agile vs. Waterfall methodologies are important. And with so many similar terms floating around, it might seem like it doesn't matter which project management method you choose.
Don't miss out on the distinct advantages that these methodologies can offer. Consult the following flowchart to get a quick overview of which project management methodology might be a fit for you and your team, or continue to better understand and compare Agile vs. Waterfall vs. Kanban vs. Scrum.
Agile vs. Waterfall vs. Kanban vs. Scrum
While these methodologies have significant differences, it’s important to acknowledge that each project management methodology ultimately has the same goal: to facilitate the completion of projects. To that end, each methodology helps manage your team’s work processes through structure and communication. Though you would implement each of these methodologies differently, Agile, Waterfall, Kanban, and Scrum all have this much in common.
But even the distinctions between the approaches can sound confusingly similar, especially from a distance. When do you use a Scrum board vs. a Kanban board? Is a burndown chart just another way of talking about a backlog? And where do swimlane diagrams come in? Throw in the project management best practices that apply to each methodology, and it’s easy to see them all as slight variations on a theme.
While the differences between methodologies might seem small, rest assured that they do exist. In fact, these seemingly small details make a big difference in how a method functions. With that in mind, let’s examine what sets each project management methodology apart.
What makes Waterfall unique
In Waterfall project management, projects are broken down into linear and sequential stages, where every piece of the project relies on the completion of preceding deliverables. As such, Waterfall has two unique traits.
Discrete, terminal phases
Waterfall project management originated in construction and manufacturing—industries where one phase must be completed before another begins. You can’t begin roofing, for example, if you haven’t completed framing. This emphasis on linear completion is central to Waterfall’s workflow.
Waterfall uses distinct phases rather than simultaneous work. When you use the Waterfall methodology, you must complete each stage before the next stage can begin. Likewise, you cannot go back to a prior phase. Any revision requires restarting the entire process. So if you're considering Agile vs. Waterfall for your project management style, remember that Waterfall offers less flexibility.
Because Waterfall does not allow going back to a prior phase, project requirements need to be clear up front. This methodology begins with gathering and documenting requirements and then making these requirements accessible to team members.
Team members also document their work as the project continues through each phase. Ideally, team members can exit or enter a project without disrupting workflow, making Waterfall a good solution for teams expecting changes in bandwidth.
Learn what the waterfall project management methodology can (and can’t) do for you.
What makes Agile unique
The Agile methodology—typically used in software development settings—is a collaborative, self-organizing, cross-functional approach to completing work and requirements.
While you might hear it talked about as a distinct methodology, Agile project management more correctly refers to a category of methodologies that includes Scrum and Kanban. Still, there are fundamental differences between Agile and Waterfall project management. Agile focuses on adaptive, simultaneous workflows—a far cry from the linear nature of Waterfall. Each Agile methodology will have the following characteristics.
Simultaneous, incremental work
This is the most distinguishing trait when comparing Waterfall vs. Agile methodology. Agile methods break projects into smaller, iterative periods, which work particularly well for products that benefit from user testing and regular revision (like software).
Because Agile methods work incrementally, teams can adjust their processes with some frequency. Where Waterfall uses a set, inflexible process, Agile methodologies encourage teams to improve and adjust workflow as needed.
The adaptability of Agile is particularly well suited to projects in which you expect requirements or constraints to change. While you should avoid such alterations when possible, Agile methodologies let teams adapt their process to compensate for such changes.
Learn more about the stages of the Agile software development lifecycle.
What makes Kanban unique
While many people want to compare Kanban vs. Agile, Kanban methodology is more accurately a specific type of Agile methodology. Kanban strives to better coordinate and balance work with the capacity and bandwidth among workers. It uses the Agile methodology principles discussed above but implements them in a particular way.
Kanban’s namesake board visualizes the team’s workflow. The board is split into categories of work to be done, work in progress, and completed work, and teams can add more categories as necessary to better visualize their process. Each task is recorded on a Kanban card, which moves from column to column on the board as it moves through the team’s process.
The Kanban board keeps team members on the same page, but it also helps teams identify where processes need improvement. It makes problems like bottlenecks highly visible, allowing the team to make corrections as needed.
The Kanban methodology requires strict limits on the amount of work in progress at any given time. Teams assign a limit to the number of cards in any active-work columns. When the limit is met, no new work can enter the column until a task is completed and moved to the next column. Again, this system helps teams identify bottlenecks, and it encourages individual contributors to rally together to fix them.
The goal of the Kanban methodology is to improve the team’s process. The team meets periodically to discuss changes that need to be made, and the data displayed on the Kanban board guides these discussions.
When held regularly, these meetings help the team continuously correct and adjust their process. This improves workflow without making any sudden or dramatic changes, ensuring easy Kanban implementation on nearly any team.
Learn how Kanban project management methodology can improve your team.
What makes Scrum unique
The final methodology we'll cover, Scrum project management, is another Agile methodology that uses an incremental approach to work in order to complete projects more quickly. Scrum methodology typically tackles complex knowledge work, such as software development. If you're looking at Kanban vs. Scrum, Kanban is primarily concerned with process improvements, while Scrum is concerned with getting more work done faster.
Scrum uses two-week sprints to get work done. These sprints are planned in advance, executed, and then reviewed at the end of the two-week period. During sprint planning, the team creates a sprint backlog. The team completes these backlog tasks during the sprint, managing the work among themselves.
Team members also hold a 15-minute Scrum meeting each day of the sprint. During this time, contributors discuss any potential roadblocks interfering with project success. They also review the previous day’s work and plans for the upcoming day’s tasks. This Scrum meeting ensures the team works collaboratively and stays in sync.
A Scrum master links the team to the product owner. Before beginning a project, the Scrum master works with the product owner to define requirements. They then help the team plan sprints. Once a sprint begins, the Scrum master helps remove any roadblocks that arise.
It’s important to note that a Scrum master is not a traditional project manager, as a Scrum master facilitates work rather than managing it. The Scrum methodology encourages teams to manage their own productivity; the Scrum master merely helps them do so.
Scrum uses a burndown chart during sprints to let team members see progress at a glance. Rather than displaying completed tasks, the burndown chart visualizes what’s left to be done. It should be continuously updated to help team members manage their workflow.
Not sure whether Scrum project management methodology is a good fit for your team?
Which project management methodology should you use?
Unsurprisingly, the answer to this question depends on your unique team and its aims. To help you decide, ask yourself these two questions.
What goals do I have for my team?
While each methodology has the same goal of project completion, their secondary aims make them truly distinct. Your goals can help you decide which methodology is the best fit for you.
Determine what you want most for your team. If you simply want to produce work faster, try Scrum. If you want to improve your production process, use Kanban. If your projects demand a linear workflow, implement Waterfall. If you’re not sure, explore other Agile options and ask yourself the next question.
Which methodology will we actually stick to?
The differences in project management methodologies only matter if you use the methodology consistently. Without WIP limits, for example, Kanban is just another complicated Agile methodology. And if you don’t keep your phases discrete when using Waterfall, then you might as well just use an Agile methodology.
As such, the best project management methodology for your team is the one you’ll execute perfectly. Using piecemeal parts of a methodology will only make you lose out on the benefits that popularized the methodology in the first place. So while you certainly can adapt methodologies for your team’s use, it’s best to use a methodology as intended, adjusting only as necessary.