Over the course of a project, you'll make hundreds of decisions. And one of the first decisions you'll make is choosing which project management methodology to follow. From Agile to Scrum to Waterfall to Kanban, there are a variety of different project management frameworks. Some, like Scrum, follow a more rigid, structured methodology. Others, like Kanban, are easier to introduce and implement on top of existing processes. They all have pros and cons, so how do you know which one to choose? This article will cover the differences between Agile vs Scrum vs Waterfall vs Kanban. We'll talk about the advantages, disadvantages, stages, and when you should use each one.
Agile software development is based on an incremental, iterative approach. Instead of in-depth planning at the beginning of the project, Agile methodologies are open to changing requirements over time and encourages constant feedback from the end users. Cross-functional teams work on iterations of a product over a period of time, and this work is organized into a backlog that is prioritized based on business or customer value. The goal of each iteration is to produce a working product. In Agile methodologies, leadership encourages teamwork, accountability, and face-to-face communication. Business stakeholders and developers must work together to align the product with customer needs and company goals. Agile refers to any process that aligns with the concepts of the Agile Manifesto. In February 2001, 17 software developers met in Utah to discuss lightweight development methods. They published the Manifesto for Agile Software Development, which covered how they found “better ways of developing software by doing it and helping others do it” and included four values and 12 principles. The Agile Manifesto is a dramatic contrast to the traditional text A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and standards.
The Agile Manifesto lists 12 principles to guide teams on how to execute with agility. These are the principles:
Agile evolved from different lightweight software approaches in the 1990s and is a response to some project managers’ dislike of the rigid, linear Waterfall methodology. It focuses on flexibility, continuous improvement, and speed. Here are some of the top advantages of Agile:
While the level of flexibility in Agile is usually a positive, it also comes with some trade-offs. It can be hard to establish a solid delivery date, documentation can be neglected, or the final product can be very different than originally intended. Here are some of the disadvantages of Agile:
Agile is a framework and there are a number of specific methods within the Agile movement. You can think of these as different flavors of Agile:
There are many other practices and frameworks that are related to Agile. They include:
Without in-depth, upfront planning, many project managers are unsure of how to calculate the cost and budget of an Agile project. Estimating the cost before the project even starts can always be challenging, regardless of which project methodology you use. However, in an Agile project, you can tie the amount of time the project will take with its total cost. First, create a burndown chart and use the burndown rate to estimate how many sprints will be in your project and when the project will end. Then, calculate how much the team will cost based on their hourly rates. Multiply each person’s rate by the number of working hours per week, then multiply that by the number of weeks in a sprint. Once you estimate the initial budget for your team, you can add any other costs, like technology, travel, or equipment. You could also break down each user story into tasks. Once you have an idea of how many hours it will take to complete each task, you can estimate the project budget. And lastly, you could use planning poker to estimate the effort required for development goals. Planning poker is a consensus-based, gamified technique for estimating the effort of development goals. Each team member makes estimates by playing numbered cards face-down on the table, instead of saying it out loud. The cards are then revealed and the estimates discussed with the whole team.
Pair programming (also known as “pairing”) is part of the Extreme Programming (XP) practices. It is when two programmers share a single workstation, which includes sharing one screen, keyboard, and mouse. The purpose of this technique is to encourage better communication, clarification of the problem, and understanding of the solution. Pairing is often used in Agile projects to quickly deliver high-quality products, but is it always required? The answer depends on your programmers, company, and goals. For some projects and programmers, pairing might improve productivity. However, it may not always be appropriate for every project. The best thing to do is experiment and see if it works for you.
Agile helps development teams focus on customers’ most important requirements as quickly as possible. With continuous feedback and frequent face-to-face interactions, the project team and stakeholders understand and prioritize the right requirements. Agile teams use backlogs with user stories to manage documents and requirements. Before an iteration begins, the team agrees on which requirements they should meet with the next delivery. This collaborative approach ensures that the most important features get prioritized. And, requirements are continuously updated throughout the project as new information is surfaced.
While Agile was traditionally created for software development, it can also be used in many other projects and industries. It’s important to remember that Agile software development was born from the principles of Lean manufacturing and organizational learning. These ideas weren’t based on software to begin with. And, many practices in Agile, like stand-up meetings and visual management, are so common and can apply to any industry. There are not many case studies of teams using Agile for things outside of software, but there are a couple. For example, Kate Sullivan, a corporate lawyer on The Lonely Planet legal team, has transformed the legal affairs service delivery with Agile. The team uses whiteboards and cards, morning stand-up meetings, prioritization, weekly iterations, and regular retrospectives. Agile can definitely be applied to projects outside of software development, you just have to find the right method and approach for your needs. You can start with boards and cards, a work backlog, stand-up meetings, or iterations (weekly planning meetings) to see how your team responds.
A simple way to get started with Agile is to incorporate daily stand-up meetings into your project. Daily stand-up meetings are easy to incorporate into any other project methodology you may already be using (even Waterfall) and don’t require any training or knowledge transfer. Meet at the same spot every day for about ten minutes and have everyone talk about what they worked on the day before, what they’ll work on today, and any roadblocks. If you want to make the complete switch to Agile all at once, you may want to start with understanding why the team and organization want to make this change. What is and isn’t working? What are they looking to improve? Then, you could conduct an Agile assessment, getting a complete view of the people, skills, and technologies used. Whichever route you choose, remember that Agile is flexible in its very nature. There is no wrong or right way to get started with Agile. Do what works for you and your team. Smartsheet's newest view, Card View, gives Agile teams a more highly-visual way to work, communicate, and collaborate in Smartsheet. Card View enables you to focus attention with rich cards, give perspective with flexible views, and prioritize and adjust work more visually. Display information on cards including custom fields, images, and color coding to better focus your team’s attention. Categorize cards into lanes to organize your work more visually. Learn More About Smartsheet for Software Development
Scrum is a subset of Agile and one of the most popular process frameworks for implementing Agile. It is an iterative software development model used that leverages incremental processes included in a larger framework that use cross-functional teams to meet goals and adapt to changes. Scrum aims to establish small pieces of a release faster in fixed-length iterations, called sprints, that last one to two weeks long. This allows the team to ship software on a regular cadence. At the end of each sprint, stakeholders and team members meet to plan next steps.
This type of project management results in a greater responsiveness to customers, lower costs of development, job satisfaction, and more immediate returns. Scrum is not a linear process, but rather, a fluid practice that takes many moving parts, teams, and goals into consideration as it progresses.
Scrum is a highly prescriptive framework with specific roles and ceremonies. While it can be a lot to learn, these rules have a lot of advantages. The benefits of Scrum include:
While Scrum offers some concrete benefits, it also has some downsides. Scrum requires a high level of experience and commitment from the team and projects can be at risk of scope creep. Here are the disadvantages of Scrum:
There are three specific roles in Scrum. They are:
Working with Scrum often means changing the team’s habits. They need to take more responsibility, increase the quality of the code, and boost speed of delivery. This level of commitment acts as a change agent; as the teams commit to sprint goals, they are more and more motivated to get better and faster to deliver a quality product. A good place to start with Scrum is to talk about the roles. Every project must have a Scrum Master, Product Owner, and Scrum Team. You may want to talk about who should be the Scrum Master and Product Owner, or if these roles are already assigned, you may want to clarify their roles and responsibilities. Depending on how familiar your team is with Scrum, you may also want to look into training sessions. Certified Scrum Coaches and Trainers and Scrum Alliance Registered Education Providers can help your team learn and embrace Scrum. Smartsheet's newest view, Card View, gives Agile teams a more highly-visual way to work, communicate, and collaborate in Smartsheet. Card View enables you to focus attention with rich cards, give perspective with flexible views, and prioritize and adjust work more visually. Display information on cards including custom fields, images, and color coding to better focus your team’s attention. Categorize cards into lanes to organize your work more visually. Use Smartsheet Card View during your next Scrum meeting. Learn More About Smartsheet for Software Development
Waterfall methodology follows a sequential, linear process and is the most popular version of the systems development life cycle (SDLC) for software engineering and IT projects. It is sometimes planned using a Gantt chart, a type of bar chart that shows the start and end dates for each task. Once one of the eight stages are complete, the development team moves onto the next step. The team can’t go back to a previous stage without starting the whole process from the beginning. And, before the team can move to the next stage, requirements may need to be reviewed and approved by the customer. The Waterfall model originated in the manufacturing and construction industries, both highly structured environment where changes can be too expensive or sometimes impossible. The first formal description of Waterfall is attributed to Winston W. Royce in a 1970 article where he described a flawed software model.
Waterfall is best used for simple, unchanging projects. Its linear, rigid nature makes it easy to use and allows for in-depth documentation. The advantages of Waterfall include:
The biggest drawback of Waterfall is how it handles change. Because Waterfall is a linear, sequential model, you can’t bounce between phases, even if unexpected changes occur. Once you’re done with a phase, that’s it. Here’s more information on the disadvantages of Waterfall:
In the traditional Waterfall model, the team goes through each phase for the entire project. For example, they do the analysis for the entire project, then they do the design for the entire project, etc. In an iterative Waterfall model, there is still a lot of upfront planning required. Once the plan is in place, the team follows the same pattern as traditional Waterfall but does it for each story. They do the analysis for one story, then all the design for one story, then all the coding and testing for one story. Then they repeat the process for another story. The work is broken up into chunks that benefit the development team.
Waterfall projects define all software requirements upfront. The project cannot proceed unless these requirements have been identified and documented. Some Waterfall projects may have a dedicated team to capture, collect, and gather these requirements. They may use questionnaires, face-to-face or phone interviews, white boards, and software tools to capture stakeholder and customer requirements. Once the initial requirements are defined, the team should produce a requirements specification document (sometimes they may create more than one). This document defines what needs to be delivered so everyone understands the scope of the project.
Because of its highly structured nature, Waterfall is best used in industries where firm tasks and deadlines need to be set and maintained. For example, manufacturing and construction industries are two highly rigid businesses that rely on the timely completion of dependent stages. Changes to these plans can be expensive, and in some instances, impossible. As a result, Waterfall is leveraged to preserve a sequential process and maintain stability throughout stages of a project.
Kanban is Japanese for “visual sign” or “card.” It is a visual framework used to implement Agile that shows what to produce, when to produce it, and how much to produce. It encourages small, incremental changes to your current system and does not require a certain set up or procedure (meaning, you could overlay Kanban on top of other existing workflows). Kanban was inspired by the Toyota Production System and Lean Manufacturing. In the 1940s, Toyota improved its engineering process by modeling it after how supermarkets stock shelves. Engineer Taiichi Ohno noticed that supermarkets stock just enough product to meet demand, optimizing the flow between the supermarket and customer. Inventory would only be restocked when there was empty space on the shelf (a visual cue). And because inventory matched consumption, the supermarket improved efficiency in inventory management. Toyota brought these same principles to its factory floors. Different teams would create a card (or Kanban) to communicate that they had extra capacity and were ready to pull more materials. Because all requests for parts were pulled from the order, Kanban is sometimes called the “pull system.” These same ideas apply to software teams and IT projects today. In this context, development work-in-progress (WIP) takes the place of inventory, and new work can only be added when there is an “empty space” on the team’s visual Kanban board. Kanban matches the amount of WIP to the team’s capacity, improving flexibility, transparency, and output. According to the Kanban blog, “Kanban is a technique for managing a software development process in a highly efficient way. Kanban underpins Toyota's ‘just-in-time’ (JIT) product system. Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied.” When looking at Kanban vs Agile, it’s important to remember that Kanban is one flavor of Agile. It’s one of many frameworks used to implement Agile software development.
A Kanban board is a tool to implement the Kanban method for projects. Traditionally, this tool has been a physical board, with magnets, plastic chips, or sticky notes on a whiteboard to represent work items. However, in recent years, more and more project management software tools have created online Kanban boards. A Kanban board, whether it is physical or online, is made up of different swim lanes or columns. The simplest boards have three columns: to do, in progress, and done. The columns for a software development project may consist of backlog, ready, coding, testing, approval, and done columns. Kanban cards (like sticky notes) represent the work and each card is placed on the board in the lane that represents the status of that work. These cards communicate status at a glance. You could also use different color cards to represent different details. For example, green cards could represent a feature and orange cards could represent a task.
Kanban’s visual nature offers a unique advantage when implementing Agile. The Kanban board is easy to learn and understand, it improves flow of work, and minimizes cycle time. The advantages of Kanban include:
Many of the disadvantages associated with Kanban come with misuse or mishandling of the Kanban board. An outdated or overcomplicated board can lead to confusion, inaccuracies, or miscommunication. Here’s more on the disadvantages of Kanban:
Every Kanban project should follow these core principles:
Q: How do you organize meetings and maintain focus without a Scrum Master? Someone on the team needs to take initiative to put the meeting on the calendar and ensure the conversation stays on track. Even without a Scrum Master, it normally isn’t too big of an issue. The Kanban board helps maintain focus during the meeting. During the meeting, you can go through the board from left to right and look for stories that have not moved since the last meeting. Instead of talking about accomplishments, you can just look at the cards on the board. The one question you do need to ask during a meeting is about the roadblockers or challenges to getting an item finished. You could also try a kaizen meeting, where you only invite people who are involved in the task at hand. Each person discusses problems and challenges, and how his or her job could be done more efficiently. Then, the whole group talks about solutions to those issues. Kaizen also can include a kaizen facilitator, who encourages the team to openly discuss critical issues.
To some extent, Kanban trades predictability for efficiency. There are no timebox constraints or planning, however once a team has optimized the flow of work and can get a sense of how long certain tasks take, there will be some level of predictability. If management still needs more defined predictability (which is not the Kanban approach), you may need to try managing expectations. In a traditional model, you have a predictable date of delivery, but in reality, no one is going to deliver a product by that date if it’s not complete. Management is always going to wait for the product to be complete, regardless of the original date set. In the Kanban model, the expectations need to be adjusted to focus on delivering the product when it’s ready and complete.
There are a couple different ways you can handle deadlines in a Kanban model. You can simply write the deadlines on the Kanban cards, making sure these deadlines act more as guidelines rather than hard-and-fast due dates (in Kanban, you shouldn’t sacrifice quality for timing). You could also change how you and your team approach deadlines. In Kanban’s truest form, there is no need for them. The Kanban system will make sure that all tasks are completed as soon as possible, so a deadline is no longer necessary.
Yes, Kanban can improve process results, reduce production times, and help manage workflow in almost any industry. For example, in the game development industry, Kanban helps shorten the video process timeline and reduce waste. In real estate, it brings more efficiency by tracking contracts, prospects, and listings on various boards. And in finance, Kanban can quickly identify bottlenecks and increase speed-to-market.
Yes. When setting WIP limits, you need to look at how many people you have on your team and how many tasks you want them to work on at the same time.
There is no formula for setting the right WIP limits. It’s very common for limits to be wrong in the beginning, but you just need to adjust them as the project progresses. A good place to start is 1.5 for available resource, but you should constantly be reevaluating this number and making changes as necessary.
Because Scrum is one way to implement Agile, they both share many similarities. They both focus on delivering software early and often, are iterative processes, and accommodate change. They also encourage transparency and continuous improvement. How Does Scrum Fit with Agile?Scrum is one of many frameworks used to implement an Agile process. Agile is an umbrella term that includes other processes, like Extreme Programming, Kanban, Crystal, and Scrum. Scrum is Agile, but Agile isn’t Scrum.
We recommend using Scrum if:
Scrum works well for projects that have a lot of unknowns or that evolve over time. Scrum deals with these changes very effectively, so you can easily accommodate new information or features throughout the process.
The line between when to use Agile versus when to use Scrum is blurry. Scrum is one framework in the Agile process, so they both have a lot in common. A good place to start is to first understand if you should use Agile in general. Then, if an Agile methodology seems like it would work for you, you could choose which framework of Agile to use (Scrum being one framework). We recommend using Agile if:
If a pure Scrum approach doesn’t work for your project, you can also try a hybrid model. There are several methodologies that combine the principles of Agile or Scrum and adapt the framework to scale more effectively. For example, Disciplined Agile Delivery (DAD) builds on the practices of Agile, Scrum, and Lean to provide a solid foundation from which to scale. DAD was developed to provide a more cohesive approach to Agile, taking strategies from Scrum, Kanban, Extreme Programming, and others. Rather than taking the time to learn one of these existing frameworks and cobble them together as needed, DAD already combines all relevant techniques. Other hybrid methods include Large-Scale Scrum (LeSS), which extends Scrum with scaling rules and guidelines, and Scaled Agile Framework (SaFE), based on underlying Lean and Agile principles.
Kanban and Scrum are both frameworks for Agile software development. They both take large, complex tasks and break them down into smaller chunks. Kanban and Scrum also work toward continual improvement and optimization of the process, and want to keep work highly visible. While both Kanban and Scrum are very adaptive, Scrum is more rigid than Kanban. Scrum has more constraints, whereas Kanban is more flexible.
While a Scrum board and Kanban board can look similar visually, they are based on very different principles. To create a Scrum board, the Scrum team must first create sprints, assign points to user stories, and plan which stories go into which sprint. Then, the Scrum board visualizes the sprint, showing which stories are in plan mode or work mode. The Scrum board is reset between each sprint and is owned by one specific team. Make your Scrum board digitally or physically, whichever works best for your team. A Kanban board has the same column-based layout as a Scrum board, but it requires no upfront planning. You can start working and moving through the flow of the Kanban board without having a structured plan. The Kanban board can be shared by multiple people and is persistent; you don’t need to reset the board. And, unlike the Scrum board, the Kanban board has a maximum number of stories allowed in each column at one time. This will continue to flow as long as the project continues, with new stories added and completed stories being reevaluated if needed.
We recommend using Kanban if:
Scrum can be less flexible than Kanban. The timing revolves around sprints, with each sprint lasting two to four weeks. In each sprint, the team has specific roles and follows specific ceremonies.
Scrumban combines the principles of Scrum and Kanban into a pull-based system. The team plans out the work that was established during initiation and continually grooms the backlog. The same Scrum meetings should take place, but the frequency can change depending on context and need. The most important part of Scrumban is making sure that work in progress limits (WIP limits) are followed. Scrumban takes bits and pieces from both Scrum and Kanban. For example, it includes the defined roles, daily Scrum, and other meetings from Scrum. And from Kanban, it takes the Kanban board, continuous flow, and ability to add changes as needed to the board. Scrumban can look more like Scrum on the technical level, but at the cultural level, it will more closely resemble Kanban. Instead of big changes all at once, Scrumban encourages incremental changes. If your team is looking to migrate from Scrum to Kanban, Scrumban can provide a gentle transition.
When comparing Kanban versus Scrum, there is no definitive winner. The best framework depends on your project, team, and your goals. Because both Kanban and Scrum are flexible Agile methodologies, you could easily take principles from each and apply them as you see necessary. It’s important to remember that true Scrum is a much bigger shift than Kanban. The team will have to learn about the ceremonies, the specific roles, and iterations. On the other hand, Kanban encourages incremental improvements. You can apply Kanban principles to any process you already have in place, even Scrum. Nothing needs to change significantly to get started with Kanban. As a general rule of thumb, if your team or organization is really stuck and needs a big change, Scrum may be more appropriate. If you already have a process in place that you’re happy with, but want to implement some small changes, Kanban might be a better choice.
There are not many similarities between Agile and Waterfall; Agile was specifically created to be the opposite of Waterfall. However, you can say that both Agile and Waterfall have the same goal. They both want to deliver quality products in an efficient way. If you have any other similarities between Agile and Waterfall to share, please leave us a comment!
We recommend using Waterfall if:
When deciding between Agile versus Waterfall, it can all boil down to this: if you anticipate or expect any changes throughout the project, go with Agile. If you know the project is fixed, unchanging, and predictable, Waterfall may be a better choice.
Agile and Waterfall are such opposites that it’s hard to say which one is better. It really depends on the project, the level of clarity around requirements, and how flexible you can be. If you have a clear picture of what the final product should be, you have fixed requirements that won’t change, and you’re working on a relatively simple project, some argue that Waterfall is a better choice than Agile. If you don’t expect to deal with change, Waterfall is a straightforward, efficient process. The issues with Waterfall come when you have to accommodate changes. If you don’t have a clear picture of the final product, you anticipate changes, and you’re working on a complex project, Agile is superior. Agile is designed to accommodate new, evolving requirements any time during the project, whereas Waterfall does not allow you to go back to a completed phase and make changes.
If you’re still wondering about Waterfall versus Agile, you could always combine principles of both and use a hybrid model. Agifall, for example, increases speed and quality by adding Agile methodologies to the Waterfall process. In an Agifall project, you would break out the research, strategy, and planning phases into tasks and proceed with sprints to complete them. The development phase would be just like any other Agile project, with more information up front. You also don’t need to wait for one phase to end to start the following phase, which is traditional in pure Waterfall. With Agifall, when the project can begin, it should begin. Wagile has a more negative connotation than Agifall. The definition of Wagile on Wikipedia is, “a group of software development methodologies that result from slipping from Agile back into Waterfall, doing a lot of short Waterfalls and thinking it is Agile, Waterfall model masquerading as Agile software development.” Wagile adopts Agile practices like short iterations, daily stand-ups, or continuous integration on top of the Waterfall model, without really changing the traditional Waterfall model.
We recommend using Kanban if:
Like with any project management methodology, there isn’t one framework that is better 100% of the time. You may choose Kanban for some projects, but want to implement Agile for others. Consider what level of change you want to introduce to your team. If you want to add something on top of an existing framework with small, incremental changes, Kanban is a better choice. If you’re looking to make a bigger process change, implementing Agile (like Scrum) would be better. And, if you want your project team to get started right away with a new method, Kanban is easier to understand. There is no training required and it can be used on top of any existing process. On the other hand, some Agile methods require more knowledge from the team. For example, they may need to learn specific roles, ceremonies, and terminology.
Download a free Excel waterfall chart template or learn how to create a waterfall chart from scratch. We'll also share when to use a waterfall chart and the features of a waterfall chart in Excel. Find eight Agile project management templates in Excel, ranging from Agile product backlog template to Agile project charter template. You'll also learn how to use Agile templates in Smartsheet Courses:
Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change. The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed. When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.
How to Create a Waterfall Chart in Excel Download a free Excel waterfall chart template or learn how to create a waterfall chart from scratch. We'll also share when to use a waterfall chart and the features of a waterfall chart in Excel. Best Agile Project Management Excel Templates Find eight Agile project management templates in Excel, ranging from Agile product backlog template to Agile project charter template. You'll also learn how to use Agile templates in Smartsheet Agile Planning: Best Practices for Project Managers Agile One-Stop Project Management Resource Courses:
Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change. The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed. When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.
Try Smartsheet for Free Get a Free Smartsheet Demo |