Agile vs Waterfall methods

I’ve had an open mind about the Agile method of project delivery until recently. This post is going to compare my views on Agile vs Waterfall project delivery methods.

Previously I’ve been involved as a Project Manager working with both methods and my preferred method was Waterfall.

Here are my thoughts why.


The Agile approach is about being fluid. You don’t start with formally documented business requirements. These ‘requirements’ are developed as ‘stories’ and the development work takes a more fluid approach. This allows changes and adaptations to be made as development progresses.

What’s wrong with this approach in my opinion?

Business requirements could be missed, until well into the project.

A full set of ‘requirements’ are not captured, in the formal sense at the start of the project. This makes it difficult to track if everything needed is being built.

We were documenting the TO-BE process maps for the business on an agile development project. During this process, it was identified that a step hadn’t yet been captured in stories, within the project.  Not sure what would have happened had we not highlighted this through formally documenting the process.

Scope lockdown isn’t quite what I’m used to.

With agile work is undertaken with rigour around what can and can’t be done. I don’t get the strong sense that there is what I would define as real scope lockdown though.

I say this because stories continue to be added to the project development, which has extended the project timelines. I’m going to hark back to my first point, in that without the defined business requirements to measure and monitor against, up front, how can you be sure that there is no scope creep going on?

It’s harder to resource plan.

If you take my first point, yet again, then it becomes evident that whilst initially you have undertaken your resource planning, there is inevitable need to rework the original estimates, because of stories being added and built onto.

The project team can get burnt out.

Maybe it is just the nature of the projects that I am working on, but they appear to be going for longer than originally anticipated, and this is causing project team member burn out.  If you imagine staff set for a three month hard and fast slog to get the project over the line, and all of a sudden they now have a further four or six weeks added to that during which they are expected to keep up the same level of intensity in order to deliver.  It’s hard and can cause burn out.  Not good for the individual, let alone the team.


The waterfall approach of course centres around having predefined and documented business requirements (in the best cases, and yes I hear you say that that doesn’t always happen).  These requirements are the basis for the phasing of the project development and delivery work and form the core determination of what is and isn’t in scope.

So, based on the things that I view as ‘wrong’ with the Agile approach, if you look at all of the items listed they are not applicable with the use of the waterfall approach because:

Documented Business Requirements are provided at the start of the project

Business Requirements are documented as part of the initiation phase of a project.

Mandatory or must-have items are called out. Nice to have’s are documented, but set aside and relegated to Phase 2 of the project.

With waterfall, scope is more locked down

Based on the documented requirements it is very clear and easy at any point in the project delivery cycle to determine if something is or isn’t in scope.

Resource planning is more predictable

With waterfall, resource planning is more predictable due to the phasing and requirements development upfront.  This is assuming that your Project Manager/Technical Lead has a good handle on resourcing and knows what is going to be required from a development perspective.  Problems, when they arise seem more manageable.

Project teams don’t tend to get as burnt out

Clearly defined phases and boundaries create less stress for team members.  I have managed a cradle to grave development project and it came in ahead of time, in scope and just under budget.  No burnout, no overtime running, no issue of team burn out.

Based on my experience, I’d prefer the waterfall method every time.


*Photo courtesy of James Barker at