Impediment Removal Vocabulary

Escalation is the Scrum Master's primary tool for external impediments — when the team cannot self-organise their way out of a blocker, the Scrum Master's job is to navigate the organisation and get the right people engaged.

Effective escalation has three components: (1) clarity — describe the impediment specifically ("The partner API team hasn't provided OAuth credentials promised 5 days ago"); (2) impact — quantify the business cost ("This is blocking 3 stories and puts the sprint goal at risk"); (3) ask — make a clear request ("I need someone to contact the partner team lead by EOD today"). Vague escalations ("we have some blockers") rarely produce action. The Scrum Master should have a pre-established escalation path — knowing which manager or stakeholder to go to for which type of impediment — rather than figuring it out when the crisis arrives.

Key vocabulary:
• impediment — anything that slows or blocks the team's ability to progress toward the sprint goal
• escalation — raising an unresolved impediment to a person or level of authority with the power to remove it
• escalation path — the pre-agreed route through the organisation for resolving specific types of impediments

Cross-team dependencies are among the most common sources of sprint disruption — the Scrum Master's job is to make them visible, coordinate across team boundaries, and help the team adapt if resolution is delayed.

The recommended approach follows a pattern: (1) Surface — add the dependency to the board with an explicit "blocked by payments team" label; (2) Connect — the SM contacts the other team's SM or lead to get a commitment on the delivery timeline; (3) Hedge — the team prepares a fallback (mock, stub, alternative story) in case the dependency isn't resolved on time; (4) Escalate — if the dependency crosses multiple sprints, escalate to programme-level coordination. Recurring cross-team dependencies are a signal for architectural or organisational change — a system that requires constant coordination between teams is a design problem, not just a planning problem.

Key vocabulary:
• cross-team dependency — a blocker that requires work or input from a different team to resolve
• dependency — a relationship where one piece of work cannot start or complete until another piece is done
• stub / mock — a temporary implementation that mimics a dependency's interface, allowing work to proceed before the real implementation is available

Ownership of the impediment log is accountability for resolution progress, not personal responsibility to fix everything — the Scrum Master is the orchestrator and escalator, not the solver of all organisational problems.

A well-maintained impediment log has: each impediment described clearly with impact quantified; an owner (who is pursuing resolution — often the SM, sometimes the developer or PO); the current status and next action; and the date it was raised. Reviewing the impediment log at retrospectives is a powerful pattern: if the same type of blocker appears three sprints in a row, it's a systemic issue. Common systemic patterns: "waiting for access/credentials" → automate provisioning; "blocked by another team" → establish a formal service agreement; "unclear requirements" → improve backlog refinement. The SM's highest leverage is converting individual impediments into systemic improvements.

Key vocabulary:
• impediment log — a tracked list of current and past blockers, including owner, status, and resolution date
• systemic impediment — a recurring type of blocker that indicates an organisational or process problem requiring structural change
• impediment owner — the person accountable for actively pursuing resolution of a specific blocker

Impediment resolution is not just closure — it is a learning opportunity. The Scrum Master's job is to extract the lesson that prevents the same impediment from recurring.

The 5 Whys technique is useful here: "The impediment was resolved — but why did it occur? And why did that cause happen? And why did that cause exist?" Following the chain of causes often reveals: an undocumented process, a missing ownership agreement, a communication gap, or a tool that doesn't automate something it should. The best impediment resolutions include both a fix for the immediate blocker and a systemic change that prevents recurrence. Teams that only fix the immediate blocker tend to see the same impediments return. Teams that also ask "why" and implement systemic changes improve their impediment rate over time — a metric worth tracking in the retrospective.

Key vocabulary:
• impediment resolution — the confirmed removal of a blocker, including documentation of how it was resolved
• 5 Whys — a root cause analysis technique that asks "why" repeatedly to trace a problem to its systemic cause
• recurrence prevention — a systemic change that addresses the root cause of an impediment so it doesn't reappear

Cross-team syncs are high-risk ceremonies — they are frequently too long, too broad, and attended by too many people, resulting in discussion without action. The Scrum Master's facilitation job is to keep them tight and outcome-focused.

The structure for an effective cross-team impediment sync: (1) State the impediment and its impact precisely (2 minutes); (2) Each team describes their current state and constraints (5 minutes each); (3) Identify the minimal viable agreement that unblocks both teams (10 minutes); (4) Assign owners and deadlines (5 minutes); (5) Confirm next check-in if needed (2 minutes). The critical anti-pattern is "alignment theatre" — a sync that surfaces the problem, discusses it extensively, but ends without a concrete commitment. The Scrum Master's job is to push for specificity: not "we'll work on it" but "Priya will send the API spec by Thursday noon."

Key vocabulary:
• cross-team sync — a short, decision-focused meeting between two or more teams to resolve a shared impediment
• resolution commitment — a specific agreement (who does what by when) that unblocks the impediment
• alignment theatre — a meeting that appears productive (lots of discussion) but ends without concrete action or commitment

'Removing an impediment' in this scenario refers to taking action to directly address and eliminate the issue – in this case, adding the necessary `null` check. The misconception might be that it simply means 'fixing the code,' but it specifically focuses on removing the blockage preventing Alice from continuing her review. It highlights the Scrum Master's role in facilitating a solution.

Sarah's response focuses on recognizing that David's message describes an impediment – something preventing him from completing his work. The key is identifying the block and initiating action to resolve it. The incorrect options represent misinterpretations of Sarah's role: she's not debugging, assigning tasks, or delegating.

The Scrum Master's next step should be to facilitate a discussion regarding the root cause of the problem – the inconsistent dependencies. Simply assigning blame or escalating without understanding the underlying issue is counterproductive. By prompting a conversation about dependency management, the Scrum Master can begin to remove the impediment through shared knowledge and corrective action.

This suggestion focuses on mitigating the *impact* of the recurring impediment – the delays in feedback. While it doesn't necessarily solve the root cause (the stakeholders themselves), it establishes a proactive process to minimize the disruption and its effect on the team's velocity. The other options represent incorrect interpretations or misapplications of Scrum principles.