Scrum, day 42: finding an impediment’s owner

Today's objective: distinguish the person affected by an obstacle from the person able to change its cause, then make the next action explicit.

Read alongside: Mastering Professional Scrum, chapter 6, focusing on identifying and removing impediments. Allow roughly five minutes for this companion, plus your book reading.

A blocked card does not identify a remedy

The fictional ShiftSwap team needs to verify a message sequence in a shared environment. Access requires a manual request handled by a separate operations group. The request has waited for several days, and the Developers have moved the item into a blocked column.

The board now shows the delay. It does not show who can resolve it, what information that person needs, or whether the same obstacle will affect the next change. Transparency about waiting is a beginning, not the entire response.

Radu helps the team describe both the immediate problem and the recurring mechanism. They need access for current work, and they need to understand why ordinary product verification depends on an unpredictable queue.

State the impact in terms of work and decisions

“Operations is blocking us” names a group and assigns blame. A more useful account says which check cannot run, which product claim remains unsupported, when the request was made, and what the current delay means for the Sprint Goal.

This information helps the operations group understand the urgency and determine whether the request is complete. It also helps Elena communicate the forecast honestly. The team should avoid exaggerating impact simply to get ahead in the queue.

If several items depend on the same access, make that relationship visible. Repeated individual complaints may conceal a single structural dependency that deserves a broader solution.

Distinguish several kinds of action

The Developers may be able to improve the request by providing missing details. An operations colleague may be able to grant the existing approved access. A manager or policy owner may be needed to change the access process itself.

These are different actions with different authority. Assigning the entire problem to the Scrum Master can obscure that distinction. Radu can help identify the people involved, connect them, and follow up, while the relevant specialists and decision-makers perform the necessary work.

The Scrum Guide describes the Scrum Master's service as including causing impediments to be removed. That does not require the Scrum Master personally to execute every remedy or become the sole route through which the team requests help.

Ask what the constraint is protecting

The access process may exist to protect sensitive information, maintain reliable environments, or preserve accountability for changes. Understanding that purpose helps the team propose a workable improvement.

Perhaps verification can use a dedicated environment with appropriate sample data. Perhaps a defined access profile can be approved once and reviewed regularly. Perhaps the current request simply needs a clearer explanation of the required scope.

The team should not treat safeguards as pointless because they are inconvenient. It should also not assume that the current manual queue is the only way to achieve the safeguard's purpose. A useful conversation examines both the risk being managed and the delivery consequence.

Separate immediate relief from lasting improvement

Operations may expedite the current request. That helps the Sprint but leaves the recurring dependency unchanged. The team records the immediate resolution and keeps the broader issue visible if it continues to affect ordinary work.

A lasting improvement might require investment, a policy decision, or a change in responsibilities. It should have a clear next step rather than remain indefinitely labeled “organizational problem.” Someone needs to know what decision is being requested and what evidence supports it.

The team can also investigate alternatives within its authority. Better local checks may reduce some dependence on the shared environment, while other checks genuinely require it. Understanding that boundary helps avoid both over-escalation and unrealistic self-reliance.

Follow up without creating a second management system

For the obstacle, ShiftSwap records the impact, current next action, responsible contact, and review point. This can live alongside the relevant work or in a small visible impediment record.

The purpose is to prevent a problem from disappearing between conversations. It does not require a large parallel ticketing process with its own ceremonies. When circumstances change, the team should update the actual delivery plan as well as the obstacle record.

If no response arrives, escalation should add useful context: how the impact has changed, which decision is still missing, and who can make it. Repeating “urgent” more loudly may increase tension without improving anyone's ability to act.

Inspect whether the cause has changed

After access is granted, the team checks the next relevant request. Does it encounter the same queue? Are the requirements clearer? Can the team perform ordinary verification without relying on an exceptional favor?

This distinction matters for evaluating improvement. A heroic intervention can make one Sprint succeed while preserving a fragile system. The team should recognize the immediate help and still examine whether future work has become more dependable.

The remedy may be partial. Making that explicit helps the organization decide whether the remaining consequence justifies further attention.

Map one obstacle

Choose a current impediment. Write its observable effect, the action that could relieve it now, and the decision that could prevent recurrence. Identify who can perform each action and what information they need.

Add a follow-up point and describe what would count as resolution. If the team lacks authority over the cause, explain the boundary without presenting itself as powerless over every part of the response.

Reflection: are you tracking the presence of the obstacle, or the next decision needed to change it? Which missing connection currently keeps the work waiting?

Next, day 43 examines a dependency the team can reduce through deliberate learning.