If you incorporated feedback along the way, then you did not do Waterfall. Which is good, because Waterfall is insane and brainless. I've witnessed a 10-figure Waterfall mistake (I was brought in near the tail end, it was years late, over budget, and delivered the wrong thing). If they'd incorporated feedback along the way they wouldn't have fucked up so badly.
This is what I mean by only listening to polemical takes on waterfall. Do you think that anyone advocating for waterfall would actually claim that you never incorporate feedback? That's why you have prototype phases
Yes. I've witnessed it several times. Some people are truly moronic. But there's no point in arguing for Waterfall if you actually use your brain and don't do Waterfall.
EDIT: You didn't do Waterfall, just to be clear. You used prototypes and feedback along the way which Waterfall explicitly excludes. So why do you insist you participated in Waterfall projects?
In order to advocate for Waterfall instead of any Agile methodology during the last decade or so one has to be overwhelmingly blindfolded by the religion. And these kind of folk tend to be quite strict in their faith. As in: "we had enough time to discuss things and think it through and now it's time to stick to the decisions we made".
And yes, I have witnesses just that quite a few times.
I know a software company that strictly uses classic Waterfall even to this day. A minor feature that should typically iterate in production for like 3 or 4 times and be done takes them about a year to implement and still never deliver what the customer wanted. And I'm not exaggerating. (The company prints free money from another line of business).
I've seen supposedly "agile" companies (in reality: Cargo cult agile, jira-driven micromanagement and long plans. Much waterfall) that failed to incorporate feedback. So yes, it could be.
do you think its possible that we all said 'yep, our planning process is faultless, all we have to do is wait 18 months and it'll come out exactly as we conceived'. how blind we all must have been
I've seen it more than once, but I'm not saying it's common. But people saying "We do Waterfall" are saying "We're brainless, insane, or only working on trivial systems (in which case any process would work)." Once you start incorporating feedback loops, you're not doing Waterfall.
Sadly, though, it is in fact a real thing. I've seen several projects fail spectacularly. One of the best failures was "only" a year late. They also learned not to go 6 months into development without integration (believing their plan was sound) and skipping testing for that entire time. It was either brainless or insane, and it took a lot of threats from customers for the PM to finally learn that, maybe, a plan made a year or more out and committed to wholeheartedly is stupid.
> do you think its possible that we all said 'yep, our planning process is faultless, all we have to do is wait 18 months and it'll come out exactly as we conceived'.
Yes. I know from direct experience.
> how blind we all must have been
Yep. The industry really was that dumb. Much of it still is.
There's a long list of things we do by default today that I had to fight tooth and nail for in 2012, and twice as many in 2002.
On the one hand I try to remind myself of this when I start feeling like nothing is going right on the project. We are less dumb, and I'm applying the same(?) energy to things that matter less.
On the other hand, telling people for 15 years that we should be doing X before people start reliably doing it is fucking exhausting. If I thought about it, I probably avoid reading about things that are too 'new' today because I'll only get to use them in my dreams.
Sometimes places that use a lot of contracting start doing this brand of waterfall in house as well.
People in startup culture have never actually seen what waterfall can be like. Waterfall as first 'proposed' was meant to be a strawman used to show how not to do things and some managers thought it sounded pretty good.
No one said, "Lets do waterfall". What happened was people were just working, with weekly meetings which didn't pry too hard into what engineers did. Then there was a massive fuck-up. Something took too long, was too buggy, too slow, and some customer was pissed and left.
Then the finger pointing happened.
Ops said, "Our servers aren't slow or missconfigured, QA should have done load tests before approving it. "
QA said, "The code we got was shit and buggy, it was all we could do to get all the breaking changes found before ship date!"
Devs said, "Product kept changing the design!"
Product said, "Sales sold something ill-defined and over promised!"
Sales said, "Everything we do isn't sellable! We needed these specs to compete! The reason the customers left was that Devs took too long to develop! Product couldn't write requirements! QA didn't test!".
So a solution was drawn. Product would get sales to get their sales-engineers to pre-qualify opportunities and sign off on a pre-qualification spec. Product would accept that, and once accepting it they would own it.
Product would take the Pre-Qualification doc, and produce a detailed requirements doc. Including timing estimates for interactions. They would present that to eng, and eng would sign off on it. Once they sign off, they wouldn't allow any changes to it. Product and Eng would need to complete a change request for every change to the requirements.
Eng would take the requirements and produce a detailed design doc. Then they would setup a time estimate that they would be held to. They would produce a machine spec sheet they would give to Ops to get the hardware ready. Once they complete eng, they would present the completed code to QA.
QA would have a test plan based on requirements only after they would accept the code from Devs. Once QA accepted it, they had a timeline to complete testing. When they have reached a low bug count, (Having a high number of bugs initially should have been caught by the pre-QA Test plan), they would sign off on the quality doc and hand code to Ops.
Ops would deploy the code, if the product didn't perform, it would be assumed at this point its the hardware config and thus ops issue.
All of this would be designed that the team wouldn't be "at fault" if they got the next team to accept the code, and every team would make sure everything was perfect before they accepted it. To keep deadlines, minimum times for doc creation and acceptance would be created. The only variable would be dev/qa time.
The process would be fool-proof, guaranteed that nothing could be produced that would cause another fuckup. Typically the first major project to go through this process would be the last. Either the company died before it would be completed, or the process destroyed itself in such a massive flame/backstabbing fest that even the CEO would get fired.
