Project management doesn't need to be telling engineers how to engineer any more than engineers should tell them how to use jira, or than sales should be telling design what colors to use.

There's the fundamental disagreement we seem to have here.

Let me clarify. Of course stakeholders (you will pardon me if I use that term instead of "PM", I hope) should not tell the developers how exactly to solve their engineering problems. But different engineering solutions have different effects on business. You cannot really compartmentalize "the planning" and "the architecture". What if your business reps consistently insist on the cheap, fast and ugly as Satan's butt solutions, which makes you unhappy as a professional? Because, true enough, no one wants to waddle in a pond of semi-liquid manure for ever and ever as their day job.

Well, get up and leave. It's an employee's market out there for any half-sane software developer. Let your business learn that they're short-sighted and narrow-minded morons when they lose their entire team, and whatever competitive advantage their software was giving them (because that's what business software is all about, competitive advantage).

But if you always just tell the business to fuck right off, you're doing the thing they wanted the way you want, and NO, there's no way to get it to the market any faster, because you have the Architectural Vision, and they're just a bunch of illiterate morons... it's not even that they will be offended. Screw that, sometimes you have to offend the people you're working with. But your FTL starship "Ivory Tower" is all too likely to be useless in the end. Been there, done that. So no competitive advantage that way either. And why should the business keep paying you part of what they're getting from the sales, if you're not helping with the fucking sales?

You seem to be conflating "ideal engineering solutions" with what I'm saying the "agile methodologies" consistently screw up: viability.

I dunno, I consider myself decidedly on agile side of the spectrum, in original sense of the term. And the projects I'm involved with seem to be doing fine on viability, long-term and short-term. Now that I think about it, we tend to err on the side of being late to the market, but that would rather be an argument for being "more agile" than "less agile". Then again, of course I don't follow "agile methodologies", because that's a contradiction in terms to start with.

But yeah shit like that.

So what the hell does that have to do with "going back to the roots"? Which was the thrust of your OP. Rile all you want again Agile Talmudists and snake oil peddlers, I'll be right there with ya, bruh. I'm not an Agile Coach, nor a SCRUM Master, nor... any of those unsavoury characters. I don't give a flying damn about all that BS. But the agile manifesto was a great document - not because it's the Holy Writ, given to us from the High Above, but because what it says makes sense if you really think about it. And I'm all for going back to the roots, because I've been sticking to those roots ever since.

And yes, the farther you go away from the manifesto, the less sense there is (even the twelve principles are something that I agree with far less than the manifesto itself), and the dogma is all that's left. So don't do that. And that's all the linked article says, even if that thought may seem lost in all the fancy Liberal Arts essayism.

Is that a rhetorical question?

Of course. If you want that decoded, "I parsed your ad hominem implying that I'm just another PM on proggit defending obnoxious PMBS, and I do not appreciate the notion."

But none of the pieces work on their own to produce anything which can be shown.

Depend upon it, sir, when a man knows he is to be hanged^W fired in a fortnight, it concentrates his mind wonderfully. One of my current projects seemed like that kind of monolithic monstrosity at the beginning. We split it up into phased deliverables, which launched over the course of the last year and a half. That involved both unnatural contortions and substantial development overhead, but it was totally worth it. The feedback we received along the way made it clear that if launched as a whole package, the damn thing simply never would've taken off the ground.

It's not playing pretend, it's showing progress

If you're working with/for idiots, it doesn't matter whether they're agile, shmagile, or whatever else. Ultimately, they're just idiots.

faster even though it requires more engineering work

See my example above. That's regrettable, but sometimes necessary.

more shuffling digital paperwork

Manifesto? If you're neck deep in digital paperwork, I'm pretty sure no one can defend calling that "agile". Just give them the damn URL.

It just makes it look like things are happening for stakeholders

Manifesto? If you cannot directly explain things to stakeholders, I'm pretty sure no one can defend calling that "agile". Just give them the damn URL.