A Scrum team completes an Increment. What happens next?
If the answer includes, “It waits”, the team may have uncovered a wider problem in the delivery system.
Follow the work
Choose a recently completed Product Backlog item (PBI) and follow its journey beyond the team.
Where did it go after it met the Definition of Done?
It may have waited for:
- approval
- integration with another system
- security or compliance review
- another team to complete related work
- a scheduled release window
- operational or marketing preparation
Some of these steps may be necessary. The important question is whether the delays between them are necessary too.
Look for queues and handoffs
Lean encourages us to examine the whole flow of value, not only the part managed by the Scrum Team.
Ask:
- How long did the work take to complete?
- How long did it spend waiting?
- How many teams or departments handled it?
- Was information lost or misunderstood during handoffs?
- When did it finally become useful to the customer?
This can reveal a significant difference between completing work and delivering value.
Make the system visible
Do not begin by blaming the people responsible for each stage. Most delays are created by how the system has developed, not by individuals deliberately holding up work.
- Map the journey.
- Identify the longest waits.
- Look for repeated handoffs, large queues and fixed release schedules.
Then ask what small change could improve the flow.
A team can become faster without value reaching the customer any sooner. Sometimes the more useful improvement is not within the team at all.
Follow the completed work. It will show you where the system needs attention.
This post is part of a series exploring what Scrum leaves unsaid. Scrum provides a deliberately lightweight framework, but it does not attempt to explain every aspect of effective product development. Practices and insights from XP, Lean, Kanban and DSDM can help us understand the technical, organisational and delivery questions that Scrum leaves open.
