In software development, two of the most widely adopted approaches are Waterfall and Agile Scrum. Yet despite their widespread adoption, there are a number of misconceptions about the underlying differences between them. To help clear up these misconceptions, let’s explore the principles of Waterfall and Agile Scrum in detail. Then look through an example of how these two approaches, often considered rivals, can complement rather than contradict one another.

Waterfall

Carried over from construction

Waterfall as a software development methodology has been around for a long time. It carries over principles from construction, where sequential planning and building is taken for granted as a necessity. This should come as no surprise. When building a structure, you first decide the kind of building you want. Then you hire an architect to develop the precise design, including detailed blueprints. Then you hand the project over to a construction company to build the structure according to the blueprints. And so on.

Sequential order

When software development grew into a substantial industry more than fifty years ago, the Waterfall approach (inherited from construction and manufacturing) was initially the only game in town. Today, on the other hand, Agile Scrum and other methodologies are giving Waterfall stiff competition. Nonetheless, Waterfall remains a leading option, especially for large-scale software projects. However, unlike the construction example above, there is some disagreement about what the actual sequential stages of the Waterfall approach to software development actually are. If you ask four different industry experts, you’re likely to get four different answers. Nonetheless, generally everyone agrees that under a Waterfall framework product requirements always precede design; design always precedes development; and development always precedes testing and release. Like a cascading waterfall, there is a one-way flow, and each subsequent stage of the project is further downstream. Although few would argue that each stage in Waterfall is always 100% fixed and final, strict adherence to the Waterfall approach means you can’t go back to a prior stage. Beyond trivial adjustments, once the design is complete, that’s what you’re going to build. Moreover, once you’ve built it, that’s what you’re going to present to the public. Period.

Agile Scrum

The first thing to remember when exploring Agile Scrum is that it is a specific on-the-ground implementation of the wider Agile methodology and philosophy. One of the concepts at the core of the Agile philosophy that’s put to practice in the Agile Scrum implementation is continuous deployment. As an extreme example of the enormously popular “release early, release often” school of thought, continuous deployment creates a constant feedback loop between project teams and users, greatly reducing the risk of major bugs and backlashes. To achieve continuous deployment, however, requires parallel work on various stages of the software development life cycle at the same time. As a highly flexible, adaptive, incremental and collaborative approach, Agile Scrum makes this parallel work feasible and productive. This capacity has earned Agile Scrum a reputation as the ideal approach for small to medium-sized teams working in fluid, rapidly shifting environments and markets.

Primary differences

Both Waterfall and Agile Scrum are methodologies or frameworks for facilitating your software project’s completion. By working within a shared framework such as Waterfall or Agile Scrum, team members can more efficiently communicate, collaborate and achieve a common goal. Having a shared project framework also gives teams a shared language and philosophy that fosters group solidarity. However, the particular framework you choose can make all the difference in the success of your project. When choosing between Waterfall and Agile Scrum, it’s important to focus on their vastly different approaches in two key areas: deadlines and project facilitators.

Stages vs sprints

The basic time unit in the Waterfall approach is the overall project deadline. Under the Waterfall approach, the project is handed-off to different departments and teams as the project progresses through each subsequent stage of its life cycle: requirements, design, development, testing, etc. A stage may last weeks or months, and the overall project deadline may be six months to a year or more out. By contrast, the basic time unit under the Agile Scrum approach is the sprint, and the project may involve dozens of them. During each sprint, which often lasts only a week, the team runs through the entire sequence of stages that Waterfall goes through only once in the lifetime of the project. This striking difference strongly affects how Agile Scrum teams handle deadlines. While Waterfall sets a long-term strategic deadline that is often treated as a do-or-die absolute, Agile Scrum involves an ongoing series of short-term, tactical deadlines tied to sprints and governed by continuous user testing and feedback.

Project managers vs scrum masters

Under the Waterfall approach, the project manager guides the project through each sequential stage, and therefore works with each separate department in sequence. Throughout this time, the project manager ensures that the project is on track to meet its long-term deadline; that the initial product requirements are met; and that the entire process is well documented along the way.

In Agile Scrum, one of the most common terms you’re going to hear is scrum master. In contrast with project managers, scrum masters generally work with a single interdepartmental team. And rather than keeping the team focused on meeting fixed requirements by a fixed deadline, the scrum master keeps the team focused on the principles of Agile Scrum, such as continuous improvement and self-organization. The scrum master also ensures that stakeholders overseeing the project have a complete understanding of the virtues of Agile Scrum, which may otherwise seem unusual to them.

When Waterfall and Agile Scrum work together

It’s a common misconception that Agile Scrum and Waterfall are mutually exclusive and cannot play well together. In the real world, a single project may have key elements that call for Waterfall, and others that call for Agile Scrum. For example, suppose your team is given the task of tackling a large, high-priority software project. Given the scale of the project, stakeholders will not give you buy-in without a firm deadline and detailed product requirements. However, stakeholders are otherwise flexible with respect to how you handle the project. With their permission, you decide that there’s no need to rigidly separate design from development, nor development from testing. Although you cannot release an official product until the long-term deadline, you find that you can release weekly invitation-only previews to early adopters, who give you continuous feedback. In the end, Waterfall and Agile Scrum do not conflict, but complement each other, as your project benefits from the overarching structure of Waterfall and the continuous improvements of Agile Scrum.