I really hesitate to say I'm in favor of agile. It's just a flexible tool for getting things done which prioritizes team empowerment and short feedback loops over top-down command-and-control project management.

Some good adaptations I've seen are largely around handling distributed collaboration, and favoring out-of-band communication practices over regular interruptions. For many teams benefit from replacing a daily standup with a status email. A good compromise is also a daily status email with standups every other day. Having a mid-sprint status meeting and a regular standup time in slack is also a good compromise.

I think engineers in particular get caught up on the rituals they're asked to attend because they view it as invasive. The rituals are just part of it, but in my opinion, the end goal is to provide regular feedback loops for measuring progress and actively communicating. This way, teams can react to changes and blockers before they prevent a group from delivering on its commitments.

Agile is good for teams that are matrixed and highly empowered. If there are strong dependencies on external teams, then it's hard to get out of the proverbial waterfall.

I don't think agile is appropriate for handling questions around product-market fit, but it does help a team to iterate on a product in measured paces in response to the product / sales cycle.

In terms of an alternative project management approach, I think maybe the question needs to be framed differently. Other approaches don't need to fail; agile just needs to be different in a useful way. Agile has a focus on self-organization and measuring progress in short intervals. It suits the increasingly distributed and technological ways in which groups perform work, specifically because it's up to the team to implement the process in a way that works for them.

The real problem with agile (even well-done agile) is the interface with non-agile upper management. Sooner or later you usually run into someone who wants to see your detailed project development plan and timeline, or some such. Answering "Why would we need one of those? We just talk to each other" does not go well, even if it's true that you actually don't need one of those because you've addressed the problems the document is supposed to address simply by regular informal communication. (Been there, done that.)

If upper management doesn't "get" agile, at some layer you have to transition to non-agile. There's an impedance mismatch at that layer. If someone doesn't actively translate things into upper-management terms, they can decide to kill the project, simply because they can't tell what's going on.

This is why middle management exists -- to insulate working groups from hard-and-fast commitments and timelines. They do this by using their professional experience and understanding of the capability of their teams to know what overall product to promise under what kind of timeline.

I don't know about many companies with 50 or more people where the CEO "does agile" personally, for instance.