Haben Sie sich auch schon gefragt was Impediments in Projekten sind? Wenn Sie in agilen Projekten arbeiten, dann haben Sie diesen Begriff sicher schon öfters gehört. Impediments sind in agilen Projekten die Hindernisse und Probleme jeglicher Art, die das Scrum-Team behindern seine Arbeit effektiv auszuführen. Eine der vielen Aufgaben eines Scrum Masters in einem Scrum-Projekt ist es, die Developer zu unterstützen Impediments zu identifizieren, zu dokumentieren und mitzuhelfen diese zu beseitigen. In diesem Beitrag erhalten Sie eine umfassende Einführung was Impediments sind, wie Sie diese identifizieren, dokumentieren und beseitigen.
Was sind Impediments?
Selbst im normalen Projektalltag (ohne den Einsatz von Scrum) gibt es Impediments. In diesem Fall sind es einfach Probleme oder Issues, die das Projekt bzw. das Projektteam daran hindern mit der Arbeit voran zu kommen. Diese Probleme müssen genauso gelöst werden, wie in Scrum die Impediments. Je weniger Hindernisse dem Projektteam im Weg liegen, desto effizienter kann es arbeiten. Dieses Zitat trifft es auf den Punkt:
An Impediment is anything that keeps the Team from getting work Done and that slows velocity.
Verschiedene Arten von Impediments
Vermutlich denken Sie bei Impediments zuerst an technische Hindernisse, aber es gibt viele verschiedene Arten von Hindernissen. Es sind nicht nur “langsame PCs”, “Technologie X ist nicht großartig” oder “Server stehen nicht zur Verfügung”. Sie arbeiten auch mit Menschen zusammen, anderen Teams, Kunden, dem Management und anderen Stakeholdern – und hier werden Sie wahrscheinlich mit Impediments viel öfters konfrontiert. Nachfolgend finden Sie ein paar Kategorien von Impediments, die mir spontan in den Sinn kommen:
Technische Impediments: Der Mainframe funktioniert am Wochenende oft nicht. Die verwendeten PC’s sind zu alt und zu langsam usw. “Warum spinnt meine Maus schon wieder!”
Team-Member Impediments: Persönliche oder familiäre Probleme oder fehlende Erfahrung eines Team-Mitgliedes, welche die Leistung des Team-Mitgliedes negativ beeinflussten. Ein Teammitglied ist wegen eines Unfalls für mehrere Wochen abwesend.
Team-Impediments: Team-Impediments sind schwieriger zu erkennen und haben oft die größte negative Auswirkung auf die Produktivität des Teams. Einzelne Team-Mitglieder dominieren z.B. in Planning Sessions. Die Moral oder das gegenseitige Vertrauen im Team ist auf einem Tiefpunkt. Der Product Owner erfüllt seine Aufgabe nicht ausreichend. Er pflegt das Product Backlog nicht, oder nur unzureichend.
Prozess-Impediments: Das Agile Manifesto Statement: “Individuen und Interaktionen über Prozesse und Werkzeuge” bedeutet nicht, dass es keine Prozesse gibt. Diese Art von Impediments könnten sein: “Der Code Review Prozess ist schlecht definiert und das Aufwand-Nutzen Verhältnis daraus ist schlecht”. Process Impediments werden oft auch in der Sprint-Retrospektive identifiziert.
Organisatorische Impediments: Diese sind oft leicht zu identifizieren, sind aber oft nicht einfach zu lösen, da sie oft außerhalb der Kontrolle des Teams liegen. Teammitglieder werden z.B. immer wieder von Linien-Aktivitäten gestört. Entscheide werden vom Management immer wieder aufgeschoben. Das Team besteht aus 6 Personen, muss aber in einem Raum arbeiten, der nur für maximal 4 Personen konzipiert ist.
Stakeholder-Impediments: Hier geht es um Stakeholder, die zu viel Einfluss auf das Projekt nehmen; User, welche die Teammitglieder immer wieder mit Fragen beanspruchen oder der Kunde, der seine Anforderungen immer wieder während des Sprints ändert.
Identifizieren und Dokumentieren von Impediments
Impediments sollten Sie jederzeit identifizieren und dokumentieren. Zwei Scrum-Events sind jedoch ideal dafür: das Daily Scrum und die Sprint-Retrospektive.
Im Daily Scrum sollten aktuell auftretende Impediments sofort angesprochen werden. Diese werden vom Scrum Master während des Meetings am besten auf einem Flipchart, mit Datum und eventuellem Lösungsvorschlag festgehalten. Am Ende des Daily Scrum kann dann der Status aller Impediments kurz überprüft und aktualisiert werden.
Impediments werden natürlich nicht nur vom Scrum Master identifiziert, sondern vom ganzen Scrum-Team. Der Scrum Master ist jedoch sensibilisiert auf Impediments und hilft dem Team diese zu identifizieren und zu beseitigen.
Impediments in der Retrospektive identifizieren
Auch in der Retrospektive identifiziert das Scrum-Team Impediments. Dies wird oft mit einem kurzen Brainstorming gemacht. Hier ist es vorteilhaft, wenn Sie die Sammlung der Hindernisse und Probleme und die dazugehörigen Maßnahmen gruppieren in:
- Solche, die das Team selbst verändern und verbessern kann
- Solche, die von der Organisation, vom Management oder dem Kunden verändert werden müssen
Dazu nimmt der Moderator ein Flipchart und teilt es in zwei Spalten ein: Team | Organisation. Dann verteilt das Team alle Probleme und die dazugehörigen Maßnahmen in die entsprechenden Spalten. Dazu sollten auch die Impediments aus den Daily Scrum eingefügt werden. Die Liste der Probleme ist oft lang und es gibt Aufwand diese abzuarbeiten.
Die beiden Spalten werden dann vom Scrum Team gemeinsam priorisiert: Welche Hindernisse und Probleme sollten sofort gelöst werden und welche Veränderungen bringen dem Team die höchste Produktivitätssteigerung? Dies machen Sie für beide Seiten auf dem Flipchart für „Team“ und „Organisation“. Damit wird klar, was das Team umsetzen will und was es vom Scrum Master erwartet, was er mit er mit der Organisation verbessern will.
Am Ende der Sprint-Retrospektive haben Sie zwei Listen als Ergebnis:
- Die Liste der Hindernisse und Probleme, die das Team lösen sollte
- Die Liste der Hindernisse und Probleme, die der Scrum Master lösen muss
Um die linke Seite des Flipcharts „Team“ kümmern sich das Developer im nächsten Sprint Planning. Die „Organisations“-Liste wird vom Scrum Master verwaltet und fließt in sein Impediment Backlog ein. Es ist seine Aufgabe, sich um diese so schnell wie möglich, in der entsprechenden Reihenfolge zu kümmern.
Die Maßnahmen sollten Sie sofort nach der Retrospektive anpacken
Das nächste Sprint Planning Meeting ist der richtige Zeitpunkt dazu, darüber zu sprechen, welche Maßnahmen von der Liste im nächsten Sprint angegangen werden sollen und was diese eventuell für einen Aufwand bedeuten. Einige Maßnahmen geben vielleicht keinen Aufwand, weil es Verhaltensänderungen sind.
Um eine kontinuierliche Verbesserung zu gewährleisten empfahl der Scrum Guide 2017 mindestens eine Prozessverbesserung mit hoher Priorität, die in der letzten Retrospektive identifiziert wurde, in das Sprint Backlog aufzunehmen. Ich denke, das ist immer noch eine gute Idee.
Am Ende der nächsten Sprint-Retrospektive überprüfen Sie dann, ob die Maßnahmen umgesetzt wurden, und ob diese auch wirken. Es kann auch sinnvoll sein, für gewisse Maßnahmen einen oder zwei Termine im kommenden Sprint zu definieren, bei denen diese überprüft werden. Dies können zum Beispiel geänderte Verhaltensregeln betreffen.
Nicht nur in der Sprint-Retrospektive überprüfen Sie den Status von Impediments. Diese sollten auch im Daily Scrum periodisch überprüft werden.
Dokumentieren von Impediments
Impediments müssen dokumentiert werden und für das Team sichtbar sein, damit darüber diskutiert wird und diese gelöst werden. Dafür hat sich in der Praxis das Impediment Backlog bewährt. Das kann eine normale Liste auf einem Flipchart sein, eine Excel-Datei, ein Wikieintrag oder Post-It Zettel am Scrum-Board unter einer Spalte namens “Impediments”. Je öffentlicher und schneller Impediments für das Scrum-Team sichtbar sind, desto besser. Wenn man die Impediments täglich sieht, wird darüber gesprochen und dies fördert automatisch deren Lösung.
Es ist eine der Aufgaben des Scrum Masters dem Scrum-Team zu helfen Impediments zu identifizieren, diese zu dokumentieren und – beispielsweise mit Hilfe des Managements – zu beseitigen. Wenn das Impediment Backlog leer ist, stimmt vermutlich etwas nicht. Es gibt kaum ein Projekt, bei dem keine Hindernisse oder Probleme auftreten. Macht hier vielleicht der Scrum Master seine Arbeit nicht?
Das Impediment Backlog
Nachfolgend finden Sie ein Beispiel eines einfachen Impediment Backlogs. Ich würde es in Excel erstellen und dann groß ausdrucken und an oder neben das Scrum Board hängen, damit es immer sichtbar ist. Sie können dies natürlich auf mit Karten machen wie bei User Stories.
Die Einträge im Impediment Backog können Sie mit weiteren Informationen anreichern wie Hinweise zur Lösung der Probleme, mögliche Kennzahlen und Prioritäten, Ansprechpartner für Lösungen oder Zeitfenster. Der Kreativität sind hier wenige Grenzen gesetzt.
Darauf sollten Sie beim Management des Impediment Backlogs achten
Das Impediment Backlog muss sichtbar sein. Das vom Scrum Master verwaltete Impediment Backlog sollte öffentlich einsehbar sein. Denn nur wenn die Hindernisse immer sichtbar sind, wird darüber diskutiert, und so werden sie auch schnell beseitigt und nicht verdrängt.
Ein Impediment Backlog kann nicht leer sein. Jedes Team kann effektiver arbeiten. Wenn das Impediment Backlog leer ist hat der Scrum Master wahrscheinlich noch nicht die Fähigkeit entwickelt Hindernisse und Verletzungspotentiale zu identifizieren.
Im Impediment Backlog ändert sich nichts oder es summieren sich die Einträge. Arbeitet hier der Scrum Master nicht (oder nicht effektiv)? Impediments sollten immer öffentlich diskutiert werden und man sollte sich immer gemeinsam um Lösungen bemühen. Der Scrum Master hat ein Problem, wenn die Impediments immer mehr werden und diese nicht beseitigt werden. Er muss diese priorisieren, eventuell delegieren und Dritte zur Problemlösung hinzuziehen, damit diese möglichst schnell beseitigt werden.
Nicht nur der Scrum Master bemüht sich um die Beseitigung der Impediments und ist allein dafür verantwortlich. Auch ganze Scrum-Team ist dafür verantwortlich. Der Scrum Master koordiniert und delegiert dann die Impediments an die Parteien, die diese am besten lösen können.
Beseitigen von Impediments
Helfen Impediments beseitigen ist nicht nur ein wesentlicher Bestandteil der Arbeit eines Scrum Masters, sondern wahrscheinlich auch eine der besten Möglichkeiten, die Team-Velocity positiv zu beeinflussen. Selbst ein hochmotiviertes, hochqualifiziertes Team wird es schwer haben, wenn die Hälfte seiner Ausrüstung defekt ist, es immer wieder gestört wird oder mit anderen Hindernissen zu kämpfen hat.
Der Scrum Master ist jedoch nicht verantwortlich alle Probleme zu lösen, die die Developer behindern das Sprintziel zu erreichen. Stattdessen sollte der Scrum Master den Developern helfen, dass dieses zunehmend selbst in der Lage ist ähnliche Probleme selbstständig zu lösen (Selbstmanagement). Der Scrum Master tut dies, indem er die Probleme anspricht und das Team bei der Lösungsfindung moderiert.
Die Ursachen für Probleme liegen oft tiefer. Versuchen Sie deshalb auch die Grundursachen für Probleme zu finden.
Viele Probleme können die Developer selber lösen, wie z.B. unklare Spezifikationen klären oder Probleme mit anderen Teammitgliedern lösen. Organisiert sich Developers wirklich selbst, wenn sie für alle auftretenden Probleme einen Scrum Master benötigen diese zu lösen? Ein Scrum Master, der die meisten Probleme löst, tut den Developern keinen Gefallen. Er oder sie behindert aktiv die (wachsende) Fähigkeit de Developer, ihre eigenen Probleme zu lösen.
Scrum Masters lösen also nie Probleme? Bedeutet das, dass ein Scrum Master nie Probleme löst? Natürlich nicht. Scrum Master sind immer noch Teil des Scrum Teams. Vielleicht repariert ein Scrum Master den Wi-Fi-Router, wenn sich die Developer ganz auf die Lösung eines großen technischen Problems konzentrieren. Bestimmte organisatorische Impediments, z.B. mit dem Unternehmens-Management kann z.B. der Scrum Master oder der Product Owner am Besten beseitigen.
A Scrum Master should reveal, not resolve.
Nicht immer ist es möglich Impediments schnell zu beseitigen. Abhängig von der Größe des identifizierten Hindernisses kann die Problemlösung länger dauern. In jedem Fall sollte der Fortschritt zur Problemlösung sichtbar gemacht und im Team besprochen werden. Generell gilt: Impediments sollten zügig gelöst werden. Wenn Impediments zu lange nicht gelöst werden, leidet nicht nur der Arbeitsfortschritt, es kann auch das Team frustrieren und demotivieren. Es gibt auch keinen Grund auf das nächste Daily Scrum zu warten, um ein drängendes Problem zu kommunizieren. Fällt der Scanner, die Klimaanlage oder der Computer aus, ist schnelle Hilfe notwendig.
Wie Sie in diesem Artikel gelesen haben, können Impediments sehr vielseitig sein und haben einen negativen Einfluss auf den Arbeitsfortschritt der Developer. Der Scrum Master ist die zentrale Person, wenn es darum geht das Scrum-Team beim Identifizieren und Lösen von Impediments zu unterstützen. Je erfahrener die Developer werden, desto mehr Impediments können und sollen sie selber lösen.
Was haben Sie für Erfahrungen mit Impediments bei agilen Projekten gemacht? Stimmen Sie mit meinen Aussagen überein oder haben Sie eine andere Ansicht oder Ergänzungen? Teilen Sie Ihre Erfahrung mit einem Kommentar den Lesern mit, damit wir alle eine weitere Sicht kennenlernen. Danke!
Wollen Sie mehr erfahren, wie Sie Ihre agilen Projekte noch erfolgreicher machen? Mein Buch Scrum – Agiles Projektmanagement und Scrum erfolgreich anwenden bringt Sie einen wichtigen Schritt weiter!
Kennen Sie jemanden, den dieser Beitrag auch interessieren könnte? Dann leiten Sie ihn einfach weiter oder teilen ihn in Ihrem Netzwerk. Vielen Dank!
