Nobody looks idle.
The developers are working. The backlog is full. Stand-ups happen every morning. There is always another release being prepared.
But the dates keep moving.
Something that was supposed to take two weeks needs another week.
A dependency appears that nobody accounted for.
Testing finds something late.
The release gets pushed because the environment isn’t ready.
A change that sounded small turns out to touch three other parts of the system.
Eventually, planning starts to feel pointless.
The business asks when something will be ready and gets an answer with enough caveats that it isn’t really an answer.
So management pushes harder.
More status meetings. More deadlines. More escalation.
And the team gets even busier.
But delivery doesn’t become more predictable.
The work may have changed. The commitment hasn’t.
This happens more often than organisations admit.
A date is agreed when the work is still relatively poorly understood.
Then delivery begins.
An integration exposes another requirement. A dependency needs work. Something described as an MVP starts acquiring the expectations of a finished product.
The team is now delivering something materially different from what the original commitment was based on.
But the date remains.
At that point, the organisation is no longer managing a delivery plan.
It is managing the gap between an old assumption and what it now knows to be true.
Sometimes the delay isn’t in the feature at all
The other place I look is everything surrounding the work.
How does code actually reach production?
What happens when a deployment fails?
Can it be rolled back safely?
How much manual work is involved?
Are environments reproducible?
Do automated tests tell us quickly when something has broken?
Can we see what is happening once software is running?
A developer can spend an entire day dealing with these things and still have nothing new to show the business at the end of it.
Do that across a team, repeatedly, and it starts looking like a capacity problem.
It isn’t necessarily one.
The organisation may simply be consuming its engineering capacity fighting its own delivery system.
This is where I stop asking whether the team is fast enough
I want to know where the time is actually going.
Not where the process says it should be going.
Where it is going.
Because if people are working hard and delivery still keeps slipping, adding pressure is unlikely to fix it.
First find the constraint.
Then fix what is making the work difficult to move.
Predictable delivery doesn’t come from making busy teams busier.