I'm a manager who (I think) does agile right, and will now defend it because I think it's brilliant (when done right).
On standups: first, I rarely speak in standup; if some other manager uses it to micromanage, well, that's on them, not on the general concept of daily checkins. Second, it's very difficult to "signal progress vs. actually making it" with your teammates. That's part of the point: intra-team accountability. If you're making no progress, you might fool me with generic excuses and you can certainly fool a business analyst or a project manager, but you can't fool another programmer who works on the same code and sits next to you.
On agile having a lot of bureaucracy layers: compared to what? The agile "bureaucracy" my teams endure is: standup, refinement, and retro. That's less than two hours per week. What methodology involves less bureaucracy than that, other than anarchy?
On points: OK I will kind of give you this one, but only because they don't bring value to you. Story points aren't for you, the dev, they're for PM and execs. What do execs want, in terms of estimates? They want to know exactly when a feature is going to ship, to the day, even if it's years away. What do devs want, in terms of estimates? To not give one, ever, for anything. Story points are the compromise. And pointing a story takes maybe 30 seconds, so it's hard to understand how anyone can see it as onerous.
So in summary, I think agile is very good when done right, and in places where it seems bad it is usually because one of the basic ingredients (a team empowered to change their own process) is missing. That, to me, is the core of agile: a team that iterates on their own process. If your team is not willing to or allowed to do that, IMHO they're not actually agile. And if they are, well, take your objections, bring them up in retro, and propose something better.
On standups: first, I rarely speak in standup; if some other manager uses it to micromanage, well, that's on them, not on the general concept of daily checkins. Second, it's very difficult to "signal progress vs. actually making it" with your teammates. That's part of the point: intra-team accountability. If you're making no progress, you might fool me with generic excuses and you can certainly fool a business analyst or a project manager, but you can't fool another programmer who works on the same code and sits next to you.
On agile having a lot of bureaucracy layers: compared to what? The agile "bureaucracy" my teams endure is: standup, refinement, and retro. That's less than two hours per week. What methodology involves less bureaucracy than that, other than anarchy?
On points: OK I will kind of give you this one, but only because they don't bring value to you. Story points aren't for you, the dev, they're for PM and execs. What do execs want, in terms of estimates? They want to know exactly when a feature is going to ship, to the day, even if it's years away. What do devs want, in terms of estimates? To not give one, ever, for anything. Story points are the compromise. And pointing a story takes maybe 30 seconds, so it's hard to understand how anyone can see it as onerous.
So in summary, I think agile is very good when done right, and in places where it seems bad it is usually because one of the basic ingredients (a team empowered to change their own process) is missing. That, to me, is the core of agile: a team that iterates on their own process. If your team is not willing to or allowed to do that, IMHO they're not actually agile. And if they are, well, take your objections, bring them up in retro, and propose something better.