[jake_morrison]

Scrum is for when you have a central dev team in a company that's shared between multiple groups. Once every sprint, you get all the managers in a room and let them fight it out. The result is a list of features that will be in the sprint. Everyone more or less gets their turn, depending on how powerful they are and whether something is legitimately urgent. Even if something is urgent, they can probably wait two weeks if they don't get it in this sprint. The dev team gets to work on something without interruptions for two weeks. The alternative is having everyone pushing around the devs, continuously changing requirements, overloaded devs, and general chaos.

[regularfry]

The critical factor there isn't the sprint, it's the product owner. As long as the PO has the power to prioritise work, and as long as they are the only gateway for getting work into the team, chaos (from this direction, anyway) is minimised.

[_y5hn]

PO or scrum master as gateway for new work is sort of misguided malpractice that continues the insulation of developers. It may work if PO or scrum master has a clue, "lead" by asking/helping the team, but often in practice they are not technical themselves or external to the team. Having stakeholders fighting for priority and say, builds up helluva toxic environment that trickles down as well.

[khalilravanna]

I see both options being shot down here so what's one possible alternative that does work?

[ratww]

There's a perfectly healthy middle ground where POs are the gateway to new tasks but don't isolate the developers from the rest of the organization, nor disregard developer input.

And since we're talking about Scrum, PO and Developers (traditionally) supposed to sit together with stakeholders for Review meetings, gather feedback from them and provide input on the next tasks.

[_y5hn]

What works depends heavily on the circumstances and the team (people first). What is to be accomplished: software delivery, operational quality and/or user/customer interactions? Are the responsibility boundaries clear or not? When overall structure is clearer, it is more straightforward to decide who are the best decisionmakers for the team..

What works for one team, might not for another. It's a good idea to have semi-stable teams as there is significant overhead creating temporary teams and disbanding them.

When there's no true need of urgency or the deadlines are outright fake, kanban and maturity may make a good alternative to scrum/sprints. It may even allow for some flexibility how to allocate people and borrow temporarily from other teams. You don't want teams to silo down, which they do the minute they are formed to start healing the wounds. Teams will need clear responsibility boundaries to be able to make effective decisions, while also granted the slack, incentives and psychological safe learning environment that fuel the necessary and logically next steps.