Eine der vielen Aufgaben eines ScrumMasters ist die Dokumentation und Beseitung von Impediments in Scrum. Impediments (englische Bezeichnung) sind Hindernisse bzw. Störungen aller Art, die während der Arbeit auftreten und einzelne Team-Mitglieder (oder auch das gesamte Team) an der effektiven Erledigung ihrer Aufgaben hindern.
Kümmert sich niemand um diese Hindernisse ist das Erreichen des Sprint-Ziels unter Umständen nicht mehr gewährleistet. Meistens stößt man während des Daily Scrum Meetings auf mögliche Hindernisse. Entweder, wenn die Teilnehmer selbst darauf hinweisen, oder wenn ein aufmerksamer ScrumMaster erkennt, dass es sich hier um ein Impediment handelt.
Selbst im normalen Projektalltag (ohne den Einsatz von Scrum) gibt es sogenannte Impediments. In diesem Fall sind es einfach Probleme, die das Projekt bzw. das Projektteam daran hindern voran zu kommen. Die müssen genauso gelöst werden wie in Scrum die Impediments.
Impediment Beispiele
Impediments die Störungen im Team verusachen können offensichtlich oder auch weniger offensichtlich, banal oder auch schwerwiegend sein. Es gibt eigentlich kein Scrum-Projekt, wo es das Impediment-Backlog leer ist. Hier ein paar Beispiele:
- Es herrschen sommerliche Temperaturen draußen und auch im Teamraum. Bei über 30 Grad in einem nicht-klimatisierten Raum tut sich das Team schwer mit seiner Arbeit.
- Das Team besteht aus 6 Personen, muss aber in einem Raum arbeiten, der nur für maximal 4 Personen konzipiert ist.
- Einzelne Teammitglieder können sich nicht auf die commiteten Aufgaben konzentrieren, weil das Management sie mit zusätzlichen, nichtbesprochenen Aufgaben aus anderen Projekten belegt. Mit dem Hinweis, diese hätten eine höhere Prio.
- Die Entwickler arbeiten an ihrem Projekt, können ihren hochgeladenen Code aber nicht wirklich testen lassen, weil die entsprechende Testing-Umgebung immer noch nicht eingerichtet wurde.
- Der Product Owner ist sehr beschäftigt und steht dem Team für Rückfragen anstelle der 5 Tage / Woche nur an 1 Tag pro Woche zur Verfügung.
- Das Team besteht aus 10 Personen, arbeitet aber mit einem Tool, für welches das Unternehmen nur eine 5-Mann-Lizenz besitzt. Es kommt zu Verzögerungen weil nicht alle Zugriff auf das einzusetzende Werkzeug haben und sich der Kauf von Zusatzlizenzen in die Länge zieht.
- Das Team benötigt zusätzliche Ressourcen im Projekt. Beispielsweise ist kein Wissen im Bereich Deployment vorhanden.
- Der Product Owner erfüllt seine Aufgabe nicht ausreichend. Er pflegt das Product Backlog gar nicht, oder nur unzureichend.
- Das Team hat mehr offene Aufgaben in Arbeit, als es Team-Mitglieder besitzt. Warum?
- Während des Daily Scrum Meetings gibt es nichts neues zu berichten. Woran kann es liegen das nichts vorwärts geht?
Impediments dokumentieren und beseitigen
Wie bereits erwähnt ist eine der Aufgaben eines ScrumMasters Impediments zu erkennen (bzw. zu identifizieren), diese zu dokumentieren und (beispielsweise mit Hilfe des Managements) zu beseitigen. Ist das Impediment Backlog leer, passt in der Regel irgendetwas nicht. Es gibt kaum ein Projekt, wo keine Probleme auftreten (egal wie banal). Es gibt auch keine Zahlenangaben, wieviele oder wie wenig Impediments vorhanden sein dürfen. Wichtig ist, dass man sich immer um die Beseitigung der aufgetretenen Probleme bemüht.
Impediment Backlog
Die Dokumentation von Impediments findet in einem Impediment Backlog statt. Das kann eine normale Liste sein, ein Excel-Sheet, ein Wikieintrag, ein Ticket in einem Aufgabenmanagement-Tool oder Post-It Zettel am Scrum-Board unter einer Spalte namens “Impediments”.
Wann stellt das Impediment Backlog für den ScrumMaster ein Problem dar?
Wenn es nicht öffentlich einsehbar ist. Wichtig ist, dass das Impediment-Backlog, welches nur vom ScrumMaster verwaltet wird, öffentlich einsehbar ist. Denn nur wenn die Hindernisse immer sichtbar sind, werden sie auch schnell beseitigt und nicht verdrängt.
Wenn das Impediment Backlog leer ist. Es kann nicht sein, dass in einem Team immer alles wunderbar passt. Jedes Team kann effektiver arbeiten. Ist das Impediment Backlog leer, hat der ScrumMaster noch nicht die notwendige Fähigkeit entwickelt Hindernisse zu identifizieren.
Wenn sich im Impediment Backlog nichts ändert. Ändert sich nichts im Impediment Backlog arbeitet der ScrumMaster hier nicht (oder nicht effektiv). Impediments sollte immer öffentlich diskutiert werden und man sollte sich immer gemeinsam um Lösungen bemühen. Es hilft auch hier zu priorisieren.
Wenn sich im Impediment Backlog die Einträge summieren. Werden die Hindernisse mehr und es kommt nicht zur Beseitigung der bereits dokumentierten Probleme hat ein ScrumMaster ein Problem. Er muss sich Prioriäten setzen, Dritte zur Problemlösung hinzuziehen und schnell an der Lösung von Impediments interessiert sein. Sonst ist nicht nur das Sprint-Ziel, sondern auch das komplette Projektvorhaben in Gefahr.
Wenn sich nur der ScrumMaster um die Beseitigung der Impediments bemüht. Als ScrumMaster ist man nicht allein für die Beseitigung von Hindernissen verantwortlich. Es liegt auch im Interesse des Managements und des gesamten Teams, dass das Team voran kommt. ScrumMaster dürfen also auch Dritte zur Problemlösung hinzuziehen, um Hilfe bitten, Lösungen diskutieren und delegieren. Man unterscheidet oft auch zwischen internen und externen Impediments. Interne Impediments können vom Team direkt gelöst werden. Um die Lösung externer Impediments kümmert sich der ScrumMaster entweder allein, oder in Zusammenarbeit mit Dritten.
Fazit
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 bis lange dauern. In jedem Fall sollte der Fortschritt zur Problemlösung sichtbar gemacht oder zumindest mit dem Team und dem Management kommuniziert werden. Generell gilt jedoch, dass alle Impediments zügig gelöst werden müssen. Das schafft Vertrauen in die Rolle und Fähigkeiten als ScrumMaster. Denn in Scrum ist nichts wichtiger als das Team. Das Team sollte gut und effektiv (zusammen) arbeiten können, damit die geplanten Ziele erreicht werden.
Auf unserer Themenseite gibt es weitere Informationen zur Agilen Produktentwicklung.