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

Agile is definitely not for everyone and every team. This is quite the irony because it was meant to be completely flexible and beside retros, all this businsss jargon was not made up by the creators of agile.

In some positions I only wished to be left alone with the relevant developers and make progress. Ultimately I get intertwined in a billion different metting to "loop me in", years later after leaving one of those companies, I like to think of the hundred of wasted meeting hours for stuff I never had to act on in the company.

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.

So when I started in the current startup I am in, we did the anarchy approach of just give a feature to work on and a tool to track tickets for 3 years. Eventually as team leader we migrated to scrum development. And as the team has expanded I've actually gotten stricter about it.

The rituals of scrum seem pointless when you start out and with a team of less than 4 people but at 4+ people it's important just to keep track of what on earth is happening in the team. Like end of sprint allows us to work out if things are vaguely on track. If they are not we can identify where the weaknesses are. Someone took on a task estimated at 8 story points and it took 2 weeks to do, need to find out what the issue is (usually because either because there is a knowledge gap in that aspect of the system or because the task just simply hasn't been defined clearly enough and needs the product owner to give more details).

I never thought I'd be that guy who defends the scrum process but 5 years of being a team lead changes you.

Though because this system was one that evolved naturally as we grew and realised what we were doing as a company wasn't working we largely avoided the corporate bullshittery version of scrum. We don't have a scrum master, I'm the guy who is like "oi I need you in this meeting" to the product owners.