Waterfall vs Agile – what approach to take and when

Agile project delivery has become a victim of its own name. The term agile has been overused and misinterpreted that much recently that it’s common for businesses to latch onto the word “Agile” and assume it must be better than any other alternative.

The main strength of Agile is the ability to start quickly and ensure that a product will always be ready by a specified due date and at a specified cost. In a truly agile project, it is impossible to deliver late or go over budget.

On paper, this sounds perfect, why would you ever choose any alternative when Agile gives you that level of guarantee? As you may have guessed, this assurance comes at a different price, and that is the flexibility on what will actually be delivered at the end of the budget and timeline.

The driving factors in any project are the Time is takes to deliver, the cost/budget and the quality of the final product. Agile locks in place the cost and time but in order to account for the unpredictability of project development, it is agreed before the project starts, that the Quality of what will be delivered cannot be guaranteed.

In order to manage this effectively, an Agile project must be completely transparent and the client must take an active role during the project lifecycle. The development team must be completely transparent regarding what they are working on, how long it is taking them and what they expect to achieve, and in return the client must be honest about budgets and with the help of the project manager, be able to actively prioritise what they want the team to focus on, knowing they may ultimately not get everything they wanted when the time of budget runs out.

To make this process a success, the product manager will capture a high level overview of what the ideal finished product would do in the form of large tickets called Epics. These epics provide a list of functionality that can then be prioritised by the client and development can begin.

As an agile project MUST deliver a functional product by the deadline, development is split into what are effectively mini projects called Sprints.

Each sprint can be between 2-3 weeks and the end result of each, with the exception of sprint 1 which must often include a lot of set up, will deliver something that could be released to the public.

As these micro projects must be releasable, what is delivered must also be fully functional, so bugs must be fixed as they go along and cannot be left until the end like in a waterfall project. This process ensures the quality but does slow down development.

At the end of each sprint is a product playback meeting where the Development team will present their work and then work with the client to amend the priorities for the next sprint. Each following sprint will then work to build upon the output of the previous one, taking into account the new priorities. It is also possible to add in additional features mid project with Agile. You just need to be aware that if something goes in at the top of the list, something must drop off the bottom.

This process continues until there is either nothing left to develop, or the deadline or budget is reached.

Waterfall project delivery is a tried and tested process, and In the same way that Agile has become associated with being lean and current, Waterfall has become associated with how things used to be done in the bad old days when costs would spiral and deliveries were late.

Again, this is an unfair label as an effectively ran Waterfall project will produce higher quality results than an Agile project because delivering an MVP is not an option. For example, you would build a physical bridge using a waterfall project management approach as unless the bridge is 100% complete, it isn’t a functional product. You can’t MVP a bridge.

The main strength of Waterfall is that the risk is transferred to the development team instead of the client. They are responsible for researching and creating the specification and project plan and providing an estimate for delivery of the final product. As the client, once you have communicated your requirements, all you need to do is sign off the specification and agree to the price. It is then on the studio to deliver everything you have asked for.>

It is then the job of the studio to deliver the entire project as efficiently as possible, knowing that any overage incurred is at their cost as opposed to the clients. This usually means the Waterfall projects will cost more up front but the guarantee is that you will get EVERYTHING that was in the specification as opposed to Agile where if you get to the end of your budget and it isn’t finished, you have to buy another sprint.

As the promise of waterfall is that the Quality is guaranteed that means the areas of flexibility in the project are Time and sometimes Cost. The development team will spend a great deal of time creating the specification upfront in order to mitigate as much of these risks as possible in order to make the project profitable but as is often the case, things don’t always go to plan, certain features are more difficult to build and the project will take longer to deliver than initially expected.

During a waterfall project, sprint playbacks or milestone updates will still take place so as the stakeholder, you will be kept up to date with progress, you just can’t make any changes and additions without raising a change request as the specification is the reference point and cannot be amended.

Change requests are permitted but the impact they will have on the already priced project must be taken into account and the budget and timeframe increased to allow for these new additions.
As the project reaches its final stages, it will move from development into a bug fixing phase where the technical debt amassed during the project is collated and all remaining bugs resolved. Before being handed over to you for the final User Acceptance Testing process (UAT) and then final delivery.

If you’re struggling to decide which approach is best for you, these below examples will help serve as a quick reference and will hopefully resonate with your current situation. 

Agile

• “I need something ready before the trade show but it doesn’t have to be perfect.”
• “I have a great idea which I just want to get started.”
• “I’m not 100% sure what the finished product will look like but I know enough to get started.”
• “I have an approved budget and a team I trust to do their best possible work for me”
• “I want to produce a prototype, not necessarily a finished product.”
• “The last thing I want to do is spend days writing, or paying someone to write a specification.”

Waterfall

• “I know exactly what the finished product should look like”
• “I don’t have time to be actively involved in the day to day management of the project”
• “I don’t trust the development team to always be working on my project.”
• “Project budgets are a secret, I want the studio to provide a cost for the build which I will either approve or reject.”
• “I can’t accept anything less than 100% of features for this product.”
• “The board needs the assurance of a well documented signed off specification before they will release funds for the project”

Just be aware that every digital agency will do things slightly differently based on their own experiences, the definitions described in this document are as close to off-the-shelf approaches as possible but that also doesn’t mean you can’t request exceptions if your project requires a little more flexibility or customisation.