Agile vs Waterfall. What Should You Use For Your Project?

Agile vs Waterfall. What Should You Use For Your Project?

NB This is a cross post from an article I wrote for The Digital Project Manager site in July this year.

I’ve been working in project management for quite a long time (I’m not going to give exact figures here, but I’ve been around since the days iPhones were a distant gleam in the eye of Steve Jobs and Facebook was The Facebook…)

One thing project managers, and specifically digital project managers have always been obsessed with is methodology. But methodologies are a big deal in the Project Management world. Why do we hinge everything we do around them – and do they really matter that much?

In this article I’m going to look at what the core methodologies used in Digital Project Management are, which you should choose and whether there is a different solution.

In summary, I’m going to approach these topics:

  1. What are these ‘project management methodologies’?
  2. Which methodology should I use on my project?
  3. ‘I want to move to Agile, but it’s just too hard to implement’
  4. ‘Does a methodology guarantee project success?


1. What are these ‘project management methodologies’?

So what is a methodology (apart from being a really dull word)? It’s a framework of the processes involved in your project, and your management of it. It generally involves core tasks including initiating, planning, executing, monitoring and closing the project.

There are loads of project management methodologies to choose from. There are the more traditional, linear ones, like the well-known Waterfall. Then there’s the Agile framework, with different branches: Scrum, Kanban and Lean, for example. There’s Critical Chain Management, and the exciting sounding Benefits Realisation Management. Extreme Programming,Prince2, the Adaptive Project Framework – the list goes on.

I’m going to focus on the two big hitters that come up time and time again when talking about digital project management. Step forward the baddy of the DPM world, Waterfall, and in the other corner, Agile – the ‘silver bullet’, the ‘magic formula’. After all, Agile is best right?

‘Agile is best, right?’

Not necessarily. Both methodologies have benefits, and both have projects more suited to them. So let’s take a more in-depth look at each.

Agile vs Waterfall: The Principles

Core principles of Waterfall

Upfront requirements gathering:

Developers and clients agree on what will be delivered early in the development lifecycle. This can make planning and designing more straightforward. Progress is more easily measured, as the full scope of the work is known in advance. Good technical documentation is part of the deliverables and it is easier for new programmers to get up to speed during the maintenance phase.

Work completed sequentially in phases:

Each phase generally begins as the previous one ends. Throughout the development, various members of the team can be involved or continue with other work. For example, testers can prepare test scripts from requirements documentation whilst coding is underway.

The approach is very structured and it can be easier to measure progress with clearly defined milestones, and easier to plan for at the beginning

Testing occurs at end of development:

Testing is more straightforward to plan and execute, as it can be done by reference to the scenarios defined in the functional specification, at the end of the development phase.

Clients or stakeholders don’t need to be heavily involved:

Except for reviews, approvals, and status meetings, a customer presence is not strictly needed after the requirements phase.

Core principles of Scrum

In 2001, a group of developers got together and developed what is now known as the Agile Manifesto, which describes the four values that they saw underpinning this way of approaching development. In these 200 words, they pretty much changed the face of software development, and spawned massive industries off it.

Whilst Agile is the framework, Scrum is the approach that uses Agile. As you’ll see, a lot of both the framework, and the specifics of Scrum, do make sense when you’re thinking about digital projects.

Individuals and interactions over processes and tools:

Firstly it focuses on individuals and interactions over processes and tools. Communication is key, not the processes that run your project. Within Scrum this means the self-organising, cross-functional team.

Working software over comprehensive documentation:

There is a strong focus on getting shippable products more quickly, rather than spending a lot of time writing down requirements. In Scrum, time-boxed sprints of work are run with a shippable product at the end of each sprint.

Customer collaboration over contract negotiation:

Agile values specify client or customer collaboration, working with the client at all points with them being heavily involved throughout the process. Scrum has consistent, and regular, client involvement.

Responding to change over following a plan:

Rather than seeing changes as the enemy, being in a position to see change as a good thing and being responsive to it is core to the Agile framework. Scrum has constantly evolving requirements, and change is embraced.

All of these things really make sense when talking about digital. Communication as a team, getting something working quickly, involving the client and – when digital is a constantly changing landscape – being able to respond quickly to change.

2. Which project management methodology should I use on my project?

What should influence your decision on which methodology to apply to a project? Until you know what the project is and other influencing factors, you’re not going to be able to decide which is best suited. Some (or all) of these factors should be taken into account when looking at methodologies:

  • Size of the project
  • Duration
  • Complexity
  • Organisational factors
  • Clients or stakeholders, external and internal.

What projects can Waterfall be suited to?

Waterfall projects are:

  • Projects where you’re working with other organisations or remote workers
  • Projects with a fixed scope, time and budget
  • Smaller, well-defined and simpler projects
  • Projects with an absent client.

What projects can Agile be suited to?

Agile projects are:

  • Projects where your organisation is responsible for the whole process
  • Projects with scope for changing requirements
  • Larger, undefined, complex projects
  • Projects with an involved client.

But do organisations really take into account all of these factors? What, or who, actually decides a process? Possibly the main thing that influences a chosen methodology is existing processes. Your organisation’s current processes are likely to determine how you run your project – whatever that project is. It’s the classic one-size-fits-all approach. Given that each project has different needs, and can differ quite widely in influencing factors, this isn’t the best way to run every project at your organisation.

So come on, which is better?

I’ve been sitting on the fence so far, saying both methodologies I’ve featured have benefits in their own right. But if we’re living in an ideal world, the Agile approach does suit pure digital projects more. All the principles do seem to fit the digital landscape, where evolving needs and change are present throughout all projects. I’ll take a look at some of the key benefits below.

Regular iterations

Regular iterations of work, which includes the testing and reviews by stakeholders every two weeks (each sprint, for example) really do help to keep a project on track.

A few years ago I was managing a project that we had to work using a Waterfall approach. The whole thing was defined and designed by another agency. We didn’t have a staging site set up for it at the time, so the developer was just working locally on their machine (first mistake). We had regular catch ups and things seemed to be going fine. However, we didn’t see a working product on staging until we went into initial QA. At this point we found out that there were large parts unfinished and the CMS was not built correctly and according to spec. If we’d had regular iterations of build to a shippable product we’d likely have avoided this. There’s much more exposure to the product throughout the project.

Think of two of the meetings that you have in Scrum: the review – so reviewing the build at the end of the sprint, and the retrospective – reviewing the work completed in the sprint. They are your early warning signs for anything veering off track.

Client involvement

There was an IT and software project review done over a five year period, called the Chaos Manifesto, published in 2013. They found the biggest factor in project success was a committed executive sponsor or product owner. When the client is involved in shaping the requirements along the way of the project, such as reviewing the work, and defining priorities – it means that they are less likely to throw up surprises suddenly. They are constantly feeding the business and user requirements into the process.

In one project I worked on about five years ago, the client wasn’t involved much. We had a weekly check-in, but all they wanted was a weekly status report delivered to them on a Monday. We tried to get them more involved in the actual UX meetings and definition, however they were too busy on another project. We got to the wireframe presentation, and their first comment? “These wireframes look too sad.” Yes, seriously. I was managing a project with ‘sad’ wireframes. Sad face indeed :(

‘Those wireframes are so, so, sad…’

Apart from a lack of understanding of the purpose of the wireframes, they hadn’t fed in their requirements to the process properly, and weren’t involved in the evolution of the idea. So we had to backtrack and waste a few weeks of the project.

Team collaboration

Rather than UX working to define a project, handing to design, then handing over to development, with everyone in their own siloed areas – you can avoid a lot of issues by the team collaborating during the project. As you can see from the project I talked about before with the developer working more in isolation, if there had been more collaboration earlier on it could have avoided surprises towards the end.

Evolving requirements

This is one of the crucial benefits of Agile frameworks, and Scrum. They accept and cope with change a lot better. Changing scope and requirements do not throw the project into crisis. In fact, this is the aim of the sprint review and the sprint planning meeting, to work out what changes are needed. On more linear projects, plans are worked out months in advance of development, and based on generally rough estimates at the time – and then set in stone.

Let’s face up to the truth here, linear project plans just don’t work.

Where your requirements are set at the beginning, and deliverables and timings are all worked out months in advance – what then happens? Things change, and this leads to project delays, as everything has to be re-scoped and redefined.

– “Over a 5 year period, an average of 53% of projects ran over on cost, and 76% ran over on time1”

The Chaos Manifesto, 2013

If we took an example of an agency who run on average 50 projects in a year, that’s over 25 projects running over on costs and 37 projects (out of 50!) running over on time. Something obviously isn’t working.

Here’s a great example:

When I create a linear project plan, this tends to happen. This is my timings folder – have you seen something like this before? Something on the project changes, so you amend the plan. Then the client wants to add something to the scope, so here we go again. On this project I created 10 versions. (And yes, I also realise I needed an Archive folder…)

I can’t actually remember the last time on a more traditional linear project I didn’t have to amend the project plan at least twice during the project’s course. That’s because projects change. Clients change. User needs change. Technology changes. Digital is constantly changing. So Agile frameworks tend to have better ways of responding to change. In fact, they embrace it rather than seeing it as a big blow to the project.

3. ‘I want to move to Agile, but it’s just too hard to implement’

However, it’s not always easy to implement Agile approaches fully or straight away in organisations. As we’ve seen, there are a lot of factors involved in implementing a process. Agile approaches don’t always sit well in agencies where clients want a fixed scope, budget and timelines up front. So,step forward the hybrid. Yes, you’ve all probably heard the dirty term, Wagile…

When I was researching my talk on this subject for Deliver Conf last January, I looked into the term Wagile and came across a couple of articles by this developer. This is my favourite, very damning quote:

– “WAgile, as [we] all know, stands for “Waterfall-Agile”, and is the pinnacle of dysfunctional development methodologies. Yes, folks: literally thousands of projects have failed the WAgile way”

Jason Gorman

He wrote this in 2008 around the time the term was coined. And despite the over-the-top outrage, I can see where he’s coming from. A lot of people misuse the term Agile. I’ve seen a lot of organisations class a project as Agile because they have a daily stand-up meeting, for example.

What is a hybrid?

A Waterfall or linear project follows the key stages in sequence: discovering, defining, building, and then testing and deploying at the end.

What I’ve seen often ran in organisations, under the name of Agile, is the following:

Just by splitting the development into two-week sprints and doing a daily catch up, does not mean you’re ‘Agile’. If you are following this linear process of discovering, defining upfront, then sequentially building and testing – this is still a linear project. All requirements are defined at the beginning, and this is what you are following within each build phase.

In a truly Agile project, the process will look more like this with each phase contained within the iterations:

With the struggles around implementing Agile, a seamless move over to Agile delivery is very difficult for a lot of organisations. Having that much client involvement, a general lack of understanding, questioning how UX fits in, perhaps a historical relationship with a client. There are lots of factors which makes it tricky to implement.
What is easier to implement is a gradual move over to adopting Agile principles and Scrum process, for example, namely using a hybrid. I know this can be quite controversial to say (and might anger those Agile purists) but to me, a hybrid seems to me a more realistic solution, at least while the transition progresses.

So this is how the flow could look:

How to implement a hybrid

So you work at an organisation that follows the more linear ways of working, but you think projects would benefit from an Agile approach. How do you help your organisation move towards this through a more hybrid solution?

“Yes, I said let’s use a hybrid”

1. Client involvement

Ideal: An empowered, available Product Owner
A core problem tends to be involving the client or stakeholder as Product Owner. They need to be heavily involved, and you might find this difficult when they’re involved in other projects. They are often not used to this either. They often expect to give you the work, and then hear from you on a status report how it’s going once a week.

Hybrid: Help bridge the gap between stakeholder and team
On a project I worked on, we helped bridge that gap. We acted as the Product Owner but got the client to agree to be involved in the core meetings (such as the reviews and planning), and made sure they were involved in setting and defining requirements at each stage.

2. Team collaboration

Ideal: A cross-functional, dedicated team
Getting a cross-functional team who are dedicated to the project can be a struggle. This can be especially true in smaller organisations where there are a lot of projects going on, and team members are expected to work between more than one project.

Hybrid: Team members keep involved throughout
Make sure that at the very least, team members are working together and collaborating. If you can’t book project members full time across each sprint, try and make sure they are included in regular discussions with the development team, the daily stand ups, the planning and reviews. A team that talks to each other can help the project succeed.

3. Continuous planning

Ideal: Planning requirements per sprint
Changing the client or stakeholder’s way of thinking is also crucial so that requirements aren’t set at the beginning of the project in a strict functionality specification, which you’re tied to through the course of a project. But clients and stakeholders are often scared of this. They want to know what they are getting when they sign off the budget.

Hybrid: Some upfront shaping, but leave detailed planning to the sprint
Look at whether you can do some upfront loose shaping of the project requirements, but leave the detailed planning to the sprints. Don’t pin down all the deliverables in the first instance, so that you can react to change along the way. Coach the client to get buy-in on this planning approach. Outline the positives of being responsive to change throughout the project.

4. Designing what is needed

Ideal: Design within each sprint
How does design fit in? The ideal would be to run this in each sprint, so designing only what is necessary for each iteration of work.

Hybrid: Design at the last responsible moment
Design should be done at the last responsible moment. Instead of a whole bunch of upfront design defining requirements early, design what you need to as late as you can. This will avoid designing unnecessary items that aren’t even used in the end. This again goes back to collaboration, and getting designers, developers and indeed all involved in the project, working together on a sprint or a time-boxed phase of work.

Helping the transition succeed

Get help

Use training, mentors, and coaching to help explain the benefits of a different approach. This goes for you, your team and importantly, your client.

Get management buy in

No process is going to change without management buy-in. Make sure you set out the benefits, and the approach to adoption. If you can present a definite plan of how clients and stakeholders will be brought on board, this will greatly help transition.

Get real

Lastly, if things aren’t working, don’t make excuses. Agile is iterative. Your implementation of the process should be too. Regular reviews of how it is going mean issues can be picked up quicker and resolved.

Instead of making excuses about how it’s going, ‘oh we’re implementing a new process it’s bound to have problems’, present plans of action of how to fix and move forward. If you fail, fail fast and move on.

Common faults to look out for

When defining your own hybrid process, there are some common faults to look out for.

No process or structure

Instead of following something, you go the complete opposite and have nothing concrete defined at all. The project becomes a mess because there is no way of working at all.

People on the team doing different things

If your team members don’t really know how they should be working, they might start going off on a tangent, and not focusing on what they should be doing .

Processes for the sake of processes

This is really important: don’t put in place processes for the sake of processes. Don’t add unnecessary documentation just because. Keep the process as streamlined as possible whichever methodology you’re following.

One size fits all approach

Beware the one size fits all approach: the idea that because something was successful once, it’s going to work for everything. Make sure you are thinking about every project as it’s own entity. There needs to be a cohesion in processes across an organisation, however each project is different in their own right and needs to be treated as such.

4. The final question: does a methodology guarantee project success?

A lot of people are so obsessed with particular methodologies, they think if they use one of them it’s going to mean the project is automatically successful. I believe however, that project success from a PM perspective is based on skills, the so-called ‘hard’ and ‘soft’ skills. I don’t really like these terms, so use ‘practical’ and ‘personal’. Practical skills are the hard skills, the concrete, learned things. Personal are the soft skills, more ingrained and coming from how you are rather than what you do. I’m going to break them down a little further.


  • Communication – Enabling collaboration and transparency
  • Leadership – Motivation and guidance
  • Flexibility – Allowing and responding to change
  • Problem solver – Finding solutions


  • Time and cost estimation
  • Technical knowledge
  • Risk assessment
  • Project process

And there it is, in the last bullet there – the methodology, the framework or processes followed on the project. So it really is only part of the whole set of things which make up successful project management and successful projects.

In fact, I was talking to my head of HR when I wrote my original talk on this topic. I was telling her about this split as we were working on putting in place a mentoring programme for our graduate trainees for project management. She said that hiring people who display the personal skills is much more important than those who display the practical skills, especially for people entering the industry. Generally people can learn the practical skills and how to implement them on projects, as long as they display a desire to learn. But personal skills are more ingrained and central to success as a PM.

The takeaway: Focus on what really matters – communication, leadership, flexibility, and problem solving.

What do you think?

So what will it be? Agile vs Waterfall, or Wagile? Could a hybrid methodology be a good alternative when transitioning to agile? What are your experiences and successes (or failures) running waterfall, agile, or wagile projects? Share your thoughts below.

Leave a comment:

Your email address will not be published. Required fields are marked *