One of the most important agile lessons I have learned is that speed does not always come from going faster.
Sometimes it comes from slowing the system down.
I saw this in a Scrum team that was struggling to finish work. On paper, we looked reasonably disciplined. We were following Scrum well enough. We had two-week sprints, like other teams in the organisation. But our delivery told a different story.
When I checked the Jira data, our cycle time for backlog items ranged from one day to 35 days.
That meant some work was taking up to seven weeks to get through the system.
For a team working in two-week sprints, that was a warning sign.
The problem was not effort
The issue was not that people were lazy or disengaged. The team was busy. Everyone was working hard.
But busyness is not flow.
In our retrospective, I raised the ‘five thieves of time’ again:
- too much work in progress
- unknown dependencies
- unplanned work
- conflicting priorities
- neglected work
The biggest problem was too much work in progress.
We had too many items moving at once, which meant too few were actually getting finished.
We reduced the sprint length
So we tried something that sounded counter-intuitive.
Instead of pushing harder, we slowed things down and reduced how much work we tried to carry.
We shortened our sprint length from two weeks to one week.
Not because one-week sprints are always better, but because we needed to force a different behaviour. We needed to focus on fewer items, finish more of what we started, and expose problems sooner.
What changed
The transformation was extraordinary.
Within a month, over four sprints, we brought our cycle time down from a spread of one to 35 days to a spread of one to seven days.
That was a major shift.
More importantly, we were delivering usable software much more regularly. We could put it in front of stakeholders sooner and get feedback while it still mattered.
That is what flow looks like.
The real lesson
The lesson was not “all teams should use one-week sprints”.
The lesson was that flow improved when we reduced work in progress and stopped pretending that keeping everyone busy was the same as making progress.
Sometimes a team does not need more pressure.
It needs less overload.
Because flow over utilisation is not just a slogan.
It is often the difference between work that moves and work that stalls.
