[wbronitsky]

I believe many people, including myself, are caught up on the idea of taking "someone else's work". I personally would be much more comfortable with the items you suggest if they either had not been assigned to someone (new or backlog task), or organically offered up (someone says they probably won't get to a task during standup or somesuch).

Additionally, it would seem that you are assuming that the dev is doing something wrong by finishing early and doing nothing, when it seems to me that they are just acting on their incentives. If my incentives are to finish my tickets for the sprint, I'll do just that. Rarely am I incentivized to take others work; I'm not going to get promoted if my co-workers hate me for poaching their tasks. I agree that we should probably find work for said dev, lord knows I also get anxious without work, but the suggestion that we take our teammates work from them is one that many teammates will probably bristle at.

Finally, I have always found the focus on locking the sprint once we plan it a bit absurd. In agile, we acknowledge and even love that the ground under us is shifting constantly. We are always iterating in everything else, so why not the sprint? The idea that I should take others' tasks from them instead of finding something else that I can work on seemingly comes from this myopic focus on frozen sprints.

However, I would assume that is not your view! Maybe you can help me see why a focus on completing the sprint is more important than letting my coworkers do their assigned work. I might be a bit closed minded on this because of my experience, so any thoughts here would help me contextualize this!

[brixon]

I think the root of the issue I am getting backlash on is team work vs individual work. If you are using Agile as a process to just organize work then ignore all my comments. I am using Agile/Scrum as a way to build strong development teams (not just groups of individual developers).

For the locking sprints, that is a matter of protecting the developers from management and the customer. The product backlog can be moving target all day, but the sprint backlog needs to have some backbone so the developers have focus and are not pulled different directions every day. If the sprint backlog needs to change then the developers will come to me for help. Our history is from a very chaotic environment and the developers really like having some sanity/consistency with defining the sprint and holding it still. If the customer wants something else, then we can deal with that in the next sprint.

[wbronitsky]

I feel like your last point does not address my criticism. The devs should feel like they have control, not the management, I agree. But my argument is we extend that control to allow devs to pull new tasks into the sprint if they are done.

Sure, you’ll have to explain the optics to management when they ask “how come the devs get to control their own process instead of me,” but with your conviction in the Scrum Master role, I’m sure that wouldn’t be too big of a problem, and would allow for everything you and I are arguing for, right?