Yeah, this is probably going to sound like a truism, but to avoid shitty Scrum, you need to resist management trying to alter the processes, but you should absolutely tweak the processes to account for the needs of the devs.

Basically, yet another reporting meeting does not help deliver the software faster. But more (or less) meetings for devs to sync what they're working on, that can help, depending on your team's specific needs.

Well, yeah, that's what Scrum is. From the guide which takes maybe 10 minutes to read

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

That's not a throwaway sentence - it is fundamental to how scrum works and that is reinforced throughout the scrum guide.

Every conversation about Agile and/or Scrum being "the worst", after some prodding it turns out that their company has refused to read or implement one or several of the fundamental principles, often without even being aware that was an essential requirement. You're baking a cake and you decided to not use any butter, that's on you champ, don't blame the fucking recipe.

The biggest valid criticism of scrum is that the thing that makes it so great - its structural empowerment of individual teams - is also what makes it structurally incompatible with any traditional top-down management style. The company must fundamentally be (re-)organized to have a flat corporate structure within its R&D department - most are simply incapable of mustering the necessary changes, if only because too many middle managers' jobs are at stake. So they call their middle managers "POs" or "Scrum Masters" and wonder why their version of Scrum sucks.

This is what’s most important. Allow for experimentation!

What works well for one team might not work well for your team. What worked well for your team 1 year ago might no longer be what you need now.

My favorite approach to team processes was to work entirely alone and do everything by myself.

That’s scrum. One of the defining features of scrum is timeboxing meetings. Daily standups are 15 minutes. A two week review should be two hours. Ditto for retrospectives and sprint planning.

A seven hour meeting means the scrum master wasn’t doing their job.

story point numbers

how many different ways can I say "I simply don't know yet?"

well give us a guess

could be one point... could be 50? I DON'T KNOW

well yeah but give it a guess anyway

They're those things on the face thing with the minions, right?

He's kind of a boomer? Like you aren't sure if he was born between 1945 and 1964? If not he's probably Gen x which are just boomers who SHOULD know better?

This. A scrum master's job should be first and foremost making sure that the dev team has what it needs to get real actual work done. Ideally, the scrum master should be face tanking status/ update meeting, coordinating with outside entities, and ensuring that as few distractions make it to the team as possible.

which literally everyone can easily do themselves

Key word here is 'can'. People can update it themselves, but unless kept accountable for missing something bad, they don't do it unless a PM drags it out of them. In a perfect world we'd all show enough accountability to share the info that could affect a project in a democratic and orderly way, but even when ignoring a lack of PM experience, people usually feel it's bureaucratic and takes precious time away from their specialisation.

A PM with a good background will definitely have a chance to be better than a PM without, but being able to contact the right specialists at the right time and keeping the project flowing is what truly matters.

Ta!

pbf is the best webcomic ever

Oh that makes more sense with the monster on the cover lol