Impediments beseitigen | 5-Schritte + Backlog | Episode 57

📚 Teil der Scrum-Problem-Serie: Dieser Artikel ist Teil unserer Serie über häufige Scrum-Probleme und deren Lösung. Entdecke weitere Herausforderungen wie Team-Dysfunktionen, fehlende Vertrauenswürdigkeit oder organisatorische Hindernisse.

Im Scrum Guide steht: Der Scrum Master ist verantwortlich für die Beseitigung von Impediments/Hindernissen. Was heißt das konkret in Scrum Impediments zu beheben? Wieso ist dieser Fokus auf Impediments so essentiell für eine gute Scrum-Umgebung? Warum tun wir uns oft so schwer damit, diesen Aspekt positiv umzusetzen? Genau darum geht es in diesem Artikel.

🎧 Podcast-Episode: Impediments beseitigen

Vertiefung gefällig? In Episode #57 unseres Podcasts "Scrum meistern" zeigen wir, warum reine "Impediment-Organisation" scheitert, wenn die kulturellen Grundlagen fehlen. Wir diskutieren, wie du als Scrum Master eine Kultur schaffst, in der Hindernisse ohne Angst angesprochen werden können.

Die Aufgaben eines Scrum Masters

Dieser Artikel ist Teil der Serie die Aufgaben eines Scrum MastersMit diesen Artikeln wollen wir einen Überblick über die Handlungsfelder eines Scrum Masters und einen Anstoß für die Ausgestaltung der Rolle des Scrum Masters geben.

Möchtest du mehr über den Scrum Master erfahren?

Auf dieser Seite haben wir alle unsere Informationen zum Scrum Master gebündelt. Hier findest du Antworten zu wichtigen Fragen, vertiefende Podcast-Folgen und aufbauende Artikeln.

zur Seite

Gemeinsam geschrieben mit Marc Bless

Dieser Artikel ist mit Marc Bless – (Certified Enterprise Coach (CEC) und Executive Agile Coach für Business Agility bei agilecoach.de) im Austausch entstanden. Lieben Dank dafür und viel Spaß beim Lesen 😉

Hindernisse als neue & ungewohnte Chance der Optimierung sehen

Viele Organisationen hoffen durch den Einsatz von Scrum ihre Probleme zu lösen, doch Scrum löst kein einziges Problem. Das ist nicht die Aufgabe von Scrum!

Scrum hilft dabei, Probleme und Optimierungspunkte gnadenlos sichtbar zu machen und gibt einen Rahmen, diese als Teil der Arbeit anzugehen oder Hindernisse als Optimierungspotentiale an die Organisation weiter zu tragen. Scrum richtig genutzt, versetzt uns in die Lage, große Optimierungen aus der Konkretheit der aufkommenden Hindernisse durchzuführen und so viele, lange vorliegende Probleme endlich anzugehen.

Was ist ein Impediment (Hindernis) in Scrum?

Als “Hindernis” oder in Scrum “Impediment” bezeichnen wir alles, was uns daran hindert oder ausbremst, schnell, nachhaltig und effektiv Wert für den Nutzer zu liefern.

Allerdings weicht dieses Vorgehen, aus der Transparenz Verbesserungsbereiche offenzulegen, fundamental von vorhergehenden Arbeitsweisen ab, wo aus dem Druck von sportlichen Zielterminen oft kein Platz für Verzögerungen besteht und Hindernisse verdrängt werden. Im besten Fall findet im Projektnachgang eine “Post Mortem Analyse” statt, wenn das Kind längst in den Brunnen gefallen ist und die Erkenntnisse für das nächste, bereits gestartete Projekt gar nicht mehr umgesetzt werden können.

Probleme werden nicht nur verdrängt, sondern unter dem hohen Druck nur halbherzig angegangen. So entsteht eine negative Erfahrung, dass das Angehen von Problemen sowieso nichts bringt und Resignation ist die Folge bei den meisten Beteiligten.

Ausgehend von dieser Ausgangssituation liegt die Herausforderung nicht bloß darin, Hindernisse effektiv anzugehen und zu lösen, sondern eine Kultur zur positiven Nutzung von Hindernissen als Chancen der Optimierung zu schaffen.

Welcher Scrum Master Typ bist du?

Reflektiere dein handeln als Scrum Master mit unserem kleinen Quiz.

7

Fragen

zum Quiz

Als Scrum Master Impediments transparent machen

Anfangs werden Hindernisse oft ignoriert oder nicht ernst genommen. Entsprechend liegt der erste Fokus eines Scrum Masters nicht auf der Beseitigung von Hindernissen, sondern darauf, diese so transparent wie möglich zu machen. Erst dann können sie sichtbar angegangen werden. Dafür muss er jedoch erstmal das notwendige Umfeld schaffen, das Transparenz erlaubt und wertschätzen lernt.. Wenn der Umgang mit Transparenz und Hindernissen für uns so schwierig ist, dann müssen wir einen Rahmen schaffen, in dem diese auch gelebt werden kann.

Fehlende Akzeptanz für Offenheit und Transparenz liegt oft darin begründet, dass die betroffenen Führungskräfte und Teams gar nicht wissen, wofür Scrum überhaupt eingesetzt werden soll. Wird Scrum einfach nur von oben verordnet, dann ergibt sich keine Sinnhaftigkeit für dessen Einsatz. Und damit steigt die Wahrscheinlichkeit, an alten Verhaltensweisen festzuhalten. Zu diesen Verhaltensweisen gehört im Regelfall auch, Probleme zu verschweigen und Fehler unter den Teppich zu kehren. Viele Vorhaben scheitern durch Wegschauen und Intransparenz so spät, dass Budget und Zeit bereits verbraucht sind und wenig Spielraum bleibt, etwas anzupassen. Optimierungspotenziale werden nicht genutzt, weil es keine Klarheit über den aktuellen Stand und die daraus abzuleitenden, kritischen Handlungsfelder gibt. Diese abweichende Herangehensweise in Scrum macht es so wichtig, dass alle Beteiligten wissen, was wir mit Scrum gemeinsam erreichen wollen und warum ein anderes, neues Vorgehen so essentiell ist.

Tipps

Kulturelles Assessment zum Herausarbeiten von Unterschieden in der Haltung

Durch ein kulturelles Assessment kann man die sehr abstrakte Sicht herausarbeiten, was unsere bisherige Handlungsweise und Haltung von der angestrebten unterscheidet und ins Bewußtsein rufen. Ein Assessment auf Basis des Competing Values Framework von Robert Quinn ist hier ein guter Startpunkt.

Reflexion effektiver Teamarbeit

Gute Teamarbeit basiert auf Offenheit und Vertrauen. Ein Bewußtsein über die Notwendigkeit guter Teamarbeit und der Status-Quo schaffen ein gutes Verständnis, worauf es in der neuen Arbeitsweise ankommt. Die Five Dysfunctions of a Team von Patrick Lencioni und das dazugehörige Assessment bilden hier einen guten Startpunkt.

Zielsetzung mit den Stakeholdern abstimmen

Die neue Herangehensweise ist kein Selbstzweck. Wir wollen ein gemeinsames Verständnis schaffen mit dem, was wir erreichen wollen, und warum eine neue Herangehensweise dafür notwendig ist. Als Startpunkt kann hier ein gemeinsamer Workshop zur Aufarbeitung dienen, kombiniert mit informellen Einzelgesprächen mit den Stakeholdern, um ein Bild “worum es wirklich geht” zu schaffen und aufbauend als Orientierung zu nutzen.

Ausrichtung der Teamarbeit auf gemeinsame Herausforderung

Was bedeutet die neue Arbeitsweise im Vergleich zu unseren bisherigen Herangehensweisen und Verhaltensmustern? Was sind Bereiche in unserer Zusammenarbeit, die uns bislang nicht gelungen sind und uns Schwierigkeiten bereitet haben? Was zeichnet für uns eine ideale Aufstellung in Hinblick auf die neuen Herausforderungen aus? Im Scrum Kick-Off können wir durch die Reflexion und Ausrichtung unserer Arbeitsweise auf die neuen Herausforderungen das notwendige Bewusstsein für die Nutzung der neuen Herangehensweise schaffen.

Echte Transparenz setzt psychologische Sicherheit im Scrum Team voraus

Dass Transparenz wichtig ist, wird seit Jahrzehnten in Organisationen als essentiell benannt. Trotzdem funktioniert es so gut wie nie! Warum? Weil die beteiligten Personen sich nicht sicher fühlen und sich nicht trauen, negative Aspekte offen zu benennen. Es herrscht Angst vor persönlichen Konsequenzen (Karriere, Anerkennung, etc.) oder dass andere diesen Sachverhalt als Angriff verstehen. So bleibt es oft im Zustand künstlicher Harmonie mit der ausgesprochenen Annahme, dass “bei uns im Team alles in Ordnung” sei.

Es braucht hier in erster Linie die neue Erfahrung für die Teammitglieder, dass Fehler und Schwierigkeiten nicht als zu vermeidende Probleme aufgefasst, sondern sehr wertschätzend und konstruktiv als Verbesserungspotenziale genutzt werden. Die Leute müssen beobachten, wie Transparenz und Offenheit zu einem besseren Zustand führen kann und dass die Überbringer schlechter Nachrichten dafür nicht gefeuert werden.

Tipps

Safety Check in der Retrospektive

Damit Retrospektiven ihren Zweck zum Lernen und Optimieren erfüllen, brauchen wir hier einen offenen Austausch. Um einen sicheren Raum dafür zu schaffen, bietet es sich an, eine Retrospektive mit einem Safety Check(Beschreibung der Übung) zu starten und anonym zu prüfen, wie sicher sich die Beteiligten fühlen und gegebenenfalls einen sicheren Raum zu ermöglichen. Sollte der Safety Check eine sehr hohe Unsicherheit aufzeigen, kann dies ein eigener, großer Punkt auf der Impediment-Liste des Scrum Masters werden. Hier muss dann intensiv mit den Führungskräften zusammen gearbeitet werden.

Vereinbarungen im KickOff

Im Scrum Kick-Off des Teams kann das Thema psychologische Sicherheit adressiert und sensibilisiert werden. Wie verhalten wir uns idealerweise als Team? Was brauchen wir, um Offenheit und Mut im Team zu leben? Konkrete Absprachen setzen den Grundstein für neues Verhalten und schaffen die Möglichkeit, auch kontraproduktives Verhalten und Unsicherheiten zu adressieren.Um konkrete Absprachen im KickOff zu etablieren sind die 8 Ground Rules von Roger Schwarz ein guter Startpunkt.

Gewaltfreie Kommunikation (GFK)

Durch unreflektierte Äußerungen aus bloßen Interpretationen des Verhaltens unseres Gegenübers, schaffen wir ein Klima der Konfrontation. Das hilft uns weder dabei, dem zugrundeliegenden Bedürfnis unserer Äußerung näher zu kommen, noch eine vertrauensvolle Umgebung zu fördern. Konstruktive Lösungsansätze zur Zufriedenheit aller Beteiligten können so kaum entstehen. Gewaltfreie Kommunikation (GFK) liefert einen Rahmen, Bedürfnisse in einer Form zu adressieren, damit gegenseitiges Verständnis und darauf aufbauend konstruktive Lösungen entstehen können.

Vorleben der Führungskräfte

Eine Führungskraft setzt durch ihr Verhalten die Orientierung in der Interaktion miteinander. Wie offen und selbstkritisch schaut man auf sich selbst? Wie wird mit Fehlern und Missgeschicken umgegangen? Wie wird auf verletzendes und attakierendes Verhalten von Mitarbeitern reagiert? Die Wahrnehmung der jeweiligen Verhaltensweisen der Führungskraft setzt die Maßstäbe für die Interaktion bei den Mitarbeitern.

Beseitigung von Hindernissen organisieren

Die verfügbare Transparenz muss nun dazu genutzt werden, das Arbeitssystem zu inspizieren, um Hindernisse zu identifizieren und aus dem Weg zu räumen. Dies geschieht sowohl in der täglichen Arbeit des Scrum Masters durch seine Beobachtung, als auch durch das Team selbst während entsprechender Aktivitäten in den gegebenen Scrum Events.

Tipps

Der Scrum Master ist dafür verantwortlich, dass Impediments gelöst werden

Die Aufgabe des Scrum Master ist zuallererst dafür zu sorgen, dass Hindernisse erkannt und angegangen werden. Auch wenn der Scrum Master dafür verantwortlich ist, dass dies geschieht, muss er nicht jedes Hindernis alleine angehen. Scrum ist ein Teamsport und jeder aus dem Scrum Team kann mit eingebunden werden, um hier Problemstellungen anzugehen. In gleichem Maße können Hindernisse über den Kontext des Scrum Teams hinaus gehen. Dann ist es Aufgabe des Scrum Masters, diese mit Hilfe und Unterstützung der Organisation und des Managements zu lösen.

Impediment Backlog

Zur Organisation von Impediments kann der Scrum Master ein Impediment Backlog nutzen. Ähnlich wie in einem normalen Backlog wird darin eine Übersicht über die aktuellen Hindernisse und deren Bearbeitungszustand gehalten.

Das ist insbesondere dann wichtig,

• wenn wir sowohl das Scrum Team als auch das Umfeld in die Behebung von Hindernissen mit einbinden wollen
• wenn wir uns in der Vielzahl von Hindernissen organisieren und klare Schwerpunkte setzen wollen
• wenn wir bei komplexeren Hindernissen und Abhängigkeiten nicht durch einfache Maßnahmen, sondern nur mit Nachsetzen zu Lösungen kommen
• wenn wir zum Scrum Team transparent machen wollen, dass das Einbringen von Hindernissen und Verbesserungspotentialen auch wirklich aufgegriffen wird.

Achtung! Wie bei einem Product Backlog besteht jedoch auch hier die Gefahr, den Wald vor lauter Bäumen nicht mehr zu sehen. Ein Impediment Backlog muss genau so nach Value sortiert sein, damit wir jederzeit wissen, welches gelöste Impediment Item unserem Team nun den höchsten “Team Value” liefert. Andernfalls laufen wir Gefahr, stupide eine lange Liste beliebiger oder sogar vermeintlicher Impediments abzuarbeiten.

Retrospektiven

Durch die Retrospektiven schaffen wir eine regelmäßige Reflexion der Arbeitsweise. In dieser werden aus der geschaffenen Transparenz Problemstellungen und Hindernisse gemeinsam im Scrum Team aufgearbeitet und konkrete Massnahmen für den nächsten Sprint abgeleitet. Ohne diesen regelmäßigen Reflexionspunkt würden wir viele der Themen als gegeben ansehen und nicht angehen. In dieser Form helfen uns Retrospektiven, die Verbesserung und damit auch die Behebung von Hindernissen als Teamsport zu betreiben.

Improvement Items als Teil des Sprint Backlogs

Verbesserungen sind in Scrum genauso wichtig wie die “echte” Arbeit in der Schaffung neuer Ergebnisse. Oft verlieren diese Verbesserungsmaßnahmen aber ihre Präsenz durch den hohen Druck etwas aus der täglichen Arbeit zu liefern. Durch die Integration von Verbesserungsmaßnahmen in das Sprint Backlog werden diese konkretisiert und sind im Sprint genauso präsent wie die normalen Backlog Items. So gewährleisten wir im Team, dass mit der Arbeit im Sprint Verbesserungen konsequent umgesetzt werden.

Was fördert Transparenz in der Arbeit mit Scrum?

Priorisierung des Product Backlogs nach Business Value

EinProduct Backlog, das an den Bedürfnissen des Businesses ausgerichtet ist und nicht an den Verfügbarkeiten und Fähigkeiten im Team, macht sehr schnell sichtbar, ob wir in der Lage sind, wertvolle Ergebnisse zu liefern.

• Können wir unsere Kräfte an den obersten Items bündeln, um schnell Ergebnisse zu liefern?
• Wo können einzelne Experten zu potentiellen Engpässen werden?
• Wo fehlen uns Fähigkeiten und Zuarbeiten?

Aus der Transparenz ergeben sich konkrete Handlungsfelder, die unsere Fähigkeit erhöhen, Wert in Richtung der Business-Interessen zu liefern.

Unabhängiger Pull des Sprint Umfangs im Sprint Planning

Durch das aufoktroyieren des Umfangs eines Sprints erfolgt eine Art resignierter Gehorsam. Es wird nicht hinterfragt, ob wir alles vorliegen haben und in der Lage sind, Backlog Items erfolgreich umzusetzen.

Durch die Vermeidung von Vorgaben oder gut gemeinte “Hinweise” zum Sprint-Umfang durch den Product Owner, sowie eine effektive unabhängige Auswahl des Sprint Backlogs durch das Team wird deutlich, welche Themen als unausgereift für die Umsetzung im Sprint gesehen werden.

Burn Down Chart nach Anzahl abgeschlossener Backlog Items statt nach Tasks

Am schwierigsten ist das wirkliche Finalisieren von Funktionalitäten. Ein Fortschritt Monitoring, das Herausforderungen transparent macht, muss hier den Schwerpunkt haben.

Ein Burn Down Chart, das den Fortschritt nur bezüglich abgeschlossener Backlog Items darstellt, zeigt uns den wahren Zustand des Sprint Backlogs: was ist tatsächlich fertig im Sinne einer Definition-of-Done und was ist noch nicht fertig? Im Gegensatz dazu suggeriert ein Burn Down Chart auf Basis von Tasks den Fortschritt der Abarbeitung der bekannten, kleinteiligen Tätigkeiten, ohne den entscheidenden Knackpunkt der 100% Finalisierung von Funktionalitäten zu visualisieren.

So wirft ein gutes Burn Down Chart beispielsweise folgende Fragen auf:

• Was fehlt zum Abschluss des nächsten Backlog Items?
• Wo haben wir Probleme? Wo müssen wir uns zusammenraufen? Wo müssen wir uns Hilfe holen?
• Schaffen wir das noch in diesem Sprint?

Review mit echtem Produkt unter Einbindung relevanter Stakeholder

Inwieweit haben wir ein nützliches und wirklich einsetzbares Produkt für unsere Anwender geschaffen? Wie wird dieser minimale Stand als passend zu den Bedürfnissen der Nutzer gesehen? Durch die Lieferung eines potentiell einsetzbaren Ergebnisses und die Reflexion dieses Ergebnisses mit relevanten Stakeholder können wir Klarheit zu diesen Fragestellungen schaffen.

Einordnung und Bewertung des Inkrements in den größeren Kontext des Produktes

Nur wenn das Entwicklungsteam den Kontext unseres Produktes versteht, kann es auch mitdenken und seine Sicht zu diesen Themen frühzeitig mit einbringen. Durch die Einordnung des Inkrements in den größeren Kontext des Produktes im Sprint Review, kann dieses Verständnis forciert werden. Dies setzt natürlich voraus, dass der Product Owner das Entwicklungsteam so gut abgeholt hat und sie damit dann überhaupt eine Chance haben, das Inkrement in Bezug zum Produkt-Kontext zu setzen.

Bewertung von Risiken als Teil des Sprint Reviews

Wenn wir nur über Funktionalitäten und wichtig zu haltende Liefertermine reden, dann brauchen wir uns nicht wundern, wenn die Lieferung von Qualität und frühe Auflösung von Risiken keine Präsenz in der Entwicklung hat.

Durch die Reflexion, Bewertung und Diskussion von nicht funktionalen Anforderungen entsteht ein gemeinsames Verständnis über den aktuellen Stand und die Notwendigkeit, hier nachzubessern.

“Information Radiators” zum technischen Zustand unseres Produktes

Wir wollen im Team stets Informationen über den Zustand unseres Systems einsehen können. Dafür eignen sich sogenannte “Information Radiators” in Form von gut sichtbaren Displays und Dashboards im Teamraum.

Automatisierte Auswertungen mit frühem Feedback zur Qualität des Codes, der Tests, sowie Fehler in der “Continuous Integration” schaffen Sichtbarkeit und geben durch schnelle Rückmeldungen die Möglichkeit, Mängel direkt dann zu beheben, wenn sie entstehen.

Außensicht auf das Team einholen

Was wird von unserem Umfeld als wichtig angesehen? Wie sind wir dazu aufgestellt? Wo gibt es potentiell Unzufriedenheiten? Diese Themen zu kanalisieren und mit dem Scrum Team den Stand zu besprechen, schafft ein ganz neues Level für gemeinsames Handeln.

Dazu können wir uns regelmäßig das Feedback von Führungskräften, Stakeholdern, Kunden und Anwendern ins Team holen. Als externe Informationsquelle in Retrospektiven bieten sie eine äußerst wertvolle Außenperspektive, die dem Team in der Selbstwahrnehmung oft verborgen bleibt.

Impediments in der Praxis: 3 Typen verstehen und lösen

Nicht alle Impediments sind gleich. In der Praxis lassen sich drei Haupttypen unterscheiden, die jeweils eigene Lösungsansätze erfordern:

1. Team-Interne Impediments: Transparenz & Psychologische Sicherheit

Typische Beispiele:

• Unklare Definition of Done
• Fehlende oder ineffektive Retrospektiven
• Probleme werden nicht angesprochen (Angst-Kultur)
• Team arbeitet in Silos statt gemeinsam

Die Herausforderung: Das größte Impediment ist oft nicht technischer Natur, sondern kulturell: Teams haben gelernt, dass das Ansprechen von Problemen sanktioniert wird. Ohne psychologische Sicherheit bleibt das Impediment Backlog leer, egal wie gut du es organisierst.

Der Lösungsweg:

• Safety Check in Retrospektiven einführen
• Vorleben von Transparenz durch Führungskräfte
• Kleine Erfolge sichtbar machen ("Seht, wir haben Problem X gelöst!")
• Vom Responsibility Process profitieren (nicht Opferhaltung, sondern Eigenverantwortung)

🎧 Vertiefung: In Episode #57: Als Scrum Master Hindernisse beseitigen zeigen wir, wie du eine Kultur schaffst, in der Impediments ohne Angst angesprochen werden. Wir diskutieren, warum reine "Impediment-Organisation" scheitert, wenn die kulturellen Grundlagen fehlen.

2. Technische Impediments: Wissens-Bottlenecks & Code-Qualität

Typische Beispiele:

• "Bob ist der Einzige der Modul X anfassen kann"
• Legacy Code ohne Tests (keiner traut sich ran)
• Langsame CI/CD Pipeline (>30 min Build)
• Fehlende technische Dokumentation

Die Herausforderung: Experten haben ihre Bereiche oft für sich selbst optimiert, nicht für Team-Zugänglichkeit. Unter Stress fallen alle in alte Muster zurück: "Finger weg von meinem Code!" Allgemeine Appelle wie "Wir müssen Wissen teilen" verpuffen, weil der konkrete Bedarf fehlt.

Der Lösungsweg:

• Product Backlog nach Business Value priorisieren (nicht nach Skills!)
• Skill-Matrix visualisieren → Bottlenecks werden sichtbar
• Code-Qualität verbessern (Tests = Sicherheitsnetz für andere)
• Pairing/Mob Programming bei high-value Items

🎧 Praxis-Story: Episode #85: Hilfe, unsere Experten werden zum Bottleneck! - Warum gut gemeinte "Wissensaustausch-Sessions" scheitern und wie du den konkreten Bedarf für Skill-Aufbau sichtbar machst.

3. Organisatorische Impediments: Außerhalb des Teams

Typische Beispiele:

• Product Owner nicht verfügbar (zu viele Teams)
• Fehlende Budget-Freigaben
• Langwierige Change-Prozesse (6 Wochen für Server-Zugriff)
• Organisatorische Silos blockieren Zusammenarbeit

Die Herausforderung: Diese Impediments lassen sich nicht vom Team alleine lösen. Sie erfordern Eskalation, politisches Geschick und oft cross-funktionale Zusammenarbeit über Team-Grenzen hinweg. Der klassische Fehler: Der Scrum Master versucht, alles alleine zu lösen.

Der Lösungsweg:

• Impediment Backlog mit klarer Ownership (Wer eskaliert?)
• Transparenz gegenüber Stakeholdern (im Sprint Review zeigen: "Das konnten wir nicht liefern, weil...")
• Cross-funktionales Transition-Team für organisatorische Probleme
• Konkretes Mandat mit Führung klären (Was dürfen wir ändern?)

🎧 Eskalations-Guide: Episode #88: Hilfe, mein Product Owner wird zum Bottleneck! - Die 3 Warnsignale für einen PO-Bottleneck und wie du als Scrum Master systemisch (nicht nur 1:1 Coaching) hilfst.

Impediment Backlog: Hindernisse tracken und priorisieren

Nicht jedes Impediment lässt sich sofort lösen. Manche brauchen Wochen oder Monate. Deshalb führen viele Teams ein Impediment Backlog - eine priorisierte Liste von Hindernissen, die systematisch abgearbeitet werden.

Was gehört ins Impediment Backlog?

✅ Ja - gehört rein:

• Blocker die länger als 1 Sprint brauchen (z.B. neue Server-Infrastruktur)
• Organisatorische Hindernisse die Eskalation brauchen (z.B. Budget-Freigaben)
• Technische Schulden die dedicated Zeit benötigen (z.B. Legacy Code Refactoring)
• Cross-Team Dependencies die koordiniert gelöst werden müssen

❌ Nein - nicht ins Backlog:

• Schnell lösbare Probleme (<1 Tag) → Direkt lösen, nicht tracken!
• Team-interne Themen die das Team selbst lösen kann → Im Sprint Backlog
• "Nice to have" Verbesserungen → Retrospektive, kein Impediment
• Vage Unzufriedenheit → Erst konkretisieren, dann tracken

Impediment Backlog: Praktisches Template

So könnte dein Impediment Backlog aussehen:

Impediment	Typ	Impact	Owner	Status	Eskaliert an
CI/CD Pipeline >30min	Tech	HIGH	SM + Dev Team	In Progress	-
Keine Test-Umgebung verfügbar	Org	CRITICAL	SM	Eskaliert	CTO
PO nur 2h/Woche verfügbar	Org	HIGH	SM	Eskaliert	Management
Legacy Modul X ohne Tests	Tech	MEDIUM	Team	Backlog	-
Fehlende Zugriffsrechte DB	Org	HIGH	SM	Wartend	IT-Security

Wann wird das Impediment Backlog reviewed?

• Täglich im Daily Scrum: Kurzes Status-Update zu kritischen Impediments ("Ist der Server endlich da?")
• Wöchentlich mit Stakeholdern: Review eskalierter Impediments mit Führung/Management
• Sprint-Ende in der Retrospektive: Was haben wir aus gelösten Impediments gelernt? Welche System-Verbesserungen leiten wir ab?

💡 Wichtig: Impediment Backlog ≠ Sprint Backlog! Impediments sind BLOCKER für Sprint-Arbeit, keine Sprint-Arbeit selbst. Der Scrum Master tracked sie separat und sorgt dafür, dass sie nicht vergessen werden.

Wenn Impediments nicht gelöst werden: Erkennungs-Content

Manchmal liegt das Problem nicht bei den Impediments selbst, sondern bei den Rahmenbedingungen:

🚨 Impediments werden ignoriert oder heruntergespielt?

Oft liegt es nicht an den Impediments, sondern daran, dass dir als Scrum Master niemand zuhört. Symptome:

• "Das ist halt so, damit müssen wir leben"
• "Zu komplex, können wir nicht ändern"
• Deine Eskalationen laufen ins Leere

→ Das ist ein Symptom mangelnder Vertrauenswürdigkeit. Lies: Warum dir als Scrum Master niemand zuhört (und was du tun kannst)

🤝 Product Owner blockiert Lösungen oder priorisiert Impediment-Beseitigung nicht?

Die Zusammenarbeit zwischen Scrum Master und Product Owner ist kritisch für effektive Impediment-Beseitigung. Wenn der PO:

• Keine Zeit für Impediment-Beseitigung im Sprint einplant
• "Erst Features, dann Probleme lösen" sagt
• Technische Schulden nicht als Business Value sieht

→ Das ist ein Zeichen, dass die SM ↔ PO Zusammenarbeit nicht funktioniert. Lies: Wie du als Scrum Master den Product Owner unterstützt

🏢 Die Organisation selbst ist das größte Impediment?

Manche Blocker liegen komplett außerhalb des Teams und sogar außerhalb der Einflusssphäre des Scrum Masters:

• Lange Entscheidungswege (6+ Wochen für einfache Freigaben)
• Silos zwischen Abteilungen
• Fehlende Mandate für Veränderungen

→ Das sind systemische Probleme. Lies: Wie du als Scrum Master das Umfeld des Teams optimierst

Hindernisse innerhalb der Organisation lösen

Scrum hilft dabei, Probleme transparent zu machen und gibt dem Scrum Team den Rahmen, die Probleme in ihrer eigenen Einflusssphäre zu lösen. Ein großes Optimierungspotential liegt in der Behebung von Hindernissen, die außerhalb des Scrum Teams liegen. Die Aufgabe des Scrum Masters ist es sicherzustellen, dass diese Hindernisse in der Organisation adressiert und angegangen werden.

Hindernisse als Chance zur Optimierung

Im Konformitätsdruck, Lieferzusagen einzuhalten, sind die meisten Umgebungen es nicht gewohnt, Hindernisse positiv als Chance zur Optimierung zu sehen. Es fehlt ein Bewusstsein, diese Hindernisse in ihrer Konkretheit als Handlungsbereiche für Verbesserungen zu sehen. Erst durch die Sichtbarkeit werden die Potentiale in der Organisation greifbar und adressierbar.Als guter Scrum Master sensibilisieren wir das Umfeld bei der Einführung von Scrum über Scrums Eigenschaft, Optimierungen aus der Offenlegung von Hindernissen anzugehen und sorgen dafür, dass die Organisation dafür aufgestellt ist, diese Hindernisse als Gelegenheit der Optimierung aufzulösen.

Hindernisse kennen keine Zuständigkeiten und Hierarchien

Viele Hindernisse, die wir im Scrum Team nicht selbst lösen können, lassen sich oft auch nicht durch einzelne Führungskräfte lösen. Sie betreffen mehr als einen Zuständigkeitsbereich und es bedarf einer gemeinsamen Anstrengung, diese Hindernisse aufzulösen.

Durch den Aufbau eines cross-funktionalen Teams mit allen Fähigkeiten, solche Herausforderungen anzugehen, schaffen gute Scrum Master einen Anlaufpunkt für diese anspruchsvollen Problemstellungen. Anfangs kann dies als Regeltermin mit allen betroffenen Akteuren gestartet werden, später kann aus diesen Eindrücken die Lösung der Probleme in ein Scrum Team überführt werden. Dieses Scrum Team, das organisatorische Probleme löst, kann die notwendigen Erfahrungen schaffen für den Aufbau eines wirkungsvollen Transition Teams.

Resümee

Ein Hindernis ist alles was ein Scrum Team verlangsamt oder davon abbringt, früh und nachhaltig Mehrwert für den Endkunden zu liefern. Die Unklarheit, was ein Hindernis oder in Scrum Impediment ist, ist ein Indikator für die mangelnde Transparenz in der Umgebung, der uns davon abhält, effektiv Wert zu liefern. In den meisten Organisationen gibt es so viel Optimierungspotential, dass es ab einem gewissen Maß an Transparenz keinen Definitionsbedarf zu dem Begriff gibt, sondern den Bedarf, die Auflösung der vielen Stolpersteine aktiv zu organisieren. In der Konsequenz ist es deine Aufgabe als guter Scrum Master, dabei zu helfen, hier eine transparente Umgebung zu schaffen, in der die Hindernisse und Potentiale sichtbar sind und gemeinsam aktiv angegangen werden können.

Ressourcen & Weiterführendes

📚 Grundlagen & Übersichtsartikel

Impediments in Scrum: Tipps und Strategien

• acquisa.de/magazin/impediments-scrum
• Umfassender deutscher Überblicksartikel mit praxisnahen Tipps zur Identifikation (auch schwache Signale), typische Kategorien und Analyseverfahren wie Ishikawa-Diagramme.

The Scrum Master as an Impediment Remover

• scrum.org/resources/blog/scrum-master-impediment-remover
• Autorisierte Scrum.org-Ressource: Unterscheidung zwischen "Blocks" (einzelne Task) und "Impediments" (Team-Barriere), plus praktische Tools wie Impediment Board.

Impediments in Scrum – Was ist das & Wie man damit umgeht

• agilescrumgroup.de/impediments-in-scrum
• Aktuelle deutsche Ressource (2025) mit praktischen Tipps zur Visualisierung und Integration in Retrospektiven.

Hürden gibt es immer: Impediments richtig managen

• teamprove.de/blog/impediments-richtig-managen
• Bewährte praktische Methode aus Workshops mit konkreten Beispielen (Raumtemperatur, Skill-Mängel, fehlende PO-Erreichbarkeit).

🛠️ Praxis, Eskalation & Strategien

Escalating and Removing Impediments: The Scrum Master's Guide

• artisanagility.com/blog/escalating-and-removing-impediments
• Moderne Anleitung mit klaren Best Practices zur Eskalation: "Zero Tolerance für Blocker", Empowerment, schnelle Maßnahmen, Eskalationsmuster mit Fakten/Evidenz.

Die Pyramide der Impediments

• valuerise-consulting.de/die-pyramide-der-impediments
• Visualisiert Impediment-Schichten: (1) Methode/Framework, (2) Teamdynamik, (3) Organisatorische Prozesse. Strategisches Framework für Priorisierung.

Impediments in agilen Projekten wirkungsvoll managen

• rolandwanner.ch/impediments-in-agilen-projekten
• Flipchart-Methode für Retrospektiven: Team-Impediments (selbst lösbar) vs. Organisations-Impediments (SM Backlog). "Zwei-Listen-Modell".

📊 Messung & KPIs

Scrum Master Performance KPIs – Impediment Measurement

• echometerapp.com/scrum-master-performance
• Konkrete KPIs: Anzahl identifizierter & gelöster Impediments pro Sprint, Velocity-Verbesserung, Sprint-Erfolgsquoten, Team-Happiness. Impediment Log in Jira aufbauen.

How To Discover and Solve Impediments in Scrum

• betterchange-consulting.com/how-to-discover-and-solve-impediments
• KPI-Framework: Identifizierte & gelöste Impediments, Produktivitäts-Impact, Rückfallquoten, Team-Feedback für kontinuierliche Verbesserung.

🎥 Videos

Scrum Master als Impediments Remover

• [youtube.com/watch?v=fnpr9Jt0Y6w](
• Hochproduziertes Video (6 Min): Relationship Building mit Managern, Fragen stellen statt direkt zu lösen, Impediments früh ansprechen.

How Does a Scrum Master Help a Blocked Scrum Team?

• [youtube.com/watch?v=lgbC7ZaH1Mc](
• Kurze Anleitung (7 Min) von "Agile for Humans": ZERO TOLERANCE für organisatorische Impediments, schnelle Eskalation.

📚 Bücher

Agiler Coach – Skills und Tools

• managerseminare.de/Agiler-Coach-Skills-und-Tools
• Umfassendes deutsches Fachbuch von Claudia Thonet. Ordnet Impediment-Management in Mindset, Skillset, Toolset. Mit Canvas-Vorlagen und Download-Ressourcen.

Agiles Produktmanagement mit Scrum

• dpunkt.de/agiles-produktmanagement-mit-scrum
• Standardwerk von Roman Pichler. Behandelt SM-PO-Zusammenarbeit bei organisatorischen und Priorisierungs-Impediments.

🎧 Podcasts

Scrum meistern Podcast – Folge #34 "Der Scrum Master"

• enablechange.de/podcast
• Von Ralf Kruse. Kernaufgaben des SM inkl. Impediment-Beseitigung. Mit kostenloser Scrum Checkliste (Impediment-Feld).

🛠️ Tools & Templates

Scrum Excel Vorlage mit Impediment Tracking

• excelvorlage.de/scrum
• Kostenlose Excel-Vorlage für Scrum-Teams mit Impediment-Tracking, Sprint Planning, Task Board. Anfängerfreundlich und flexibel anpassbar.

ScrumDesk – Enterprise Impediment Tracking Tool

• scrumdesk.com/start/manual
• Professionelles Agile-Management-Tool mit visuellem Impediment Flag im Backlog. Freemium-Modell für kleinere Teams.

Für all die Scrum Master, die sich gern weiterbilden und mit ihren individuellen Herausforderungen wachsen möchten, bieten wir ein arbeitsbegleitendes Advanced CSM Coaching an. Mehr dazu findet ihr hier!