Scrum truly does end up being "Waterfall" most of the time, in my experience. I think this is largely because teams or management inevitably get bored with projects and end up shifting priorities regardless.
From what I've seen, projects almost always start out in a requirements/analysis phase because management, stakeholders, etc., need the reassurance. I've yet to see any public-facing project of meaningful size start out releasing actual MVPs as opposed to "big bang" releases.
Design often happens first because engineers don't want to(and sometimes can't) begin coding away and then receive designs that are either counter to their existing work or are unworkable; management usually sides with design because, well, it looks cool.
Engineers eventually get coding, but non-automated testing doesn't really occur until later because it can be impractical to have people testing unfinished software. Then there's alpha testing, users break the software, engineers fix bugs, A/B testing of different versions of features, then beta testing, where users again break the software and the engineers fix more bugs.
The project continues to drag on because the first 80% of a project is always the easiest part, and management is always hesitant to release "unfinished" software.
Inevitably, there's a big bang release, by which point management has already gotten bored and has dreamt up other "big ideas" for the team to focus on, at which point the project is, for all intents and purposes, placed into maintenance limbo where bugs are fixed, junior developers place their awful code, and a new "feature" is added now and then to satisfy the marketing department.
Senior developers rationalize the waterfall-like nature of the project, so they opt for "continuous integration", but all that ends up translating to is maintenance limbo without versioning.
The actual next version of the software doesn't get built until after most if not all the original team left, and the original software became "legacy" enough that bugs keep popping up and the new engineers don't want to touch the old code. Management eventually gives in, for better or worse.
Am I wrong? This is what I've seen happen to the vast majority of software projects, all under companies that were either Scrum, Agile, or pretend "Agile". Maybe I've just had bad luck.
I wish more teams could pick and choose what methodologies to use for their purposes, rather than buy into MLM garbage.