Waterfall is a project management approach where a project is completed in distinct stages and moved step by step toward ultimate release to consumers. You make a big plan upfront and then execute linearly, hoping there won’t be any changes in the plan.
When you take traditional project management and apply it to software development, you get Waterfall. As such, no one invented waterfall - instead, we gave it a name once we realized that there are other ways to manage projects (like agile project management).
Waterfall was the first software development methodology, inherited from the manufacturing and construction industry, where you can't afford to iterate (after you've built a tower or a bridge you can't go back to "improve" the foundation). But because the software is prone to frequent change, the waterfall is not the best solution.
Waterfall is often mentioned alongside Agile and stands in contrast to it. The main difference between them is that waterfall doesn't react well to frequent changes, which is why it gets a bad reputation in the software development community, where frequent changes are the norm.
Project Management Methodologies and Frameworks
Phases in waterfall projects
All tasks on waterfall projects are grouped by type of activity and each project follows the same phases:
- Requirements - where we analyze business needs and document what software needs to do
- Design - where we choose the technology, create diagrams and plan software architecture
- Coding - where we figure out how to solve problems and write code
- Testing - where we make sure the code does what it supposed to do without breaking anything
- Operations - where we deploy the code to a production environment and provide support
Once you put all the activities on a Gantt chart, you get something that looks like the slopes of a waterfall, hence the name.
Usually, 20–40% of the time is spent on requirements and design, 30–40% on coding, and the rest on testing and operations.
Activities on waterfall projects have to happen in the exact order, and one set of activities can't start before the previous one ends. This is why planning is the most important thing on waterfall projects: if you don’t plan right, a phase will be late and will push every other subsequent phase, thus putting the whole project over deadline.
The problem with using the waterfall method on a software project is that planning is very tricky in software development. You can never be 100% sure how much time you'll need on something or how much time you'll spend debugging. As a result, the waterfall is risky.
Advantages of waterfall
Extensive documentation
Because you can't go back to a previous activity, you're forced to create comprehensive documentation from the start, listing all the requirements you can think of.
Knowledge stays in the organization
When you have extensive documentation, knowledge won't get lost if someone leaves. Also, you don’t have to spend time training new members, as they can familiarize themselves with the project by reading the documentation.
Team members can better plan their time
Because everyone knows in advance what they'll work on, they can be assigned to multiple projects at the same time.
Easy to understand
Waterfall projects are divided into discrete and easily understandable phases. As a result, project management is straightforward and the process is easily understandable even to non-developers.
The client knows what to expect
Clients can know in advance the cost and timeline of the project so they can plan their business activities and manage cash flow according to the plan.
Client input not required
After the requirements phase, client input is minimal (save for occasional reviews, approvals, and status meetings). This means you don't have to coordinate with them and wait for when they're available.
Easier to measure
Because waterfall projects are simple, it's much easier to measure your progress by quickly looking at a Gantt chart.
Better design
Products have a higher cohesion because during the design phase you know everything that must be taken into account. There is no one-feature-at-a-time problem that leads to usability problems down the road.
Disadvantages of waterfall
No going back
Once you're finished with one activity, it's difficult and expensive to go back and make changes. This puts huge pressure on planning.
No room for error during the requirements phase
Everything relies heavily on the requirements phase and if you make an error, the project is doomed.
Deadline creep
Once one activity is late, all the other activities are late too, including the project deadline.
QA too late to be useful
Testing is done at the end of the project, which means that developers can't improve how they write code based on QA feedback.
Bug ridden software
Because the testing is done at the end, most teams tend to rush the testing in order to deliver the project on time and hit their incentives. These short-term wins lead to sub-par quality and long-term problems.
Not what the client actually needs
Most of the time, clients can't articulate what they need until they see what they don't need. If the client realizes they need more than they initially thought, the project plan will need a major overhaul (as well as the budget).
Unexpected problems
Designers can't foresee all the problems that will arise from their design, and once those problems surface, it's very difficult to fix them.
On what types of projects should you use Waterfall
Waterfall is suited for projects where:
- budget, requirements, and scope are fixed (e.g. you're building a one-off project which doesn't need further development)
- you can accurately estimate the work (you're familiar with technology, and you've done the same work before)
- you can't afford to iterate (e.g. you're building a heart rate monitoring software)
- project is innately low-risk (you're building a clone of something that already works)
- the project has a hardship date (e.g. you have to ship a video game by Christmas)
- your users can't or won't update software (doesn't apply to web applications, where updates are seamless)
You shouldn’t use a waterfall:
- where a working prototype is more important than quality (e.g. you first need to test if there’s a market demand)
- when you don't know what the final product should look like
- where a client doesn't know exactly what they need
- when the product is made for an industry with rapidly changing standards
- when you know you won't get the product first the right time and have to incorporate user feedback
- when your users are happy with v1.0, and you can ship additional features as time goes on
Whether you'll use agile or waterfall doesn't matter on your preference, but the type of project and your customer/client. While strictly speaking agile is better for software development (see the statistics here), if you can't iterate, you have to use waterfall.
Waterfall is not that different from Agile
Waterfall is always mentioned as the antithesis to Agile, which makes sense. After all, waterfall projects have a hard time dealing with changes, while agile projects welcome change. At least in theory.
The truth is, no matter what methodology you use, change is not a good thing. Change always means additional scope, delay, and expenses. Agile is better at minimizing the effects of change, but they still happen. Also, agile teams have a culture where change is OK, which is maybe the most important benefit of being agile.
"The key to successful project management is to adapt. If you're constantly evolving, you are perfectly suited to project management's nature, as it is a beast that is continuously unknown. Success rests on the shoulders of your ability to plan ahead and adapt." — Kalila Lang, DigiSomni
But once you scratch behind the surface and look both from a pure process perspective, waterfall is very similar to agile.
Once you break down any agile workflow, you'll still get a set of activities that follow one another, which eerily resembles Waterfall. And if you treat waterfall projects as smaller phases within a big project, you'll end up with agile.
In other words, activities on a project are a waterfall and if you treat the whole project as a series of iterations, it’s agile.
Whether you're agile or waterfall ultimately depends on whether your client expects the first version to be bad. And waterfall projects are projects where the client decided on zero iterations.
In agile projects, the number of iterations is decided on by the customer. Because things are all done within an iteration in agile, the logical assumption was that an iteration equaled a project. But an iteration is more properly referred to as a phase or subphase of the project. - PMI
As you can see, agile still fits in the traditional project management, only the point of view changes. Instead of treating each iteration as a separate project, iterations are just phases in one big project.
The real difference between the waterfall method and agile is that in the waterfall, the clients are heavily engaged at the beginning of the project and then their engagement declines; while in agile, the client is constantly engaged.
So what does this all mean in practice? It means no organization is purely agile or waterfall. Agile and waterfall are more about the culture and type of work the organization does than how they do it. You’ll find that most organizations divide the project into a waterfall milestone, but work according to agile principles between those milestones.
A problem common with comparing agile and waterfall is the labeling. Few, if any, companies are purely "agile" or "waterfall". They are more mindsets that encompass a wide variety of practices and approaches to development. Labels are convenient for helping make an argument, often with cute little straw-man statements to help reinforce preconceived notions. - Clinton Keith
