Building a team and helping individuals grow is so much more than "maximizing" (not really) every minute of the work day.
They will think about it on the way to work. They will think about it during breaks. They will think about it while appearing to wander aimlessly around the building.
They will think about it on the way home. They will think about it while they're at home, they will think about it in the shower, they will think about while eating or doing something else, and they will think about while they're asleep.
It will take them at least two weeks of actual undistracted full-time down-time to stop thinking about it.
But you can also make them stop thinking about it by piling on distractions - hiring sessions, meetings of all kinds, absolutely critical company events that aren't, and so on.
And you can also make them stop thinking about it by giving them too much to do. Most people have enough mental space for one, maybe two, problem tracks. Giving them more - especially with limited context switching time - and you'll make it impossible for them to solve any of them.
You're not running a physical production line. The typing and the code changes are the output of a complex and surprisingly fragile mental process. If you don't understand how the process works, you're wasting a lot of its potential value.
Not only will people be unhappy, but the quality of their work will suck too.
I have, for a long time, been very opposed to single point estimates, especially when those estimates are going to be interpreted like this. For any task that has any kind of uncertainty to it, there’s a range of time for how long it’s going to take. If you take longer than your single point estimate, you’re going to be punished for it in some way (work late, etc). If you take less time than your single point estimate, you’re going to be... punished for it?
What I’ve settled on in my consultancy work is doing 3-point PERT-style estimates. If I finish a task earlier than the range that drops out, I make a mental note to be more optimistic in the future on that project. If I’m nearing the far end of the range, I take pause and reassess what happened. Did the scope of the task blow up? Did I miss something up front? Is there too much technical debt in this project?
When you use SPEs, there’s no way to tell retrospectively (except in extreme cases) whether an estimate was actually good and the completion time was within an expected statistical variation, or if the estimate was bad and some part of the estimation process needs to be tuned.
We do not use estimates and actual's for any management metrics, this is for the developer to gauge their workload for the sprint. We know from our history that once a developer estimates about 40 hours of work for a two week sprint we don't allow them to take any more.
For us, estimates are the developers gauge to know when the sprint is full.
You're my hero. For real!
Baseball is a team sport, but that doesn't mean you have two people swinging one bat.
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.
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.
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!
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.
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?
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.
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.
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-...
The scrum team should be acting as a team and the developer should work with the team to figure out how he aligns. That is part of the "Self Forming" stuff. The Scrum Master is not their boss and does not weigh in on the project implementation. They are more of the advocate for the team and the advocate for Agile/Scrum. e.g. Dealing with the Product Owner when they try to add stuff to the current sprint or Management saying everything is top priority. Technically we call that coaching the Scrum process, but I'm going to make sure my team has steady/predictable work and are not going to burn out.
There are many other reasons that this reasoning is misguided, but I'll leave them for now and instead point you to those smarter and better written than I am.
Luckily, there is a ton of writing on this. I'd start with "The Mythical Man Month" which explains that your reasoning is a fallacy with software engineering: https://archive.org/details/mythicalmanmonth00fred