Waterfall vs Agile in experience design projects

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.

Waterfall

“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

• This management technique requires discipline (could be beneficial or detrimental). Every phase has a start and end point and involves clearly defined milestones and deliverables – usually at the start of the project.
• Emphasis on planning and detailing requirements at the start of the project encourages agreement by stakeholders using minimal initial expenditure – ‘no doing’.
• Due to the amount of documentation throughout the project, the Waterfall methodology can aid efficient knowledge transfer between team members that may be resourced onto other projects whilst not actively working on this project.

Some shortcomings of using Waterfall

• Relies heavily on detailing the requirements at the start of the project. Although in theory this should mean an approach and plan is agreed at the start of the project, in reality projects always throw up unknowns that could not have been anticipated at the beginning; especially on larger projects.
• Once a stage is complete, that task will not be revisited. Therefore as a project progresses it can render designs and project outputs obsolete.
• A traditional Waterfall approach would insist on all testing to take place at the end of the project, meaning any issues are not discovered until then and cannot be rectified. This in particular does not support our experience design process in which users are involved from the beginning.
• This methodology doesn’t take into account a client’s evolving needs. If the client realises that they need more than, or a variation of, what they initially thought - and demand change - the project is likely to come in late and impact budget.

Agile

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

• Improves the transparency of the project including activities which improve engagement, often streamlining sign-off (which I mentioned as an issue that I discovered with Waterfall).
• Due to the ever evolving project factors, the project approach needs to be able to endure and adapt to change, Agile allows for this. 
• Often due to breaking down the work into smaller, more manageable pieces, having regular collaboration and reviews with stakeholder input, the finished product is of a higher quality.

Some of the shortcomings of Agile

• Often there is a non-negotiable deadline and / or budget which goes against the Agile way of setting expectations with clients or project owners and would not be acceptable.
• Foolproof do not usually handle the backend development, this is usually done by the client or third parties and Agile isn’t always feasible because of factors such as remote location of the other team. 
• If all project deadlines are being met and projects are being deemed a success, at least by particular teams, there will be an understandable hesitation from the team to change their already successful model and adopt something new.

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:

• The customer is extremely satisfied and provides good feedback to client services.
• All major project milestones were met and deliverables approved.
• The budget made a healthy recovery and the financial target met.
• The team are pleased with the outcome, enjoyed most of, and were ultimately motivated by the experience. 
• The project should be deemed successful

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