https://upload.wikimedia.org/wikipedia/en/6/65/Screengrab_-_...
One way I've weaned people off waterfall approaches is just to tell them yes, of course that's what we're doing, but to make it extra safe, we'll produce software early and often so you can see progress. Then eventually I'll slip in getting users to try it, just for "testing". And then getting it deployed early, for more "testing". The smart ones get engaged in this process, using it to making things better than the initial conceptions. They may produce waterfall documents for a while, especially if they need to pacify higher ups. But often they'll just forget. I think them GANTT charts and the like were always a ritual to get them feelings of control, and they stop doing that work once they have actual control.
So I suspect a lot of the nominal waterfall projects of yore were similarly made to work by developers just doing the right thing in quiet ways while saying, "Oh, that's 90% complete for sure. Mark it on your chart!"
I was a kid who didn't make grammar/spelling mistakes. I'd just write up the paper, insert two or three errors, submit it, and then a couple days later submit the original version.
Its funny because that would the inverse of the current situation where exec proclaims their company is agile to external observers and potential hires, but the de facto regime could be anything
I've never felt so old in my life
I'm on a project now trying to manage external customer cutovers and integrations using JIRA and its a dumpster fire.
A proper project plan with deadlines, lead times, resources etc would solve 99% of the problems.
Its just non stop crisis "oh we forgot to get get change submitted on time" - "oh this customer can't migrate until date x" - "oh this test environment is down for scheduled rebuild on days xyz" - all can easily be tracked to automatically calculate timelines.
Agile is fine at a macro level, but it needs to feed into a better system for real world dependencies and deadlines.