[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)