An item can spend days ‘in progress’ while nobody is actively working on it.
Someone has started it. Everyone involved is busy. Yet the item is waiting for an answer, a review or its turn in somebody else’s queue.
If we want to understand why delivery takes so long, we need to notice the gaps between the work.
Continue reading The hidden life of agile work: most delays happen while nobody is working on the itemA two-week Sprint creates the impression that a Scrum Team learns every two weeks.
But that is true only if useful feedback reaches the team within that period.
A Sprint may end while the work is still awaiting integration, testing, deployment or use by real customers. The Scrum events continue, but the most important feedback arrives several Sprints later.
Continue reading What happens when the Sprint is shorter than the development feedback loop?One of the harder parts of being a Scrum Master is this: sometimes you can see that a team needs to slow down, but managers or stakeholders want the opposite.
That is understandable.
From the outside, slowing down can look like reduced effort.
But in practice, reducing overload is often how delivery improves.
The key is not to argue for ‘slowing down’ in the abstract.
It is to help people see that too much work in progress, too many competing priorities and too much pressure to start work are often the very things that stop work from finishing.
Continue reading How to influence when slowing down is the right moveOne 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.
Continue reading When slowing a team down increased delivery
I’ve been thinking a lot recently about the size of user stories in agile projects. The idea that I’ve been reflecting on is what if teams only worked with small, similarly-sized pieces of work, rather than exponentially larger blocks of work?
In theory, small user stories should be more predictable, should include less risk, less uncertainty and less complexity. They should, therefore, take less time to complete than larger user stories… you would think! Or as Mike Cohn put it in Agile Estimating and Planning (Prentice Hall, 2006), “small stories keep work flowing”.
Continue reading The importance of small user stories
