Agile vs Waterfall when to use

There is debate from both camps of the project delivery method space – Agile vs waterfall when to use.

In my earlier post ‘Agile vs Waterfall methods‘ I described my understanding of both the Agile and Waterfall methods and which one I preferred.

I’ve had an email from ‘Adam’ who works in mining with some great comments that I would like to discuss.

He expressed that “Agile is not the definitive answer, it just lowers the risk, or accelerates the impending failure.

I agree in part with this statement.  I don’t agree that agile lowers the risk necessarily.  I have recently watched a project be far more costly than originally forecast using the Agile method.  There was a high risk associated with the project being finalized because there were not necessarily funds available to ‘fix’ the issues that were identified at the stage of development where the funds ran out. It certainly accelerated the impending failure of the project at that time.

Whilst the business decided to find the funds needed to continue the project and bring the development to a state that they could wear as a marketable product, this meant additional time and funding that was out of scope originally.  Would this have been different had a waterfall approach been used?  My opinion is that yes it would have been, as the business would have developed the requirements up front and therefore not missed many of the key items that were later rushed in, or left out of the agile delivery.

Did using the agile approach mean that the development was more fluid and changes could be made to the product as it was being developed, certainly and this was one good thing for using that method.


Adam also said “A first step in all project management methodologies is to decide what kind of project it is and to look at the lessons learned.”

How many project teams or project managers actually do this?  I don’t care which methodology that is being used I want to suggest that lessons learned are not used enough in any project space.  I have seen many Project Management Offices (PMO’s) capture lessons learned in databases and then that is the end of it.

Would I like to see them used more to determine the sort of approach to project delivery?  Of course, how valuable it would be to decide that a particular project is suited to the use of either the waterfall or agile approach based on previous lessons learned.

What a challenge for PMO’s/project managers/project teams.  I would suggest that there is not one project team that has gone to an organisations lessons learned log during project delivery when they are coming up against problems and yet how valuable might this be if they did.


Adam asked the question “If it was 1965 and you were given the project of putting a man on the moon and you used waterfall approach, how would it pan out?

Great question.  I love thinking about the waterfall approach as the equivalent of pieces of a puzzle that are scoped out, shaped and then fitted together.  For me this question would be answered in regards to compartmentalizing the work that needed to be carried out into phases. One phase might be the design/production/testing of the space shuttle.  Another phase might be the recruitment/training etc of the astronauts.  Another phase might involve the technology aspects of tracking the shuttle and the astronauts whilst they are in space.  I can see that each of these pieces could and would be worked on as individual pieces which would then all interconnect.  Is this strict waterfall, probably not, but it is more like waterfall than agile from my perspective.  Is there some fluidity required in the approach, yes certainly, especially when it is done for the very first time.  So, in this instance a strict waterfall approach might not be the best.  I don’t see that an agile approach would necessarily be the best either, so maybe a more hybrid approach would be better.  What might that look like, I’m not completely sure, but will ponder it.

Maybe the idea is that there shouldn’t be strict methodologies for these different sorts of projects.  What would work is the blend of both, where flexibility is added to a structure that sees things called out, detailed, scoped so that budgets and constrains are adhered to.


Adam also put forward this as an explanation for the use of each method:

Low risk, Low complexity, Commodity = Waterfall
High risk, High complexity, Development = Agile.”

What are your views on this?



Written by Karen Munro