In this blog I compare Agile, an approach based on flexibility and continuous improvement, with Waterfall, a linear and predictive paradigm. To avoid misunderstandings, I want to add that by predictive I mean that Waterfall greatly emphasises the importance of anticipation versus adaptation, while Agile emphasises the opposite. But I am not saying that Agile teams don’t plan. Adaptive planning is an integral part of any agile project.
Moreover, my goal of making this comparison is not to convince you that Waterfall is bad and that Agile is good; both the approaches carry their own set of strengths and weaknesses to project delivery, and both have projects more suited to them.

The waterfall model, introduced in 1970, quickly gained popularity because it brought discipline in software development. It is a sequential design process, in which progress is seen as flowing steadily downwards (like a waterfall) through several distinct phases: Requirements, Design, Implementation, Test, Deploy, Maintenance.

The Waterfall model does have advantages, such as:
● It is easy to understand and use, it follows the same sequential pattern for all projects.
● Discipline is enforced, indeed every phase has a start and an end point. It is easy to share progress with customers.
● Puts great emphasis on documentation. The detailed documentation makes it easier to hand over to separate support teams. Moreover, in case of employee turnover, the strong documentation allows for minimal impact on plans.
● It is good to be used when the project is a familiar territory with a predictable path and the client knows what to expect.

It has also quite a few disadvantages, including:
● Clients usually appreciate what is needed when the application is delivered, therefore lots of educated guesses and assumptions are made upfront, but software is not delivered until late. The coding begins only at the third phase.
● Once a phase is completed, you are not supposed to go back. If the team discovers that a requirement is missing while being in the test phase, this could have an impact on the rest of the project.
● Changes cannot be easily accommodated: if requirements change, the plan and the budget will be adversely impacted.

Agile addresses the limitations of Waterfall, but it also has a few drawbacks, besides strengths.

Some of the Agile strengths are:
● Change is embraced: with shorter cycles, it is easy to accept changes in requirements at any time.
● It is very good when the end goal of the project is not well defined or when the end outcome is clear but there is flexibility in how it is met.
● Breaking down the project into iterations allows the team to focus on high-quality development, test, collaboration. Having tests during each iteration permits the team to find and fix bugs quickly.
● Working software is delivered at each iteration and customers have the opportunity to use it, share their input and have a real impact on the project.
● Feedback from users and team members is encouraged, so lessons learned are used to improve future iterations.

Some of the Agile drawbacks are:
● Planning can be less concrete as tasks can be reprioritized at each iteration, it is possible that some work items initially scheduled for delivery may be not completed in time.
● The team must be knowledgeable. Agile teams are usually small, so team members must be highly skilled in a variety of areas.
● Documentation may be neglected. One of the Agile values puts emphasis on working software rather than extensive documentation, so team members could consider documentation less important. The team should find the right balance between documentation and code, and acknowledge that this can be challenging for them to balance sometimes.

As I said at the beginning of the chapter, the key to deciding which is right for you comes down to the context of the project. If it is going to be changing rapidly, eg. groundbreaking project with uncertain outcomes and high rates of change, complexity, and risk, choose Agile. In case you know exactly what you need, eg. produce a predetermined end result within a specific date and no flexibility in how to deliver it, then maybe Waterfall is the better option. A third option could be to consider taking aspects of both methodologies and combining them in order to make the best possible software development process for your project.