Waterfall vs. Agile methodology: Differences and examples

What is Waterfall?

Waterfall is an approach to project management and software development that follows a linear sequence of events. In Waterfall, each phase of the project is gated. Teams cannot advance from one phase of the SDLC to the next until the current phase is complete. Each phase has clearly defined completion criteria. Criteria for the project are generated in the first stage of Waterfall -- the requirements stage -- and codified in documentation. The requirements set forth in the beginning ideally do not change during the course of a development project in this model.

Waterfall suits projects that require a high volume of documentation and have repeatable, predictable processes. It is especially effective for projects with well-defined requirements and minimal expected changes, ensuring consistency and traceable control.

What is Agile?

Agile is an approach to project management, specifically software development projects, that prioritizes collaboration, continuous delivery and customer feedback. Agile breaks work into iterative steps, which are smaller tasks that can be completed quickly. These iterations are done during sprints. Agile teams complete one sprint before moving onto the next one. Requirements can change at any time in the project based on changing business needs or customer feedback. Future sprints are based on the outcomes of previous sprints.

There are several frameworks -- Kanban, Scrum and feature-driven development, for example -- that help software teams put Agile into practice and implement the 12 principles outlined in the Agile Manifesto. Agile teams are self-organizing, and team roles can shift over time. Agile is best for projects that have flexible processes and incorporate customer feedback throughout the process.

Agile vs. Waterfall

Agile software development emphasizes iterative work. This distinguishes Agile from Waterfall development, which entails grouped development, where all the work must reach the same point of completion before moving onto the next phase of the SDLC.

With an approach based on small changes, complex software development processes are trackable and manageable for all stakeholders. If development teams try to change too much code at once -- if, for example, they try to build a number of new features at the same time -- they risk encountering unanticipated problems that delay the project. These delays can create challenges for other stakeholders -- for example, a business department that expects a new feature to be available by the date of a customer project kickoff.

Agile limits the scope of work and focuses on adapting to changing circumstances. These traits make Agile beneficial for complex projects in which unanticipated problems can arise and require development teams to pivot in response.

The tendency for Waterfall projects to go over anticipated deadlines and scope means that Waterfall is rarely used today. In general, most teams prefer Agile.

By opting for an Agile approach, developers can gain a range of benefits, including the following:

• Greater efficiency. Isolated changes help developers spend less time implementing extraneous functionality or chasing down the source of bugs.
• Faster software releases. Agile helps developers avoid delays within the SDLC. Developers can move on to other tasks more quickly when they are not waiting for one large release. It also benefits users, who obtain new features faster.
• Greater adaptability. Under Agile, teams can change plans if they decide against a given feature. In Waterfall, a team commits to many interdependent changes that it implements simultaneously. When multiple projects come together in Waterfall development, canceling or modifying some changes impacts others.
• Enhanced stakeholder collaboration. By keeping projects on time and on task, Agile helps ensure that developers can collaborate effectively with stakeholders. Stakeholders might include business users who expect a new feature by a certain date or IT teams that need to provision the infrastructure to host a new application release.
• Less complexity for users. Software users benefit from Agile because changes arrive in small batches. They don't have to adapt to a totally new version of an application that has been overhauled in major ways all at once, as they might if developers followed a Waterfall approach.

Still, Waterfall may work for software development projects where the following is true:

• The requirements for the project are clearly defined, meaning there is no need for detailed planning, analysis and design processes.
• The total work necessary to complete the requirements is small in scope.
• There are only a handful of developers, and they can collaborate efficiently without an Agile framework to guide them.
• The deadline for the project is flexible.

Under these conditions, Waterfall can be preferable because it doesn't require as much planning and orchestration.

Examples of Agile and Waterfall within the SDLC

Agile and Waterfall provide general guidance on how to structure the SDLC. It's up to the developers to decide exactly how they get the project done within one of these methodologies.

An approach to integrating Agile into each of the seven stages of the SDLC might look like this:

• Planning. During the planning stage of the SDLC, developers establish a reasonable scope of changes that they want to implement. For example, they might decide to build a single new application feature.
• Analysis. After deciding what to implement, developers perform analysis to determine how they will do it. Following an Agile approach, they break the work into small, discrete tasks.
• Design. Agile doesn't necessarily shape the design stage, which focuses on defining software architectures, components and interfaces associated with the planned changes. However, an Agile design philosophy might encourage the use of small, modular units within application architectures and interfaces since this fits the Agile concept of keeping tasks discrete and manageable.
• Implementation. During the implementation stage, developers make only the specific functionality they've decided to build. Even if there are other requirements to address -- for example, if there are known segments of the application code that could be optimized to improve performance -- they ignore those for the time being to focus on just one predefined task.
• Testing. An Agile testing strategy breaks software tests into small units, and then the team performs them incrementally. Small, incremental testing makes the testing team's workload estimable and gives them the flexibility to adapt to failures in test.
• Deployment. Agile doesn't necessarily have to change the IT team's approach to deployment, which means moving a new application release candidate into production. However, in Agile, deployments happen more frequently than in Waterfall. Each incremental change deploys separately. In Waterfall, multiple changes deploy together simultaneously. Incremental deployment strategies, like canary releases and blue/green deployment, complement Agile.
• Maintenance. Agile doesn't dictate anything in the maintenance stage of the SDLC, which is the period when developers and IT teams monitor an application in production. Teams can collect feedback about problems encountered during production and use it to drive the next round of application updates.

In contrast, a Waterfall approach to the SDLC might look more like this:

• Planning. During planning, developers create a list of changes they want to implement. Some might add application functionality, while others might enhance existing capabilities or improve performance.
• Analysis. The diverse set of changes that developers are targeting makes it challenging to run a complete analysis of each one and generate specific, detailed plans. As a result, developers might only achieve a basic analysis of what is required for the design. In this scenario, developers might fill in the details once work is underway.
• Design. Likewise, a Waterfall approach to design typically means having only a basic vision for the application architecture, components and interfaces and planning to work out the details later.
• Implementation. During Waterfall-style implementation, a set of development teams write the code necessary to build the features or other changes within the project. Along the way, they might decide to take on additional tasks that they didn't originally plan on so that those changes can roll out with the project, not wait until a new project starts.
• Testing. All changes are implemented together and tested together. Due to the volume of changes that appear simultaneously within the application, it may be unclear which updates cause which problems in testing. When developers fix issues with one part of the code, they may break other code that depends on the code they fixed. For this reason, developers return to the implementation phase to overhaul the codebase and then test again. If they discover new bugs that force them to implement additional code, this process repeats and so on.
• Deployment. As with Agile, Waterfall doesn't dictate a particular deployment method. However, the large number of changes implemented during the project typically makes deployment complex. In Agile deployment, fewer components have typically changed.
• Maintenance. Similarly, an application developed under a Waterfall approach is likely to have complicated change management. In addition, because Waterfall release cycles take so long, any bugs discovered during the maintenance phase may take a long time to fix.

These examples show why many development teams have drifted away from the Waterfall methodology. The development team using Waterfall was not prepared to handle failures in test, creating inefficiencies. The roadmap that the development teams using Waterfall committed to was thrown out as developers chased down bugs repeatedly. Ultimately, it could take many months, or even years, longer than originally expected to release the updates they planned. The Agile team was able to adapt to failures in test by making workloads more manageable. The Agile team stayed on schedule by anticipating the need for flexibility in the SDLC.

The table shares a condensed summary of each methodology's effect on the phases of SDLC.

Chris Tozzi is a freelance writer, research adviser, and professor of IT and society who has previously worked as a journalist and Linux systems administrator.