Would you share how "old school" waterfall differs to what people are currently doing?
I'm imagining UML diagrams, control flow charts for the old days vs UI mock-ups and Jira tickets today, but not quite sure how far exactly today's waterfall projects go in defining the work to be done.
I think people compare perfect agile with dysfunctional waterfall - i.e. Project Manager creates a gantt chart and screams louder and louder at devs as reality deviates from the plan he prepared on Day 0 of the project.
Burn-down charts, jiras, gantt charts are really just plans of how much work is left, what will it cost, and roughly when will we finish.
In the old days, execs would decide what to build. They would decide amongst themselves, perhaps talking to the customer a bit (if there was one).
Next, the analysts would begin the requirements analysis. They would talk to their customers to ask things like "What would you like to see feature X do?", write up ERDs and DFDs, flowcharts and such, and then come up with a huge document listing all of the requirements of the software. At no point in this phase would an engineer or even the prospective user of the software be consulted.
As an aside, UML wasn't really a thing yet, and mock-ups were rare. Information would just be crammed into an available space on the screen or perforated printout.
Next, the architects come together to decide upon technologies and the overall shape of the software. This was done in a vacuum, with no input other than the requirements document.
Next, the systems guys would decide how the rubber hits the road, injecting their requirements for the system this will run on.
Next, the programmers would implement what the previous guys had output in their documents.
Once all that was done, the testers would come in, use the software and compare to the requirements.
Then the software would be shipped to the customer.
Note that nobody lower would communicate directly with anyone higher in the waterfall.
If at any point in this process something was found to be horribly off, you would decide whether to conceal it to stay on target, or to raise an issue. Once an issue is raised, you go back up the waterfall until it reaches the person responsible for that thing, and then the documentation process adjusts as it trickles down the waterfall (this usually takes a couple of weeks) before you continue where you left off.
The main issue is the lack of communication. Those higher up rarely have any interaction with those lower down. The company has very little contact with the customer, other than to ask questions and then write requirements full of biases and assumptions. There's high pressure to stay the course and not change when the product doesn't satisfy because that would lose money. This is why the customer was asked to sign off on each phase of the waterfall (containing thousands of pages he didn't understand).
And the thing is, this worked (in the sense that software houses made money, not that customers got anything wonderful) because everybody did it.
The changes since then are not only agility (although those are huge wins). There's also MUCH better communication - keeping everyone in the loop (including the customer), observation-based analysis (watching the user actually do things in their day-to-day as an input to requirements, and a discussion springboard for innovation), a/b testing, automated testing, continuous deployment, ticketing systems, UX, etc. All the good stuff that we just take for granted now.
The "agile" manifesto was a good catalyst to modernize software engineering, but it's not an endpoint, and rigid adherence to an ideology is what caused all the mess in the first place.
I work in Ag-Tech. Hire-ups are always so confused on why nothing is "working out" the way they intended and THEN surprised to hear we are doing waterfall, yet, our process is literally bullet for bullet what you posted.
Except as others stated, we use Jira and have a Kan-Ban board...
We were doing this very long drawn out milestones and now have switched to releases, which eases it up a bit, but my god it is just terrible.
Going off of ideas, designs, and requirements made four years ago just doesn't seem to work out. So weird!
I'm imagining UML diagrams, control flow charts for the old days vs UI mock-ups and Jira tickets today, but not quite sure how far exactly today's waterfall projects go in defining the work to be done.