Introduction
The Waterfall model is the opposite of Agile and its iterative and incremental approach to product development and management. In this approach, development is broken down into linear, sequential phases. This means that each phase depends on the deliverables of the previous one — in that it also means it is one of the least flexible of development/management methodologies in use today. But, that does not mean it doesn’t have a valid use case in today’s world!
Theory
Generally, the theory behind the Waterfall model is that there are times when executing on a particular project (or in product’s case, development) requires a phase by phase approach to reach its final “definition of done.” Thus, this means that Waterfall typically is a valid choice for work that is predictable and recurring. Conversely, this also means it is a terrible choice for work that is rapidly evolving (shifting requirements and scope, evolving business needs, etc.).
Some may cite that “time spent early in [the product lifecycle]” translates to reduced costs at later stages. For instance, some problems are cheaper to fix early on in the product lifecycle as opposed to later one, where it may require significant refactors of code or large scale redesigns of a product and its features. Additionally, one should also acknowledge that the Waterfall method naturally places a great emphasis on documentation (of requirements, designs, etc.) which minimize the impact of things like team turnover.
Execution
Typically, the Waterfall approach goes through five phases: requirement gathering, design, implementation, validation, and finally, maintainence.
Requirement Gathering
Here, you’re trying to define what the product should do — what is in scope, out of scope, etc. At the end of this phase, you typically know what time and resources you need for the product, an idea of who will work on what, and details on each phase of development.
Design
At this point, you’ll build out solutions to meet the requirements. At this point, you’ll want to introduce some predictability to your development by defining milestones and schedules, clear requirements, and mockups on UX/UI as applicable.
Implementation
Once you know what you need to do and how your product/solution will work, you must now actually build it out. Your developers should be researching how to accomplish any aspects of your product, outline what work needs to be done from a technical perspective, and allocating themselves in a practical manner towards each to-do.
Validation
After you’re team has built an MVP (minimum viable product), you’ll want your QA teams to review the requirements and scope, then run through all use cases pertaining to said requirements and scope. Naturally, the end result of is that you’ve validated you have an acceptable, viable, and shippable product for your customers.
Maintenance
The end of the Waterfall approach is to release new features and bug fixes over newer versions your product. When support your product post-release, you’ll want to have at least a couple communication lines with your stakeholders to collect feedback on what you could do next for the product. These could be through formal ticketing systems or an escalation ladder through staff.
Warning
If any new requirements come up beyond the requirement gathering phase, you’ll need to re-examine your product from end-to-end — this is because, depending on the nature of the requirement, you may find yourself needing to throw out your work thus far and start over.
Conclusion
Waterfall seems to be an inefficient methodology in modern day product development and management — this is far from the truth and, like any other methodology, has its time and place. By employing the Waterfall method, your team would enjoy a clear development structure, clear costs, have an easier time tracking progress, have ample opportunity to document for future reference, lay out a more defined roles and responsibilities expectation, and ideally experience fewer delays as a result of added requirements. However, Waterfall’s limitations include longer delivery times, limited flexibility for creativity and opportunity for stakeholder feedback, increased volume of feature requests post-release, and standstills if any phase faces a significant issue that would result in a work stoppage. These limitations are the reason why many teams may prefer Agile-based frameworks as their go-to modus operandi.
Either way, the bottom line is that depending on the nature of your market, business, and product, Waterfall is a useful tool — its value to you will be dependent on what your unique situation and needs are. Use the right tools for the right jobs!