It’s the 1980s and the era of the Walkman, CDs, and dazzling our house guests by illuminating a room with a mere clap.
We heard the Microsoft Windows start up sound for the first time, we excitedly brandished mobile phones that were the size of actual bricks, and Apple Macintosh looked more like BMO than the sleek beast it is today.
We didn’t know it but we were standing on the precipice of a tech explosion that would change our lives in unfathomable ways at such a pace that it would outgrow the very processes that brought it to life in the first place.
Enter: Waterfall, a linear project development framework where each task must be completed before ’flows’ into the next.
Often separate teams would work on each phase, passing the project down the chain once they’d made their contribution. This development process was long, sometimes spanning several years and, while this worked well in tech’s infancy, as the pace of living began to exponentially speed up and needs began to change far more rapidly than ever before, waterfall products were becoming obsolete before they’d even hit the market.
Naturally, nobody was pleased, least of all a group of software developers that decided to change things up with a new development framework called Agile. Unlike waterfall which did its initial research then effectively retreated into a cave to develop, Agile was built around change. Specifically, the changing needs of the customer.
But what does Waterfall actually look like in practice?
Waterfall is made up of five distinct phases that must be completed in a specific order: requirements, design, implementation, testing and delivery. Firstly, data is gathered via liaison with clients or customers. It’s rigorously analysed, mapped out and then the project is coded and otherwise developed. Only after it’s complete is it put to the test to determine whether or not it has met the brief. If it has, it’s handed over to the client or customer in the delivery phase. If it hasn’t, it needs to be started from scratch costing more time and money. Therein lies Waterfall’s Archille’s Heel.
Is Waterfall still used today?
Yes. Despite being mismatched to the fast-paced nature of the tech industry, there are still teams that use Waterfall. Why? Its ordered structure and tick box approach to initial requirements make the process easy to understand and manage, particularly for a top-down management style. It also can actually work for small, simple projects with clear, static requirements that don’t require any level of developmental flexibility.
For beyond basic projects, however, and even for basic ones, Agile is your better bet, provided the team is supported enough and ready to commit to a more freeform, change-friendly way of working. Wield Agile well and your team is more likely to futureproof your team’s efforts creating a product that’s better and more relevant for your client or customer (and potentially at a faster rate and cheaper cost) than you’d ever hope to achieve prescribing to Waterfall. Efficiency is all well and good but if you’ve missed the mark completely, albeit in record time, nobody’s going to be impressed.