The Scrum Master's Guide to Removing Blockers

Impediment removal is the Scrum Master's most tangible contribution to team performance. Everything else the SM does — facilitating ceremonies, coaching the team, protecting the process — supports the long game. Removing blockers produces immediate, visible results. A developer who was stuck for two days is suddenly productive again. A dependency that was holding up three stories gets resolved. A process bottleneck that slowed every sprint gets eliminated permanently.

Yet many Scrum Masters approach blocker removal reactively: they hear about a problem in standup, send an email, and hope it gets resolved. That is not impediment management — it is wishful thinking. This guide provides a systematic approach.

Classifying Blockers

Not all blockers are the same, and the type determines the resolution strategy. Understanding the categories helps the SM route the blocker to the right person with the right urgency.

Technical Blockers

These are blockers within the team's technical domain: a failing build pipeline, a database that is down, a third-party API that is not responding, a merge conflict that requires another developer's input, or a technical problem that nobody on the team knows how to solve.

Resolution strategy: Technical blockers are usually within the team's ability to resolve, sometimes with help from outside specialists. The SM's role is to ensure the team is not spinning their wheels. If a developer has been stuck on a technical problem for more than a few hours, faciliate a pairing session or escalate to a senior engineer. The SM does not need to understand the technical details — they need to ensure the right people are connected.

Organisational Blockers

These are blockers caused by the organisation's structure, processes, or politics: waiting for approval from a committee that meets monthly, needing access to a system controlled by another department, requiring a decision from a stakeholder who is unresponsive, or navigating a procurement process that takes six weeks for a software licence that costs R500.

Resolution strategy: Organisational blockers require escalation — often multiple levels. The SM needs to understand the organisational landscape well enough to identify who can actually resolve the issue, not just who should. Sometimes the official process is too slow, and the SM needs to find an unofficial path. This is where relationships and political awareness become essential skills.

External Blockers

These are blockers outside the organisation's control: a vendor that has not delivered a component, a client who has not provided required information, a regulatory approval that is pending, or a third-party service outage.

Resolution strategy: External blockers are the hardest to resolve because the SM has limited leverage. The best approaches are to escalate through the vendor's account management chain, have the project sponsor make direct contact, or find a workaround that allows the team to continue on other work while the external dependency is resolved. Document the impact — cost of delay, missed deadlines, idle team members — because this data strengthens escalation conversations.

The Escalation Framework

Escalation is not a sign of failure — it is the mechanism by which blockers that exceed the team's authority get resolved. But escalation must be structured to be effective.

A practical escalation framework has three tiers:

Tier 1: Team-level resolution (target: same day). The blocker can be resolved by someone on the team or by the SM directly. Examples: a failing test, a missing acceptance criterion, a question that the product owner can answer immediately.

Tier 2: Cross-team or management escalation (target: 1-2 days). The blocker requires involvement from outside the team. The SM escalates to the relevant manager, department head, or cross-team coordinator. Examples: access requests, environment provisioning, decisions from absent stakeholders.

Tier 3: Executive escalation (target: 1 week). The blocker requires senior leadership intervention. The SM escalates through the project sponsor or delivery manager. Examples: budget approvals, vendor contract issues, organisational policy changes.

For each escalation, document: what the blocker is, when it was raised, who it was escalated to, what the impact is (in terms of delayed stories, idle developers, or missed commitments), and what the expected resolution date is. This creates accountability and provides data for retrospectives.

When to Shield the Team vs. When to Involve Them

The servant-leader model suggests that the SM should shield the team from distractions and organisational noise. This is generally good advice — developers should not be pulled into political discussions or bureaucratic processes. But there are exceptions.

Shield the team when:

• The blocker is purely organisational or political and the team's involvement would not accelerate resolution.
• Stakeholders are putting pressure on the team that is counterproductive — asking for daily progress reports, questioning estimates, or requesting scope changes outside the agreed process.
• The resolution requires navigating relationships or hierarchies that the SM is better positioned to handle.

Involve the team when:

• The blocker is technical and requires the team's expertise to explain or resolve.
• The blocker has implications for the sprint plan, and the team needs to decide how to adapt. For example, if a dependency will not be ready for another week, the team needs to re-plan, not the SM.
• The blocker is recurring and the team needs to be part of designing the permanent fix.
• Transparency is more valuable than protection. Teams that are shielded from all problems lose context about the environment they operate in.

At Pepla, our Scrum Masters operate on the principle that the team should always know what the blockers are, but should not always be responsible for resolving them. Visibility and accountability are different things.

Tracking Impediments

An impediment board — whether physical or digital — is one of the SM's most important tools. Every blocker should be tracked from identification to resolution with the following information:

• Description: What is the blocker?
• Impact: Which stories or team members are affected?
• Date raised: When was it identified?
• Owner: Who is responsible for resolving it?
• Escalation level: Which tier is it at?
• Status: Open, in progress, or resolved.
• Resolution date: When was it closed?
• Days open: Total elapsed time from identification to resolution.

Review the impediment board daily. Blockers that are not making progress need re-escalation. The "days open" metric is particularly powerful — presenting a graph showing that blockers take an average of 8 days to resolve to senior management creates urgency that individual escalation emails do not.

Preventing Recurring Blockers

The most valuable blocker removal is the kind where you remove the blocker permanently, not just for this sprint. If the same type of blocker recurs sprint after sprint, the SM should address the root cause rather than continuing to treat the symptom.

Common recurring blockers and their structural fixes:

• "We're waiting for environment access" recurs because the access provisioning process is too slow. Fix: work with IT to create a self-service provisioning process or pre-provisioned environments for development teams.
• "The product owner is unavailable" recurs because the PO is overcommitted. Fix: escalate to management that the PO role requires dedicated time. Alternatively, establish a deputy PO who can make decisions in the PO's absence.
• "We're blocked on another team's API" recurs because of tight coupling between teams. Fix: define API contracts upfront using contract-first development, so teams can work in parallel against mocked interfaces.
• "We can't deploy because the test environment is shared" recurs because of environment contention. Fix: invest in environment-on-demand infrastructure using containers and infrastructure as code.

Retrospectives are the primary venue for identifying recurring blockers and planning structural fixes. The SM should bring data — "this type of blocker has occurred in 4 of the last 6 sprints and cost us an average of 12 story points per occurrence" — to make the case for investing in permanent solutions.

The SM's Blocker-Removal Toolkit

Beyond frameworks and processes, experienced SMs develop a practical toolkit:

• Relationship capital. Build relationships with people across the organisation before you need their help. The SM who already knows the infrastructure team lead by name gets faster responses than one who sends cold emails.
• Clear communication. When escalating, state the problem, the impact, the urgency, and the specific help needed in the first three sentences. Decision makers receive dozens of requests daily — make yours easy to act on.
• Data-driven escalation. "We're blocked" is weak. "We have three developers idle and are on track to miss our sprint commitment, which delays the client delivery by two weeks and puts R200K of revenue at risk" is strong.
• Creative workarounds. While the official resolution is pending, find ways for the team to make progress. Can they work on other stories? Can they implement a temporary workaround? Can they do preparatory work that will accelerate implementation once the blocker is resolved?
• Follow-up discipline. After escalating, follow up at the agreed time. And then follow up again. And again. Persistence is not rudeness — it is accountability.

The Scrum Master who removes blockers effectively earns the team's trust, demonstrates value to the organisation, and directly contributes to delivery outcomes. It is one of the most concrete and measurable aspects of the role.