Gedanken zur Hindernisliste in Scrum

Vor ein paar Tagen haben sich ein paar oose-Kollegen über ihr jeweiliges Verständnis der Scrum-Hindernisliste unterhalten und ich habe einmal die wichtigsten Aussagen (mit meinen Worten) zusammengetragen, wobei wir nicht den Anspruch hatten, einen Konsens zu finden, sondern die verschiedenen Ansichten auszutauschen.

Was ist die Hindernisliste und welchen Zweck hat sie? Eine Hindernisliste ist eine Sammlung von schriftlich formulierten Hindernissen, deren Lösung ein Team besondere Aufmerksamkeit geben möchte. Typischerweise wird die Hindernisliste während des täglichen Teamtreffens und während der Retrospektiven bearbeitet.

Die Hindernisliste ist neben der Planungswand und dem Abarbeitungsdiagramm (Burndown Chart) eine der drei expliziten teamspezifischen Scrum-Artefakte, die im Teamraum stets sichtbar und zugänglich sein sollen.

Eine Hindernisliste ist keine Zu-Tun-Liste, sondern eher eine Problemliste. Sofern sich eine oder mehrere Personen gefunden haben, die sich um die Beseitigung eines Hindernisses kümmern, können diese Personen auf der Liste vermerkt werden.

Die Hindernisliste hat den Zweck, die Aufmerksamkeit der Beteiligten gezielt auf bestimmte Hindernisse (Impediments) zu lenken, um die Wahrscheinlichkeit zu erhöhen, dass sich ein oder mehrere Personen finden und entscheiden, sich der Klärung und Beseitigung des Hindernisses anzunehmen. Es geht also vor allem darum, Hindernisse sichtbar und auf sie aufmerksam zu machen sowie sie zum Kümmern bereit zu stellen.

Größe der Liste. Aus diesem Grunde darf die Hindernisliste nicht zu lang werden, weil sich dann die Aufmerksamkeit zu sehr verteilt und dadurch unfokussiert wird. Die Elemente der Hindernisliste können nach gefühltem Leidensdruck priorisiert werden, um die Fokussierung der Aufmerksamkeit noch gezielter zu steuern.

Es existiert die Gefahr, dass die Hindernisliste zu einer großen Sammlung von „Man müßte mal …“-Punkten wird. Kleinkram gehört nicht auf die Hindernisliste. Wenn die Liste trotzdem zu lang wird, stimmt wahrscheinlich etwas Grundsätzliches nicht (Rahmenbedingungen, Vorgehensweise, Rollenwahrnehmung, Einhaltung der Scrum-Regeln etc.), was dem Scrum Master eigentlich schon hätte auffallen sollen.

Umgang mit den Hindernissen. Manche Hindernisse müssen erstmal „abhängen“ (reifen), bevor eine Lösung sichtbar wird. Bei manchen Hindernissen reicht es bereits, sie ins Bewußtsein zu rufen, um Veränderungen auszulösen.

Die Einträge in einer Hinderliste sollten danach unterschieden werden, ob sie innerhalb (interne Hindernisse) oder außerhalb (externe Hindernisse) des Einflussbereiches des Entwicklungsteams liegen. Die internen Hindernisse sind im Normalfall vom Entwicklungsteam selbst zu lösen, die Lösung der externen Hindernisse wird meistens vom Scrum Master veranlasst. Unabhängig davon, wer die Lösung eines Hindernisses übernimmt, darf das Entwicklungsteam sich nicht darauf verlassen, dass dieses damit weg ist.

Die Elemente der Hindernisliste sind eher transient (flüchtig) als persistent. Anstatt also eine Hindernisliste regelmäßig zu aktualisieren, könnte ebensogut regelmäßig die alte vernichtet und eine ganz neue Liste aufgesetzt werden. Manche Hindernisse erledigen sich im Laufe der Zeit von alleine, werden unwichtiger oder von anderen in der Aufmerksamkeit verdrängt.

Während eine Retrospektive vertraulich ist und die besprochenen Inhalte zunächst einmal grundsätzlich den Teilnehmerkreis nicht verlassen sollen, ist die Hindernisliste prinzipiell auch für andere sichtbar. Die auf der Hindernisliste aufgeführten Punkte sind also die, die der Teilnehmerkreis einer Retrospektive bewußt nach Außen freigibt.

Umgang mit heiklen Hindernissen. Dabei stellt sich schnell die Frage, was mit den heiklen Themen ist, die zwar wichtig genug sind, um auf die Liste zu kommen, deren team-externe Veröffentlichung aber möglicherweise bestehende Konflikte verschärft oder neue auslöst? Hierauf gibt drei Antworten:

1. Sofern ein solches Hindernis auftaucht, ist dies ein Signal an das Team, sich unmittelbar und eingehender mit dem Hindernis zu beschäftigen und die passende Formulierung des Punktes für die Hindernisliste bereits als Teil der Lösung anzusehen. In vielen Fällen geht es erst einmal darum, die eigentlichen Ursachen zu finden und nicht nur auf die Symptome und Folgen zu schauen sowie die eigenen Anteile an dem Hindernis zu erkennen und von den (dann deutlicher formulierbaren) externen Anteilen zu unterscheiden.
2. Der primäre Zweck der Hindernisliste ist, die Aufmerksamkeit des Teams zu fokussieren. Die Einträge auf der Liste sind also Merker für das Team, sie müssen für das Team verständlich sein, nicht aber zwingend für Externe. Heikle Themen können also vorübergehend so abstrakt formuliert werden, dass sie extern eine geringere Reibungsfläche bieten, intern aber dennoch die Aufmerksamkeit des Teams erreichen.
3. Die Hindernisliste ist nur ein Mittel, Hindernisse zu lösen und nicht für jedes Hindernis ist die Hindernisliste das passende Mittel.

Retrospektive, Veränderungsziele, Aufgaben. Die Hindernisliste ist ein Artefakt, das Eingang in die Retrospektive findet und anschließend neu bzw. aktualisiert als ein Ergebnis einer Retrospektive herauskommt. Dabei sollte das Team während der Retrospektive möglicherweise unmittelbar Maßnahmen oder Veränderungsziele vereinbaren, so dass das Team gar keinen Bedarf mehr verspürt, die auslösenden Hindernisse auf der Hindernisliste zu verzeichnen. Dann bleiben vor allem die externen Hindernisse für die Hindernisliste übrig.

Für Lösung mancher Hindernisse ist es ausreichend, wenn das Team sich einfach etwas Bestimmtes vornimmt, sich ein Veränderungsziel setzt. Beispielsweise: „Bevor jemand die Testfälle für ein Akzeptanzkriterium programmiert und der Product Owner gerade nicht da ist, erläutert er einem anderem Teammitglied kurz sein Verständnis davon und läßt die eigene Auffassung von dem Akzeptanzkriterium vom anderen kritisch hinterfragen.“ Solche Absichtserklärungen oder Ziele betreffen die eigene Arbeitsorganisation des Teams, also die Frage, wie das Team die Aufgaben löst, und dazu kann das Team jederzeit eigenständig Vereinbarungen treffen. Dazu bedarf es keiner expliziten Aufgaben in der Iterationsplanung.

Manche Hindernisse erfordern eigens geplante Aufgaben und gehören daher in das Iterationsplanungstreffen mit dem Product Owner. Beispielsweise: „Wir nehmen uns in der nächsten Iteration alle zusammen drei Tage Zeit, um die in Datenbankprozeduren enthaltenen Geschäftsregeln in die clientseitigen Geschäftsobjekte zu verlegen.“ Solche Aufgaben sind dem Product Owner vorzuschlagen, den es davon zu überzeugen gilt, denn er entscheidet über die Prioritäten und den geschäftlichen Nutzen. In der Folge entstehen also ggf. neue Aufgaben, so dass diese Punkte nicht mehr auf der Hindernisliste vermerkt werden müssen.

Sonstiges. Neben der Hindernisliste kann es sinnvoll sein, auch eine Erfolgsliste anzulegen, um sich zu vergegenwärtigen, welche prozessualen und arbeitsorganisatorischen Verbesserungen bereits erreicht wurden.