Engineers that are 100% busy are killing your team's effectiveness

How is this possibly true?

"If we keep everyone 100% scheduled during a sprint, this is how we get the max out of the team, right?"

Unlikely: this creates local, but not global efficiencies. It's painful to watch the sprint planning meetings where we try to stuff as much we can on every engineer's plate.

"Wait - you say - we only schedule 80% of the hours / story-points / pirate-ninjas (🚀) of the sprint, so that would make us optimally efficient, no?"

Better but not quite.

Let's start from first principles:

What is important is to maximize the output of the whole team and the impact this output would have to the entire business.

If an individual team member is working as effectively as they can, but their output is not affecting the customer, we're not achieving our end goal.

Quick way to reframe this: focus on what value we ship and work backwards from there. Some heuristics:

→ Did we structure the work so we can ship something to our customer that adds value? Not one piece of a puzzle that may eventually make it to an end-user but something tangible they can use now. (Shipping here means all the way to production, with the feature flag on, not just merged into trunk 😬).

→ Are our teams organized in a way where they can ship this value without unnecessary dependencies to other teams, systems, etc.? Having all the correct cross-functional group of people, and having them singularly focused on one outcome means the team can make fast decisions, that are of higher quality.

🔼 This is where waiting for a team member who had his time 100% "booked" is the velocity killer. They are busy doing *stuff* (that may or may not ship in the future) instead of helping the team get value shipped to the customer. Priority inversion! 🔼

→ Did we minimize unfinished work? If we didn't ship it, there is a solid chance the rest may not make it to the next sprint (priorities change all the time) and now this work becomes stale. All the effort we put into it is wasted. If it *does* make it in a future sprint, we will likely lose context and increase the likelihood of creating bugs.

So the suggestion is this: experiment bringing down the amount of work, while focusing on shipping value, and measure the correlation between the two. Find what the sweet spot is for your team - keeping in mind this can change over time.