Waterfall vs Agile vs Scrum vs Kanban… which method should you choose?!

We all like having options. Having choices gives us a sense of control over our work and flexibility in our approach. Thankfully for the software development industry, there are plenty of options for project management methods and tools. 

The trick is in knowing which tools are best for which projects and understanding the conditions for making them work. This article breaks it down for you into informed and manageable pieces.

The place to start with the Waterfall, Agile, Scrum, and Kanban discussion is to understand the difference between the two methodologies in the group. They are Waterfall and Agile – two distinct big-picture frameworks. The former is linear, the latter more flexible. Fixed vs nimble.

Scrum and Kanban, on the other hand, are two common approaches to managing projects under the Agile framework. Think of these as the instruments used to deliver on the bigger picture. 

Both Scrum and Kanban are good team collaboration tools and facilitate continuous improvement. But they’re more complementary than they are comparable. Scrum offers a detailed, governing approach to Agile project management, and Kanban is a visualization tool. 

Waterfall Framework

The Waterfall framework came first. It typically begins with project managers being assigned three things: a predetermined solution to a problem, a defined set of outputs, and a deadline for when the outputs must be delivered. 

There is no opportunity for hypothesizing the problem or testing potential solutions first. The goals and outcomes are established before the project begins. The project manager develops a detailed project plan for delivering the solution on time and on budget, which requires significant upfront work and planning.

When illustrated, the Waterfall framework looks like its name. The project is broken down into stages, typically starting with requirements gathering and cascading into system design, implementation, testing, and deployment, followed by maintenance. 

Once the Waterfall cycle begins, it flows step by step, leaving little room for variation, adaptation, or error. Each functional team does its part and hands off to the next. 

There are many benefits to the Waterfall framework, including:

• Clear expectations
• Projects can be planned ahead of time 
• Progress can be tracked between stages 
• Each stage ends in a deliverable, and the project does not move forward until that deliverable has been met 
• Team members can work on multiple projects at once

There are also challenges with the Waterfall framework. For example, the project team has little interaction with the client as the project progresses, nor with end-users, and quality assurance testing happens after the solution has been built. 

This means that the team won’t know until the end of the project whether the solution will actually solve the problem. And therein lies the greatest drawback with the Waterfall framework: What happens if the prescribed requirements were wrong? 

Still, the Waterfall framework remains a viable option for small projects with obvious solutions, defined scopes, and clear outputs. 

Agile Framework

The Agile framework was developed as the antidote to Waterfall’s more rigid structure. In fact, the authors of Embracing Agile say it “revolutionized” the software industry. The Agile process features everything that the Waterfall framework does not, namely a flexible approach, iterative steps, and frequent client engagement. 

The Agile framework starts with the premise that the problem to be addressed is complex, the solutions are not known, and requirements will likely change along the way. It recognizes that the project team will need to collaborate closely with their clients and end users, seeks regular feedback, and adjust their plans as the project progresses. 

Cross-functional teams work together in “sprints,” or short intervals of about two weeks each, to build something tangible to show for the work at the end of each sprint. They meet frequently to review what’s working and what can be improved.

 A key principle of the Agile methodology is to “Build projects around motivated people from different disciplines. Give them the environment and support they need to do the job, and trust them to get the work done.” To that end, teams need support from the top.

The greatest risks with the Agile framework include scope creep and increasing budgets. There are, however, best practices for using the framework under the right conditions, such as starting small and practicing Agile principles at the executive level of an organization. 

This article on Agile vs Waterfall expands on the conditions most conducive to each of these methodologies.

Scrum 

The distinction between Agile vs Scrum is not always clear. Scrum is the most common approach to project management under the Agile framework. It’s a blueprint of values, guidelines, and roles to help teams focus on continuous iteration and ongoing improvements. 

At its core, the Scrum methodology’s intention is to provide self-directed cross-functional teams with a structure that empowers them to organize and prioritize projects, adapting as they need to. This means that it works especially well for projects that don’t have clear requirements and are expected to experience change. 

In Scrum project management, the team comprises distinct roles:

• A product owner, who is responsible for the overall initiative and liaises with the client
• A Scrum master, the go-to person for questions about workflow, priorities, project changes and workload, and
• A cross-functional team that works together throughout the project. 

The Scrum process is characterized by short phases, called sprints. Ahead of each sprint, the project team identifies a small part of the scope to work on in the following two to four weeks. 

The Scrum process is also governed by a set of guidelines:

• Each Scrum runs on sprints
• Each sprint lasts no more than four weeks
• The team has daily standup meetings of about 15 minutes to analyze progress and reassign work as needed
• Each sprint ends with a retrospective to evaluate accomplishments, review lessons learned, reroute any unfinished work and prepare for the next sprint 

Other differences between Scrum and traditional project management are that sprints end with tangible products, rather than delivering only at the end, and the overall process is transparent to everyone involved. 

Kanban

Kanban is another common process under the Agile framework. Like Scrum, it helps teams stay flexible and seek continuous improvement, but that is where their similarities end. 

Kanban is devoid of rules, guidelines, and roles, and has no time restrictions (except for the length of time spent in meetings). It can just as easily be used for ongoing processes as it is for defined projects or stages. 

Its purpose is to display workflows that help teams visualize their progress and impediments. It uses Kanban boards to provide a visual representation of the work. Think of this as post-it notes organized in swimlanes on a whiteboard, but significantly more sophisticated and shareable in ways that whiteboards are not. 

Kanban works well to:

• Provide a visual project management system
• Support visual check-ins for work in progress, keeping all team members in sync
• Help teams improvise to find the ideal fit
• Track ongoing processes and projects just as easily as projects and stages

Wrap-Up

Perhaps the most important thing to remember from a Kanban vs Scrum comparison is to recognize how Kanban can be useful to the Scrum process. Scrum teams can use Kanban boards to plan and visualize their sprints and track any backlogs discovered during Scrum retrospectives. 

As well, in Agile vs Kanban we explain that Agile projects can use Kanban without adopting the Scrum approach. Similarly, Kanban boards can help project managers visualize their progress within a Waterfall framework. 

What the Waterfall, Agile, Scrum, and Kanban comparisons come down to is this: project managers have many tools and approaches at their disposal. Which ones they use will depend on the type of project and requirements, the make-up of their teams, and perhaps the culture of their organizations and leadership. 

---

Continue to explore the rest of Terminal’s content offerings. If you are interested in learning more about how Terminal can support your organization and accomplish your development goals, please get in touch with our team!