In any complex system, small changes can have big impacts. That’s especially true if the system is under stress, or running at almost full capacity.
There’s lots of research on this, but the basic advice is to target no more than 80% utilisation, if you go for more then your wait time gets longer much faster than expected, you can’t react to changes or anything that’s unexpected.
Building software is a classic complex problem with changes and unexpected problems. Sometimes you’ll discover a team that is running slowly, often missing commitments and not delivering the value that they are focusing on. Often they are the most optimistic team you know, sure that they will turn it around, or that next quarter will deliver double.
If you dive into it, then it’s often a problem of capacity and utilisation. For whatever reason, the team thinks and plans as if they can always work at 100%, that there will be no changes or surprises and that every problem will be solved externally to them.
Rather than trying to fix these symptoms, strip it back to that utilisation belief.
Be ruthless, and cut back heavily on what the team is trying to achieve. Cut it in half, free up time for the team to get back on an even track.
Go back to some key agile practices. Prioritise the most valuable things first. Make the work as small as possible. Ship value as soon as you can. Cut back on work in progress, and start saying no to increasing this value.
When you’ve done this, you’ll find the team turns around. They are able to deliver faster as they aren’t overwhelmed, and the utilisation becomes more healthy.
When the unexpected hits, they are able to absorb it and keep going. They become predictable, and the time to realise value goes down.
So keep some slack in your schedule, and you’ll actually go faster and do more!