The Myth of the 'Waterfall' SDLC (2019)

PRD -> design doc -> code -> launch -> promotion.

Of course, it's broken down and full of a mess (like a real waterfall) at most stages.

I feel like in a way it was a disservice to my career having a decade and a bit of work in smaller companies (where we often shipped quicker and with a less dysfunctional process) before coming to Google. Because the people around me seem to find the way things are... all quite fine and dandy while I just stare in cynical disaste.

The new team I'm on seems better, though.

If you tried to collect the requirements up-front, the only thing you would get would be to either stall the project before it starts (what could be a good thing), or to do the exact same process, but only after a months-log delay that created a bunch of stuff you would simply throw away.

TBF, in the defense and defense contracting world that is not an unusual situation. It's a terrible situation, but it's not unusual. I've seen multimillion and multibillion dollar mistakes caused by this repeatedly.

It's improving, but SAFe is not the answer. If it were, the F-35 may not have been such a clusterfuck. SAFe is overly prescriptive and inflexible, it's a way to make managers happy but does little to actually improve the situation.

It depends, the idea of working in short sprints with deliverables at the end of it is that often you do not know what you need and the best way of finding out is by trying out and talking to the customer.

The place I'm currently working at is agile on paper but 90% of the work is just implementing external requirements we have no say in. Needless to say, not analysing the problem up front and not designing the general architecture up front leads to building roadblocks later on that prevent getting work done.

To stay with your metaphor: Sometimes you have to eat shit (because of legal requirements, etc.). Planning ahead is very useful in those situations for not choking on the shit.

https://acqnotes.com/acqnote/acquisitions/milestone-overview

This is literally the way the US DoD has done acquisition for decades. In the early phases there are often (but not always) multiple R&D efforts which are evaluated later (in the aircraft world think about the various X aircraft that compete to become the next fighter). But once it's selected, it's very waterfall-esque from within the context of the program office which encourages (but does not mandate) a waterfall approach from whoever is doing the work as well. They do periodic check-ins, but they're basically waiting for the entire thing to be produced before it can be evaluated properly. The checkins are just smaller milestones, again not necessarily increments which could standalone if the project were to stop there.

And yes, US DoD does big bang testing at the end. They have test organizations which receive software/hardware systems (cyber-physical systems is a common phrasing for them) and evaluate them at the end of the development process. Ideally, of course, the development team is also doing testing. But even then, in software, they tend to do scattershot testing during development with one big bang test run at the end.