[kabdib]

Yeah. Scrum doesn't make management disappear, it amplifies it.

I saw meetings with middle managers (people who hadn't shipped anything significant in a decade) in daily meetings, going over burn-down rates of individual engineers and "expressing concern" through channels that someone was off their schedule by a couple of days. The daily scrums were just half-hour status-in-a-ring and some public shaming if you couldn't say that you did anything, so a lot of people made stuff up, or at least hedged by saying they'd completed 50% of the work or that tests were "nearly passing" (code for: my stuff is broked).

Oh, and in the mean time the build system we devs were using had been on fire and broken for three weeks and it was nearly impossible to get a working build. WTF?

I said, "We don't need Agile. We need an earthquake to collapse that wing of the building" (where the managers were; they liked to cluster).

We had Ken. Ken was there at the beginning for maybe a week, and for the next few weeks after that it was great. But we forgot that middle managers are still gonna manage, and that you have to fire them or they're still going to be there, you know, managing stuff, because that's all they know how to do.

And with the right tools, Scrum can be turned into the perfect surveillance state. (I stole that from another response in this thread, thanks).

[cmdkeen]

Intriguingly you've not mentioned 2/3rds of the people in a Scrum team - the Product Owner and the Scrum Master - both of whom are supposed to be the ones who handle many of the problems you list. Build servers being on fire feels like a perfect example of an impediment. People who aren't actually developing anything feel like the perfect example of people who shouldn't be at standups, and certainly shouldn't be speaking at them.

Again Scrum relies on empowerment, with the Product Owner being the "single wringable neck" whose career is tied to the project and who has the buyin from management to get stuff done. The point being that it is in their interest to have a happy and productive development team doing what they say.

Finally there's also a really good point about internal and external metrics. I've always been a fan of management getting the stats they ask for, not being provided with access to the team's internal metrics which should really be short term to address perceived issues. If we count defects for a few sprints to reduce our defect count that is good, providing them for evermore to management is bad. Separating the two out lets your Scrum Master / line managers have a good conversation about what management are concerned about and how to effectively measure it.

As you said - bad managers won't do any of this, but then flagging up that you have bad managers is A Good Thing (TM) overall.

[kabdib]

Well, 2/3rds of the people in a Scrum team were essentially dead weight, in my experience. They made work.

In one org, the devs were excluded from the planning meetings, which is pretty much all you need to know about how badly Scrum went off the rails.

"Okay, you're signed up for X, Y and Z, it'll take you two weeks, and tell us every morning about your progress."

"This is day 15 of the build system being totally broken, and I haven't been able to run my code in a week."

"So, you're late. Is that what you're saying?"

(sound of door slamming shut)

[dccoolgai]

The problem is that, to them, "Agile" is Candyland: No responsibility or accountability for their own job (making stable plans/requirements), but hyper-accountability/scrutiny for the devs that have to spring to their every half-baked whim. It amounts to a DDOS attack on the dev process. It's just waterfall without the top part of the waterfall where they are responsible for requirements. I'd rather go back to waterfall.