The traditional Waterfall approach takes each stage of a project in turn, and cannot progress to the next stage until the previous has been completed. In contrast, Agile approaches split the project into small batches that deliver a usable product, and analyse, design, build and test these batches over a shorter period (typically 2-4 weeks).
So here’s 3 reasons you might to go Agile, and 1 reason you might not:
1. You’re not entirely sure what you want, and you’re prone to changing your mind
If you want a keyboard (but in your heart of hearts you just want to play Twinkle Twinkle) a Waterfall project to develop a keyboard with a million additional sound buttons, that only gets your feedback at the end, is 90% wasted effort. In an Agile approach, the first batch would give you a basic keyboard, and chances are you’d decide that was mission accomplished.
Agile lets you refine, re-prioritise and drop requirements as you go along. The incremental nature of the approach means that you don’t have to know everything that you want up front and you haven’t wasted a lot of time and effort fully developing a concept that you’d gone off half way through the project.
This is particularly useful if you’re in a fast-moving, customer driven market, such as mobile phone apps; you can release a small part of the app, get user feedback, and continue or scrap further development depending on the results.
2. Time is of the essence
We seem to have a bit of a thing for firsts. First man on the moon, first person to the north pole, first person to climb Everest. It doesn’t matter if it’s 5 minutes later, being second is just not quite going to cut it.
So if you have an ingenious new product, you want it to be first to market, right? You can’t wait two years for the whole thing to be developed with every little bit working; one of your more enterprising competitors will doubtless have got something out on the market by then!
With the focus on delivering usable products in short bursts, Agile allows you to launch a product that will get your foot in the door and your name down as the first in that field. It might just be a product list with the ability to select and pay, rather than a full-blown Amazon experience, but it’s still enough to be used. Your next batch can add the shopping cart, and the one after that can include reviews.
3. Quality is key
If you’ve just spent the whole day wrestling with a flat-pack dining table and have finally got it up (despite the best efforts of whoever wrote the instructions), would you be tempted to declare it a success when it looked vaguely table-like and didn’t immediately collapse? Maybe it’ll be a couple of weeks before you notice that slightly wobbly leg, and by then all of the tools will be packed away and it’s just too much effort to fix…
When testing is a task to complete at the end of a long and laborious process, there is a risk that there won’t be sufficient time to test in sufficient detail and appropriately fix issues. Because Agile operates in small, usable increments, testing occurs throughout the project and quality is never compromised.
Where products are released to users at the end of each increment, there is also an opportunity for each successive increment to build on the quality of the last.
+1. Nothing is non-essential
Sometimes you know exactly what you want, and exactly what needs to be delivered to achieve that. The construction industry tends to be a good one for this; nuclear power stations can’t have 90% of the original requirements delivered, or be operational in small batches: it just doesn’t work!
Agile works on the principle that not all requirements are essential. You’ll have Must-haves (nothing’ll work without it), Should-haves (it’s going to need a work-around without it), Could-haves (it’d improve the user experience or let people do more things) and Won’t-have-this-times (things that would be nice to have, but are really unnecessary right now)
If all requirements are known at the start and are essential, then Waterfall may be the way forward for you.
