Agile vs Waterfall Software Development

The waterfall methodology takes a linear or sequential approach to software development. Things are done in a strict sequence, with one step following another, in a definite order. It is a very rigid approach that is highly inflexible.

The flow of progress in the waterfall approach to software development, is essentially in one direction: sort of like the way a waterfall in nature does. A waterfall in nature flows downwards and does not go back over its flow. This analogy is where this methodology derives its name.

The waterfall approach has its roots in the manufacturing and construction industries, where the highly structural physical environments dictate that changes to designs be minimised, to avoid the resulting prohibitive costs associated with change.  

In the waterfall methodology, the following phases are followed in order.

1. System and software requirements: captured in a product requirements document.
2. Analysis: resulting in models, schema, and business rules.
3. Design: resulting in the software architecture.
4. Coding: the development, proving, and integration of software.
5. Testing: the systematic discovery and debugging of defects.
6. Operations: the installation, migration, support, and maintenance of complete systems.

This order is followed religiously in a waterfall project, such that design changes are not even considered during the coding phase, for example.

By design, waterfall projects are very well documented, which means that there is easy transfer of knowledge when team members leave due to unforeseen circumstances, or when new team members join a project.

A waterfall project is inherently highly structured, such that milestones are expected to be known from the very beginning, and is therefore suitable for projects with clear outcomes and well understood technologies.

On the downside, clients may initially not be so clear about their requirements, and are bound to want to make changes as the project progresses. This introduces a high likelihood of tension arising between the client and the developer in a waterfall approach.

Furthermore, projects also evolve in the eyes of developers, and as the project progresses, developers may find themselves wanting to make adjustments to the project to suit evolving and emerging circumstances.