Project Management Methodologies: Agile vs. Waterfall Posted by: Alan on 13/06/2013

Project Management Methodologies: Agile vs. Waterfall image

Waterfall methodology, the more traditional of the two approaches, is very much a structured and sequential process with projects being split into a short number of large stages.

For example, a standard website design and development project for us may well consist of the following key stages:

  1. Research, requirements and scoping
  2. Design
  3. Development
  4. Testing
  5. Deployment

To a large degree, any aspect of this process cannot be properly commenced until the previous stage is complete.

This method has been tried, tested and practised over the last 42 years or more (the first known example dates back to 1956, whilst the first formal description of the process is cited as an article by Winston W. Royce in 1970), so it can’t be all bad. As with all things though, requirements and expectations, not to mention technologies, progress and change over time. Since the 90’s in particular, people started to question and criticise the Waterfall methodology – largely for being too inflexible. For example, with the process detailed above, if a design change is requested once you’ve got to the testing stage, it may have huge implications on all of the work completed thus far. For reasons such as this, new techniques like Agile were developed.

Agile project management is based on a more flexible and modular approach, with project delivery broken down into smaller and numerous iterations called Sprints, with stages and milestones based on weeks as opposed to months. The idea here is that lessons can be learnt and improvements made to your approach all the way through the project, making changes easier to implement than they may otherwise be with a Waterfall process.

So, what works best then? The answer really is horses for courses (as much of a cop out as that may sound!). In an ideal world, when working on any digital project we would deal in absolutes (both client and supplier side) – budgets, deadlines, resources, objectives, features, functionality and even user behaviour and perceptions would all be known for certain at the outset and these facts would all be used in planning and working through a project. This is where Waterfall methods work perfectly well. In reality however, this is not always the case, especially in respect of mobile and apps. In these cases, Agile processes tend to come into their own, as if requirements change or a new ‘must have’ idea comes to light midway through the project, the chances of being able to incorporate this and change tack are much higher (due to the modular approach).

It’s important to weigh up the options of each approach when starting a new project and to fully discuss the pros and cons with both the internal and client teams. In our experience, it’s often more difficult to get sign off for a project using Agile methodologies as the stages, phases and milestones are a little less easy to quantify. Sometimes, however, it may be the best route to take to achieve the best end result and at the end of the day, that’s what we’re all aiming for.


Back to blog