[TheCoelacanth]

This is exactly the attitude that causes anxiety. You are done with the thing you were working on, now go "help" one of your teammates somehow regardless of whether that will actually increase the amount of value the team is delivering.

Baseball is a team sport, but that doesn't mean you have two people swinging one bat.

[tmorton]

Software development is more like basketball than baseball.

In basketball, players do "take off" certain plays. But the most valuable players are still contributing during that time. A good shooter can just stand at the 3-point line. Even if they don't do anything, they occupy a defender and make the whole offense better.

A developer won't be cranking out code 8 hours a day. But if they are available to answer questions, perform code reviews, and generally help the team, that's a valuable contribution.

[muzani]

Yeah, honestly, I think soccer/basketball are better analogies. The team remains in formation. Doing too much is far worse than doing too little, because it pushes everything else out of sync.

A big part of the work is sometimes just fixing/improving workflow. There are tests to write, documentation, refactoring, warnings to look at, plugins to update, that wonky button padding to fix, all these little things that are not vital but stack negative impact.

[crdrost]

There is a much bigger point here, though, about idle time.

Idle time is not just about healing the psyche. It also does that. But you run into problems from not having idle time much sooner than burnout, typically.

What is at stake is that the greedy algorithm for optimization does NOT work for complex systems. “I will make every individual person efficient, everyone is always working on something, look how good of a boss I am”—and you WILL fail to meet deadlines. And you will blame that failure on other people, or on the business constraints, because “well I did everything that I could to make the system efficient, the expectations that were put on me were unrealistic!”

The greedy algorithm is really obvious. Why would every part of the system doing less allow the system as a whole to do more? But it is also really wrong for any system that is large and complex enough to have the right sort of nonlinearities. If you’re managing a call center and everything is very linear—everyone has the same task day-in, day-out, the output of the team is directly changed by the output of every individual on that team—great, you can use the greedy algorithm. But if different people are working on different interrelated tasks then forget about it.

Because if you manage an interdependent system without creating idle time, soon you have every task falling into the proverbial “three priorities: Hot, Red Hot, and DO IT NOW.” You have that because you have chosen to create a system where there are large latencies in response to incoming tasks, so that those tasks are piling up.

I discoursed more on the abstract theory behind this in an answer on the Project Management Stack Exchange:

https://pm.stackexchange.com/questions/26651/why-do-all-the-...

[crdrost]

(also if you want a longer overview a bunch of related concepts are talked about in Dominica DeGrandis’s book Making Work Visible, and the advice on managing by the critical path method comes from a makes-my-eyes-roll-a-little-but-still-pretty-solid business novel by Eli Goldratt called Critical Chain, which applies the reasoning from another less-eye-rolls business novel by the same author to the “project context” that we find ourselves in when writing software.)

[alexpetralia]

This is great. Thanks

[UglyToad]

This is a nice metaphor.

I think it's similar in many ways to the complaints one overhears about roadworks. "Why do they take so long!? It's just 5 people stood around watching another dig a hole!". Software is a lot like that, you can't have everyone run off and work on all parts of the stack and domain at once, there's only a certain amount of parallelizable work.

[brixon]

Examples are: The tester is always backed up (1 tester for 4 developers), so a developer can help test a user story they did not write. A developer can take on a user story that was originally assigned to someone else.

[theprotocol]

This is kind of a Kafkaesque way to destroy the developers' pysches.

I feel like you've misunderstood the critical replies you've received above. You may think you are profiting by trying to allocate every millisecond of the developers' time, but it comes at a great cost that is hard to see upfront, but is very very real.

[brixon]

The sprint is two weeks long, if you finish your user stories in a week like OP, then is a full week of downtime ok? That will encourage everyone to sandbag the work to only need to work every other week. No one is talking about milliseconds or even hours, but I don't want the developers making up stuff to do like the OP mentioned or taking stuff off the backlog that the team did not agree to for the sprint. He used the word Sprint, so I assumed we were talking about a team and not just an individual, support your team, that's all.

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