Waterfall. Agile. Kanban. Scrum. What do these words have to do with project management, what are the differences, and how can you pick the methodology that’s right for your team?
If you’re unsure about the meaning of any of these terms, we’ve got you covered. In this article, we dive into what each of them mean, what the benefits and disadvantages are, and how they compare.
Use the jump-to links on the left to navigate to a particular headline if you’re here to get the answer to a specific question. Or stick around for the ultimate guide to answer all the questions you have regarding waterfall, Agile, Kanban, and Scrum.
The waterfall model divides each project into different phases and moves through the phases in sequential order. No phase can begin until the phase before it is completed. Typically, each phase ends in a project milestone that indicates the next phase can begin.
The specific phases of the waterfall process depend on exactly what your team is creating, but typically they look similar to this:
Requirements phase, sometimes split into an additional analysis phase
System design phase
Implementation phase, also known as the development phase or coding phase—depending on the type of project
Deployment phase, also known as the operations phase
The waterfall method got its name from the way it looks when you draw the process out. Similarly to a natural waterfall, projects look like they’re cascading from one project phase to the next.
Implementing this project management methodology requires a lot of up-front planning and preparation. A big part of waterfall project management is creating an airtight project plan so your team clearly understands the project requirements and restraints before they get started on the work. That’s because there isn't a lot of room for variation, adaptability, or error once a waterfall project is set in motion.
With careful planning, you can successfully achieve your end product with clear, predictable workflows. This project methodology is great for time management and progress tracking, though it’s less flexible than other models, such as Agile.
Agile project management is an iterative methodology where work is completed in short sprints. By prioritizing a flexible approach and continuous delivery, the Agile method is more flexible when it comes to unexpected project changes—however, it can suffer from scope creep as a result.
The Agile methodology was developed to counter traditional waterfall-style project management. As software development became more prevalent in the early 2000s, developers needed an iterative approach to prototyping and project management—and thus Agile software development was born.
Since then, the Agile Manifesto has been the go-to resource for Agile values and principles for anyone who’s looking to implement this methodology. The Agile methodology is no longer exclusive to software development. Among others, marketing, IT, event planning, and product development have adapted and modified the methodology to fit their industries.Asana로 애자일 팀 관리하기
Agile project management includes iterative backlog management, sprints, reflection, iteration, and more sprints. Each Agile sprint typically lasts two to four weeks.
Each sprint goes through the following phases:
First, the product owner organizes the product backlog. The product backlog is a list of every task that may be worked on during the sprint. This information is usually stored in a project management tool.
Before the sprint, the entire project team participates in sprint planning to identify the best tasks to work on during the two-week period.
During the sprint, Agile teams meet frequently to discuss blockers and action items.
Once the sprint is over, team members get together to run a sprint retrospective and identify what went well and what could have been better.
Kanban is a subsect of the Agile methodology and functions within the broader Agile mentality. The Agile philosophy is all about adaptive planning, early delivery, and continuous improvement—all of which Kanban can support.
When someone speaks of Kanban in project management, they’re most commonly referring to Kanban boards. A Kanban board represents stages of work with columns that hold the individual tasks for each stage—but more on that in a little bit.
The Kanban framework is very flexible and can help your team become more dynamic and agile over time.Free Kanban board template
The Kanban framework was developed by Taiichi Ohno in the 1940s and has been digitized, adapted, and refined over several decades. At its core, the modern Kanban framework is an online, visual method to manage work.
When people say “Kanban,” they are frequently referring to Kanban boards: the visual project management view that brings the Kanban methodology to life.
In a Kanban board, columns represent the various stages of work. Within each column, visual cards represent individual tasks and which stage they’re in. Typically these stages are ‘to do,’ ‘in progress,’ and ‘done.’
Kanban boards are one of the most popular forms of visual project management. They’re most effective for providing easy, at-a-glance insight into a project.참고: 프로젝트 계획을 시각화하는 3가지 방법: 타임라인, 캘린더, 보드
When you use a Kanban board for visual project management, you provide your team with a wealth of at-a-glance information, including but not limited to:
Tasks or deliverables
Relevant tags, like priority or task type
Kanban boards are a flexible way for your team to visualize work in progress. Traditionally, Kanban board columns display the stages of work, which is why they’re popular visual project management tools for teams that run ongoing processes and projects like creative requests or bug tracking projects.
You can also customize your Kanban board columns based on task assignees, add a “swimlane,” or create columns by due dates.
Because of how effective they can be for visualizing work, Kanban boards are a key component of most project management tools. If you’re looking to choose the right project management tool for your team, make sure it offers Kanban as a view. Better yet, look for a tool that allows you to view work in multiple ways. For example, in Asana, Boards View (or Kanban) is one of four ways you can view work, in addition to Timeline View, Calendar View, and List View.참고: Asana에서 업무를 시각화하는 4가지 방법 (1)
Scrum is one of the most popular Agile frameworks. Unlike Kanban, which is generally used as a tool to visualize work, Scrum is a full framework and you can “run teams” on Scrum. The framework was pioneered by Taiichi Ohno and provides a blueprint of values, guidelines, and roles to help your team focus on continuous improvement and iteration.
It’s much less flexible than Kanban but a great way for Agile teams to collaborate and get high-impact work done.Asana로 애자일 팀 관리하기
While Scrum, like Agile, was originally created for software development teams, industries like product, engineering, and others now run Scrum to execute their work faster and more effectively.
To run a Scrum, teams typically assign a Scrum master, who is in charge of running the three distinct Scrum phases and keeping everyone on track. The Scrum master can be your team lead, project manager, product owner, or the person most interested in running Scrum.
The Scrum master is responsible for implementing the three traditional Scrum phases:
Phase 1: Sprint planning. A Scrum sprint is usually two weeks long, though teams can run faster or shorter sprints. During the sprint planning phase, the Scrum master and team take a look at the team’s product backlog and select work to accomplish during the sprint.
Phase 2: Daily Scrum standups. Over the course of the Scrum (also known as the Scrum “cycle time”), teams traditionally meet for 15 minutes every day to check in on progress and make sure the amount of assigned work is appropriate.
Phase 3: Sprint retrospective. When the Scrum is over, the Scrum master hosts a sprint retrospective meeting to evaluate what work was done, route any unfinished work back into the backlog, and prepare for the next sprint.
The goal of Scrum isn’t to build something in two weeks, ship it, and never see it again. Rather, Scrum embraces a mindset of “continuous improvement,” where teams take small steps towards bigger goals. By breaking work into smaller chunks and working on those chunks, Scrum helps teams better prioritize and ship work more efficiently.
Teams that run Scrum have clearly established rules, rituals, and responsibilities. Additionally, your daily Scrum meetings, combined with sprint planning and sprint review (or “retrospective” meetings), help teams continuously check in and improve on current processes.
Because it draws from a backlog of work, and begins with a sprint planning meeting, Scrum offers an easy, built-in structure for team leads or product owners to manage and support their team’s most important work. During a Scrum, your team has a pre-set and limited amount of work and time for each sprint. This level of built-in prioritization is combined with clearly defined responsibilities ensuring that everyone knows what they’re responsible for at all times.
We’ve covered the ins and outs of the individual methodologies and frameworks. Now, let’s take a moment and compare them with one another to find out which one you should implement to help your team reach its goals.
Considering the benefits and disadvantages of each methodology will likely make it easier for you to pick the one that’s best for your team. Let’s take a look, shall we?
Waterfall project management is more effective for cross-functional projects. Some of the biggest advantages of the waterfall methodology are that you can…
Plan projects ahead of time to prevent scope creep.
Track progress easily between different phases of the project.
Work on multiple projects without being completely dedicated to one initiative.
Manage dependencies with ease.
However, the waterfall methodology also comes with a few disadvantages that are important to note:
Can lead to increased project risk due to lack of flexibility.
Can lead to loss of information if different people work on the project during different phases and don’t document clearly.
Can lead to unexpected bugs when QAs happen late.
Can cause decreased customer satisfaction without their involvement.
The Agile methodology is popular for a reason—here are some of the biggest advantages for Agile teams. They…
Adapt quickly to unexpected changes
Focus on customer satisfaction
Experience high intrinsic motivation by emphasizing teamwork and team member involvement
With all of that flexibility come a few disadvantages Agile teams have to face:
Can increase scope creep and project budget unexpectedly
Can be difficult to engage with customers if they don’t have the time or bandwidth
Focusing exclusively on the Agile sprint process doesn’t allow team members to work on other initiatives
Can be difficult for virtual teams to thrive in Agile environments
While most teams can benefit in some way from either waterfall or Agile, here’s an easy breakdown to help you decide which methodology is best for you:
Use the waterfall methodology if…
You’re working on a sequential project and no phase can begin unless the other is complete.
You want to tightly control scope creep.
You value clear, effective planning.
You want to understand the entire development lifecycle before beginning the project.
You value functionality over quick delivery.
Try the Agile approach when…
You want to use a more iterative process.
You want to deliver results quickly—even if that means improving them later on.
Your team moves quickly.
Your team values adaptability over predictability.
Your customers want to be active stakeholders.
If you’re sold on the Agile methodology, your next step will likely be to consider whether or not Scrum is the right way to run your team.
When it comes to the Agile methodology and Scrum, it’s not a question of which one to pick but more one of whether or not you want to make Scrum your Agile framework of choice.
Absolutely! Scrum may be the most common Agile framework but you can still be Agile without adhering to the rules of Scrum. If you’re looking for a methodology that allows your team to be more collaborative and flexible but don’t think the rules of Scrum will benefit your team, there are other frameworks you can consider—like Kanban, which we’ll get to in a little bit.
Agile can also stand by itself—however, without a Scrum master, daily standups, and bi-weekly sprints, there are a few best practices you should keep in mind to allow for a smooth workflow:
Keep projects small. Without Scrum rules, it's going to be much easier to manage a small project with a small team that works toward a small goal.
Assign a product owner. Without a Scrum master, you’ll want to assign a team member who is looking after project requirements and resource needs. This teammate will be the go-to person for questions regarding workflow, project changes, and resource allocation.
Have regular meetings. With a small team and a small overarching project goal, weekly meetings should set you up for success. Take the opportunity to review the project progress and discuss everyone’s goals for the upcoming week to keep morale high and your team engaged.
Schedule frequent reviews. Just like you meet up to discuss weekly goals, your Agile team will also benefit from regular quality reviews. These reviews can uncover details of the project that need more attention and ensure that the overall quality of your project is high.
Now, let’s take a look at another Agile framework, Kanban, and how it compares to Scrum.
Kanban and Scrum are the two most commonly referred to Agile methodologies. Both Kanban and Scrum encourage teams to embrace continuous improvement.
One of the core tenets of Agile methodology is flexibility and continuous improvement—in fact, it’s one of the reasons product, engineering, and software development teams are so drawn to Agile philosophies. Continuous improvement is a big part of both Kanban and Scrum.
Kanban and Scrum are both great team collaboration tools. Even though collaboration might look different depending on the framework your team chooses, both Kanban and Scrum are, fundamentally, a way for teams to work better together.
While the two have some things in common, there are a few major differences between Scrum and Kanban. Let’s take a look!
Scrum is more defined than Kanban. Scrum includes a specific set of “rules” for teams to follow. Kanban is most frequently used to visualize work. Many teams actually run Scrum on a Kanban board—but in those cases, they’re still running Scrum, not Kanban. Think of Kanban less as a “methodology” with a set of rules and more as a way to visualize work.
Scrum is time-bound, Kanban is flexible. Scrum runs on sprints, which are typically two-week work cycles. At the end of a sprint, you have a collection of finished work—no matter what that work is. Kanban boards don’t necessarily have to have a beginning or end date. In fact, at Asana, we often use Kanban boards to represent ongoing processes.
Kanban board columns can be organized in different ways. When you’re running a Scrum, it’s important to track work as it moves through stages. But within a non-Scrum-based Kanban board, board columns can represent a variety of work, not just work status. Columns could represent the work that will be accomplished each month, a retrospective that captures the work that was previously accomplished, or whatever else you need them to be—unlike Scrum, which has more defined “rules.”
There’s no exact rule for when your team should use Kanban, Scrum, or another form of visual project management. However, a good way to decide if Kanban is right for you is if:
Your team needs a visual project management system.
You want an at-a-glance way to understand where a project stands.
You’re not on an engineering, product, or software development team.
You run ongoing processes and projects.
Most of your work isn’t produced in short periods of time.
Even if you choose not to run a Scrum framework, you can still pull inspiration from it. For example, maybe you don’t want your work to be limited to two-week sprints—but keeping a backlog of work would be helpful for your team to better understand and prioritize tasks. The best part of Kanban is that you can pull what works for you and discard the rest.
Scrum can be a powerful way to organize and prioritize your entire process. Though not every team thrives on Scrum, you might benefit from Scrum if:
You’re on an engineering, product, software development, or Agile-based team.
You think your team could benefit from a slightly more rigid structure.
You have a large backlog of work to get through.
Your team is motivated by quick deadlines and deliverables.
Someone on your team is committed to being the Scrum master.
Remember: you can always combine the two by running Scrum on a Kanban board.
In order to host effective daily standup meetings, stellar sprint planning, and retrospectives, you need a strong way to visualize work through stages and track all of your work in progress. Kanban boards can help you tackle your sprint backlog and organize the flow of work during a sprint, so every Scrum cycle is a success.
Teams that run Scrum on Kanban boards (or, as they’re sometimes called, Scrum boards), frequently create a new board for every Scrum sprint. The reason for this is twofold:
Teams that create new boards for every sprint can start with a clean slate. This makes it easier for the Scrum master and Scrum team to visualize the new work they have to do for each sprint.
Scrum masters use past Scrum boards to track what work was accomplished during each Scrum cycle. Since a big reason teams implement Scrum is process improvement and efficiency, it can be helpful to look back and see what you’ve accomplished.
As you can see, it all comes down to finding a combination of methodologies, frameworks, and tools that work for your team and project.Create a Scrumban template
Whether you’re implementing a waterfall or Agile approach, decide to run your teams on Scrum, or use Kanban boards, make sure you’re tracking your work in a central tool.
When team members have clear insight into who’s doing what by when, they can more accurately plan their own work and hit their deliverables.업무 관리에 Asana 사용해 보기