WTF is… Waterfall vs. Agile?
Imagine you’re enjoying a magnificent holiday. You want to share your amazing experience with your friends, so you lift up your phone and take a selfie. The first photo didn’t look so good, so you take a second and a third before uploading that beautiful selfie to Instagram.
Nicely done: you just took an ‘agile’ selfie. Now let’s discuss WTF Waterfall and Agile mean, and how this relates to your photo.
Waterfall and Agile are two different approaches to running projects. Whilst other approaches exist, Waterfall and Agile are oft-misunderstood or chosen for the wrong reasons. It certainly took me a while to understand Agile.
So, what is the ‘Waterfall’ approach?
Let’s say you see a market opportunity for a brand new iPhone app — a revolutionary todo list. Embarking on a project to create such an app would rarely just involve developers to write the software, but also involve designers who can understand the target users and how they would want to interact with such an app. You may also have testers who are experts in ensuring the resultant app contains as few bugs as possible.
It’s rare that any one person can wear the hats of a designer, a developer and a tester, meaning each of these disciplines tend to be led by separate people. This means a chronology naturally form: designers do their work first and hand their designs over to developers for creation. Developers then create the app before handing it over to testers for testing.
Each discipline generally works alone and only begins their work once the preceding stage has completed.
Waterfall is sequential: each phase (e.g.: design/develop/test) is generally completed before beginning the next.
The Waterfall approach originated in manufacturing where detailed design and planning needed to be performed before manufacturing began — changes introduced after manufacturing had begun were prohibitively expensive. This led to the term ‘BDUF’ — Big Design Up Front.
As a result, the Waterfall approach works well when most facts are known — or can be easily uncovered — upfront and are not likely to change. This tends to suit shorter, simpler projects.
So, what does happen if you sprinkle a little bit of change into a Waterfall project?
With Waterfall, our functioning app will only be available at the very end of the project (once designed, developed and tested). This means that if the designs are misinterpreted and the ‘wrong’ thing is created, it will likely only be caught at the end of the project when the app is available — often months later.
There is nothing worse than doing the wrong thing well.
— Peter F. Drucker
Likewise, introducing new changes after the design stage is expensive as some amount of rework will be inevitable. If we discover users prefer to use iPads to manage their todos — rather than their iPhones — this would involve redoing a lot of the design and development work that has already been completed. There will also be a similar cost for responding to changes outside of our control, such as new regulations (e.g.: GDPR).
Testers will also only begin testing the app once it has been created in its entirety by developers. Building software is akin to building a house: if the foundations are found to be unsteady only after completing the entire house, it is a lot more costly to fix.
So remember: Waterfall generally gives you one shot at getting things right. It anchors us to our view of what we thought we needed to build when we completed our upfront design.
Well, then what is the ‘Agile’ approach?
Many projects are enshrouded in uncertainty: it is only once we’ve begun the project that we begin to discover what our users truly need and therefore what we need to create for them. In such cases, we cannot exhaustively plan and design at the beginning of the project because that’s the point at which we know the least.
We instead need to break our app idea into smaller pieces. Delivering one small piece at a time means we receive feedback from users early and often as each piece is made available to them. The ongoing stream of feedback allows us to continuously course-correct and reduces the cost of each change — building one small piece incorrectly is cheaper to fix than building an entire house incorrectly. By getting something into the hands of the user early, we also generate a return on investment sooner than with Waterfall.
With Agile, each discipline works together as part of a — generally co-located — cross-functional team, allowing them to build a shared understanding of the problem and solution. This replaces heavyweight designs or documents— which can lead to misunderstanding and rework — with face-to-face collaboration that teases out misunderstanding and refines ideas.
Agile is about being adaptive rather than predictive.
– Martin Fowler
In an environment of uncertainty, Agile trades exhaustive upfront planning for getting started with the first small step. The first step, by its very nature, will be the most uncomfortable — it is the most likely to take us in the wrong direction. However, each step we take furthers the feedback loop with users that allows us to learn and course correct, ensuring every subsequent step takes us closer to our destination.
So what did this have to do with my selfie?
Imagine if you had to use an analogue camera that relied on photographic film. You’d need to take your selfie, fill up the rest of the film and hand the film over to be developed before you’d know whether your selfie was adequate for being posted to Instagram. If it wasn’t you’d need to start the process again. Sound familiar? Yes, that’s Waterfall.
So, when trying to remember the difference between Waterfall versus Agile, think about taking selfies using analogue cameras versus digital cameras.
Well, that’s my view on the Agile and Waterfall approaches to project (and product) delivery. I have, of course, simplified a couple of very deep subjects in order to help convey the important and holistic view.
To dive deeper, I recommend:
Other stories in the WTF series:
