Waterfall Done Well

Off the back of some conversation on Twitter, I wanted to start a longer form discussion (Twitter isn’t a great medium for that!)

The initial tweet I put out was:

Which led to some conversation about how waterfall done well can work really well.

I was wondering if any of you have experienced situations of waterfall done well? Or conversely, with the benefit of hindsight, what would you go back and change about a waterfall project that you worked on?

1 Like

I have experience with Waterfall projects that ended well (actually only one) and others that didn’t finish as expected. Same applies for projects with methodologies closer to agile principles.

Talking about the successful waterfall one, I think it worked because we had a customer that understood how software delivery works. Even in a waterfall process, we had direct and constant communication, they were open to changes and suggestions from development team, etc. Also, a good team of developers and testers where in place. We were able to deliver a product that fits on the client necessities.

That said, with all those condiments, having a good team of product, management, developers and testers, I’m pretty sure that following agile methodologies, the product we delivered would have been better and, most important, cheaper. We would be able to identify pieces that didn’t fit as expected on the final product, and stop working on them at the beginning, instead of dedicating the effort to conclude them to later discard or re-do them.

2 Likes

I think this is the part I’ve struggled with the most when on waterfall projects but then I’m not sure that I’ve been on waterfall projects done well :sweat_smile:

1 Like