Does Waterfall Still Have Its Place?


#1

Are there any situations where someone would consider a waterfall approach?

I’ll give a blunt example: A potential client wants a fixed amount of features by a very hard deadline. I can’t really explain why, but I would really like to get all of the requirements (and wireframes) done up front so I know if it’s even possible to build and meet the deadline. I would then probably iterate coding and testing each piece, but I feel the heavy requirement gathering up front is needed.

So again, does waterfall and/or its concepts still have any place in an agile world?


#2

If the work needed is predictable–both tasks to perform and length of time–plus risks are easy to plan for through the use of historical data, I see no reason why a phased workstream isn’t a viable option.

The considerations would need to be true for each phase, mind you.

z


#3

Is it a question of features they ‘want’ or ‘need’?

What’s their timescale? Weeks, months, years?

Can it really not be broken into several products/releases?

Consider the time and effort required to do the whole thing up front, and to what level of confidence. Confidence increases with knowledge and detail. Both come at a cost of effort and time.

I would consider Story Mapping their concept and make them do the hard thinking, not you. The result of that is they get more confidence whilst also seeing a road map of what lies ahead, without the need to commit to it now.

They can benefit from early release and return on investment. Plus the initial investment per release is lower and less risky. They can take stock with each iteration, and so on…

So in brief, I can’t see a case for Waterfall, other than to open yourself and your client to increased uncertainty and opportunity for failure.


#4

Dogmatism is the only thing that has no place, imo.

I encourage pragmatism. If waterfall works, use it.

There is nothing in the Manifesto that says otherwise.

And I will argue that one can be using waterfall methodology and still be “agile”

Four values, 12 principles.

Let the flames begin…


#5

This is an excellent response, Andy. Pragmatism is exactly what’s needed. My response says more a reflection on my experience with dogmatic use of Waterfall, ironically, dressed up as agile. The blunt example given fits with a raw experience.

I could have left the last three paragraphs out and maybe seemed less dogmatic myself :wink:


#6

I agree with @andycleff; use what works to help you succeed. Waterfall does have it’s shortcomings but it does have a place in the delivery ecosystem. While it’s huge and overly wordy there are some good learnings in the PMBOK and as professionals we do ourselves a disservice to blindly throw it and it’s methodologies away.

In the end, it all comes down to delivery. If you deliver and the client/customer/etc. is happy then nobody cares how you did it.


#7

I never circled back on my reply - but thanks for the insights @zachbonaker @RabAusten @andycleff @JayHorsecow ! :+1:


#8

These are all great responses. I think @RabAusten and @andycleff make great points. If knowledge and confidence increase with time invested then waterfall may make sense. Software that has to be perfect the day it’s released because it can’t be updated, like a pacemaker or satellite or Mars rover, might benefit from the waterfall method. In these cases, being pragmatic is all that matters.


#9

AGREE with @andycleff . Waterfall works, Agile works too!

As mentioned above: anything that is hard date driven. Additionally, things that are deliverables based contract driven.

waterfall use case: Event planning with Marketing, Advertising and Creative teams. I did a few product launches at CES driven mostly by Product Marketing Teams. They cater food, have banners delivered, workers setting up lighting, DJs, Artist riders. These pieces must come together for the Gig to go live!


#10

I’m not afraid to admit that one of the most successful projects I’ve been a part of (and most satisfying) was a waterfall project. This was before i’d even heard of agile.

The business case was crystal clear, the technical approach did not require much if any innovation, and the feature set was pretty minimal. It was a 3 person team and the project took about 2-3 months. It’s all about the context of the project.