5 ms·
> Should we go back to Waterfall? Waterfall seems like a strawman to me. Has the tech industry ever used it? The first reference I could find for it was back i
by chris11 4y ago
> Should we go back to Waterfall?
Waterfall seems like a strawman to me. Has the tech industry ever used it? The first reference I could find for it was back in the 70s as what not to do. I don't think waterfall should be used as a defense to scrum.
As for alternatives, you can start with giving engineering teams autonomy and ownership of their work. Gergely Orosz has a good article on project management in tech.
http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...
https://newsletter.pragmaticengineer.com/p/project-management-in-tech https://newsletter.pragmaticengineer.com/p/project-managemen...
- TameAntelope 4y agoEvery time you have a "Gather Requirements/"Design"/"Develop"/"Test"/"Deploy" set of stages, you're using waterfall. Note the absence of "collect feedback from customers". Waterfall is in no way a "strawman", it's very real, and many shops who claim to be "agile" are still using it today, not to mention the near-ubiquity of its presence in software shops for years prior to agile taking over.
- igouy 4y agoAs-if "collect feedback from customers" somehow couldn't be in "Gather Requirements" and "Design" and "Test" and "Deploy".
- TameAntelope 4y agoIt needs to be part of all of them, but you can't do it meaningfully in any one of those steps, because you don't have a working product to actually show the customer until the end.
- igouy 4y agoAs-if! '… we need to accept the possibility that we will iterate during the development, perhaps within a given phase (eg reworking a design until it seems that it will give the required performance), or from one phase back to another (eg to correct a faulty design decision that, during construction, is exposed by a failure to be able to implement it). The biggest iteration is the one where we complete the development and, when we see what we have produced, we decide we need to start again and redefine the user requirements in the light of what we have produced. Such iterations happen in the real world and we wanted to accept this fact and put it in our model. Royce first formulated this idea in what he labelled the waterfall model … page 31 'The "oldest" process model is the waterfall model … This shows a similar progression from inception, through definition, the various stages of design, code, unit testing and integration to final acceptance. The fact that that progression is never smooth and monotonic is acknowledged by drawing little backward arrows suggesting iteration." page 39 1990 Strategies for Software Engineering: The Management of Risk and Quality https://www.google.com/books/edition/Strategies_for_Software_Engineering/Wd8mAAAAMAAJ?hl=en&gbpv=1&bsq=waterfall https://www.google.com/books/edition/Strategies_for_Software...
- TameAntelope 4y ago...what? Nothing here talks about getting customer feedback on a finished product rapidly.
- igouy 4y agoBe real.
- TameAntelope 4y agoI assure you I'm entirely "real". What's not real is the notion that waterfall didn't ever exist. It did. That's objective fact. It was prevalent across the industry, that's also objective fact.
- igouy 4y agoAs before, "… we will iterate during the development … Royce first formulated this idea in what he labelled the waterfall model …" page 31. Seems like you deny that waterfall model.
- cuddlybacon 4y ago> Waterfall seems like a strawman to me. Waterfall definitely existed. I've been at places that worked that way. I think Agile (and corruptions of) have replaced waterfall well enough that people no longer think it used to exist.