Scrum vs. Waterfall: What's the difference?

Difference between Scrum and Waterfall

The key difference between Waterfall vs. Scrum is that Scrum is a lightweight, Agile development framework, while Waterfall is a rigid structured process that divides the development lifecycle into discrete, isolated phases.

A process, methodology or framework such as Scrum is said to be Agile if it embraces the four key values and the 12 fundamental principles outlined in the 2001 Agile Manifesto. This includes the following beliefs:

• Individuals and interactions take precedence over processes and tools.
• Working software is more important than comprehensive documentation.
• Customer collaboration should be prioritized over contract negotiation.
• Responding to change is more beneficial than always following a plan.

Agile vs. Scrum

Scrum was developed by Ken Schwaber and Jeff Sutherland, two of the co-signers of the Agile Manifesto. It embraces those Agile ideals in the following ways:

• Never plan more than a month ahead.
• Deliver usable, working features to clients every 2-4 weeks.
• Encourage stakeholder feedback throughout the development process.
• Provide daily opportunities for developers to adjust their short-term plans.

Interestingly, however, the word Agile is not mentioned anywhere in the official Scrum Guide.

Agile responds to Waterfall

Frameworks that embody Agile, such as Scrum and Extreme Programming (XP), exist because programming teams originally encountered difficulty when they applied traditional, Waterfall-based development process to software.

Waterfall, which has its roots in construction, industry and manufacturing, demands that organizations break down product development into isolated and distinct phases that do not overlap. Instead, these phases flow down unidirectionally into each other, just like a waterfall.

A traditional Waterfall model includes the following phases of development:

• Requirements gathering.
• Analysis and design.
• The building or implementation phase.
• Testing and validation.
• Deployment and delivery.
• Ongoing maintenance.

Waterfall: Upfront planning vs. incremental results

Waterfall models typically include a lot of upfront planning, documentation and customer negotiations to precisely clarify specifications.

Waterfall works great in manufacturing and construction operations that benefit from a great deal of upfront planning. Additionally, Waterfall is arguably necessary when changed decisions from a prior development phase could have disastrous consequences for the current lifecycle phase.

Waterfall example

For example, if you're building a home, you don't want the customer to hand over new diagrams for a six-bedroom mansion after you've poured the foundation for a small, two-bedroom bungalow.

Scrum: Regular intervals of usable results

In contrast to Waterfall, Scrum emerged from the software world, where app developers require a more flexible model than those used in construction and manufacturing.

Scrum rejects the idea that a software product can be thoroughly planned and documented before the development phase begins.

In fact, Scrum encourages teams to get started with product development even if the product vision isn't completely clear, and thus avoid planning paralysis.

Instead, Scrum encourages teams to begin development right away, and put some form of usable, valuable software in the hands of stakeholders no longer than a month after development begins. The belief is that as stakeholders get software in their hands quickly and at regular intervals, the requirements will change as the stakeholders' wants and needs become clearer.

Scrum is designed to allow teams to adapt quickly as conditions change and requirements evolve.

Scrum example

In Scrum, the team continually delivers product increments to the customer to inspect and critique, and the Scrum team quickly accommodates that feedback. For example, a mobile app project designs the login button placed at the top of the screen, but the stakeholder finds it awkward to use. With Scrum, the Agile team can quickly adapt and make the requested changes in the next Sprint.

When to use Scrum over Waterfall

A current trend in the software development industry is to move away from Waterfall models and into Agile frameworks like Scrum, feature-driven development and Kanban. Scrum works well with the following examples:

• Small, highly motivated teams of developers who can self-manage.
• Complex projects where requirements are likely to change regularly.
• Details and requirements that evolve and change over time.
• The product owner has a vision, but isn't precisely sure of all low-level details.
• Stakeholders are willing to be highly involved in the development process.
• Management trusts developers to self-manage and self-organize.

Scrum isn't just for software development projects, however.

While Scrum originated in the software development world, the stewards of the framework encourage its application in a variety of other domains -- including manufacturing and construction. In fact, Scrum's origin story is essentially the inverse of Waterfall, which originated in manufacturing and construction and was later applied to software.

When to use Waterfall instead of Scrum

Large enterprises in the banking, government and manufacturing sector tend to prefer a Waterfall-based approach for important projects.

Waterfall works well for these companies when they undertake projects that have the following characteristics:

• Well-defined user stories and feature requirements.
• Development teams larger than 10 people.
• An established DevOps stack and developers who are experienced with it.
• Only minor changes implemented once development has started.
• Management wants to tightly manage the developers on the team.

Large companies often lean toward a Waterfall-based approach because they believe that upfront requirements gathering enables them to more accurately set project budgets and estimate milestone completion dates.

Can you combine Waterfall and Scrum?

Organizations cannot implement Scrum and Waterfall together at the same time, as they are two very different approaches to product development.

However, many organizations start a project in a Waterfall manner by doing requirements gathering and analysis before a project starts. Then, as the development phase approaches, they hire a Scrum master to help plan a transition into a Scrum-based development strategy, and then adopt a Scrum framework throughout the development phase.

The goal of a talented Scrum master is to spread the gospel of Scrum throughout the organization and inspire a transition away from Waterfall-based practices. However, such conversions are difficult to accomplish without a cultural change within the organization.

As a result, organizations sometimes partially adopt or modify aspects of Scrum, and end up doing ScrumBut (it's Scrum, but …). They try to use Scrum throughout the full development lifecycle, but they can't get out of the upfront planning and requirements gathering process that makes their stakeholders more comfortable.