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 ov

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.