Waterfall vs Agile in experience design projects

The team evaluates the pros and cons of Waterfall and Agile delivery methods.

In my opinion there are primarily two project management methodologies employed by Experience Design agencies: Waterfall and Agile.

These are both valid approaches with pros and cons for each.

But often agencies will choose to solely deliver projects using one methodology. In some cases they will apply certain management models to projects that fall into a particular category (design, development etc) but, more often, agencies will adopt a methodology and implement only that throughout all of their projects.

However, from my experience, large experience design projects require a more flexible approach focused on outcomes rather than process.


“As its name implies, the phases in the Waterfall model consistently progress downward. These phases should be followed in sequence to be effective.”(www.techopedia.com).

Waterfall involves a series of gates or phases that must be completed in sequence, and is particularly useful for small user research projects that are clearly linear.

Some benefits of using Waterfall
Some shortcomings of using Waterfall

Agile is possibly the most passionately debated methodology in the world of user experience right now. Agile was developed initially to manage software projects when Waterfall (and others) were not suitable.

In essence “Agile methods promote a process that encourages development iterations, teamwork, stakeholder involvement, objective metrics and effective controls.”(www.allabout agile.com).

Some benefits of using Agile
Some of the shortcomings of Agile
Experience Design and ‘Wagile’

People dedicated to a particular management style would argue they do so because that methodology is the ‘best way of managing projects’, in my opinion there isn’t a ‘best way’ of managing a project.

An approach must be designed based on a number of factors such as preconceived budget and deadlines/key dates, type of activities, size of the team, skills required and skills within the team.

In large experience design projects there are a lot of moving parts, a lot of concurrent activities requiring multiple skill sets. Some of these are dependent on others completing, often many are not. In terms of the factors I mention above, there are often fixed budgets and delivery milestones - even if these can be negotiated at the start of the project it’s unlikely they can be negotiated in flow.

Clients often have external factors that drive their need for the project to answer all unknowns within the first quarter of the project and therefore implementing a purest management style is not feasible.

My preferred management style is a hybrid of what I think is most appropriate at the start of the project and what continues to work throughout. It often comes in the form of ‘Wagile’ which I am not claiming to have coined, it’s a well-known term to describe a methodology, especially within design agencies that can’t quite commit to complete Agile and still hold some Waterfall style techniques.

It’s probably frowned upon by most Agile professionals but to me it doesn’t actually matter what methodology or project management style you apply, as long as the project can be deemed a success. Which elements I choose to include from either methodology is dependent on the project but what never changes is what success looks like.

Measures of success

The answer to this will be derived by an assessment of the project factors at the start of the project and there could be some variance, or weighting of importance. However in my eyes there are some principal measurements of success:

If these criteria are met, and the project is deemed a success, does it really matter which methodology I used to get there?

Related articles