Scrummaster here. Interesting enough, Agile was built to be completely developer driven, to reduce meetings and stress on developers and reduce waste time. Instead we have what I have coined "corporate agile". Agile has been bastardized and ruined by corporations to sneak in their bullshit.

For example, the most basic rule of Agile is that it should be Team driven. This means:

• The team should drive how many meetings happen and when they happen. (You always have a planning and daily standup, but length, time of day, how they run, should all be developer chosen)
• The team should decide kanban/sprints/sprint length, wip length, everything. They should decide what process works best for them, with hints and guidance from the scrummaster
• The team should decide what points mean and how they represent work items. Points should never be linked directly to time or be a limitation (i.e. you should never point something as '4' hours, because now you have business looking at that like it's some expectation, and all developers know that that doesn't work.

Instead I've seen

• Director/senior business people demand extra meetings, followups, random bullshit meetings that are not relevant to the developers and really should have just a PO.
• Company wide mandates on sprint length, expected capacity per sprint, meetings, times, "one size fits all" when in reality no team is the same
• Points that are treated as punishments. "You said this would get done in 26 hours". Code doesn't work that way, and all it does is teach developers to lie.

So, I'm very burnt out as a scrummaster. We get no power, and us who truly do believe in true agile are shot down continuously because people who don't understand developers or development want us to micromanage, and I hate micromanaging my teams. If they let me actually do my job I could get them all the data they need, but they think they know agile better than I do.

Thanks for letting me rant. I'm sorry Corporate Agile has failed you

Agreed in spirit, but this is the Internet, so here's my unrequested take:

As a manager, if there's only one part of the development process I'll keep, it's the retro. The retro is the critical bit that gives me insights to help get the rest unstuck.

Sprints have one and only one true purpose, I use them to tell stakeholders how long to fuck off and leave the dev team alone for, in a minimum of two week increments. I don't think my team actually gives a rip what sprint we're in.

I don't do burn charts. I've never seen the point. I'm pretty good at telling stakeholders "it's done when it's done" and that sentence takes way less time than making a chart that says the same thing.

I do track total tickets closed because a big jump up or down in that number is a a leading sign of oncoming burnout.

I've appreciated great SCRUM masters, but I've never managed to keep that role filled long term.