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.

At that time though I really didn’t have enough experience with the use of Agile to make a really informed decision as to why I felt one was better than the other, but having recently worked on several more Agile projects I can now say that I feel I have a better understanding of which I prefer and why.  So, here are my thoughts.

Agile

The Agile approach is to be fluid. You don’t start with formally documented business requirements, these are developed as ‘stories’ with the development work taking a fluid approach so that changes and adaptations can be made as development progresses.

What’s wrong with this approach in my opinion?

  • Business requirements could be missed, until well into the project.  Because they haven’t been all formally captured at the start, there is no way of tracking that things are all being built and captured within the stories.  Case in point, we were working on documenting the TO BE process maps so that the business could fully see and understand the changes that would take place for the staff, and during this process at one process step it was identified that this step hadn’t yet been captured in stories, within the project.  Not sure what would have happened had we not been formally documenting the process.
  • Scope lock down isn’t quite what I’m used to.  Whilst I’ve seen that work is undertaken with rigor 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 lock down.  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.

 

Waterfall

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:

  • Business requirements are clearly defined and documented at the start of the project.  Mandatory or Must have items are called out, with Nice to have set aside and even relegated to Phase 2 of the project.
  • Scope is locked down based on the documented requirements and it is very clear and easy at any point in the project delivery cycle to determine if something is or isn’t in scope, due to tracking it back to your requirements.
  • Resource planning is more predictable, because of the phasing and again solid understanding of exactly what needs to be built and how.  Of course here I am 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.  It’s not to say that there can be problems here, but I have seen them be more manageable.
  • Project teams don’t tend to get as burnt out because there are clearly defined phases, with defined boundaries around what is and isn’t to be developed.  I have managed a cradle to grave development project and it came in ahead of time, in scope and just under budget.  No burn out, no over time running, no issue of team burn out.

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

Karen

 

Written by Karen Munro

*Photo courtesy of James Barker at Freedigitalphotos.net