Impediments in agilen Projekten wirkungsvoll managen

Scrum Impediment BacklogHaben Sie sich auch schon gefragt was Impediments 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 Development-Team behindern seine Arbeit effektiv auszuführen. Eine der vielen Aufgaben eines Scrum Masters in einem Scrum-Projekt ist es, das Development-Team 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. 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: „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 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 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 der Besprechung 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 Development-Team und vom Product Owner 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 Retrospektive haben Sie zwei Listen als Ergebnis:

  1. Die Liste der Hindernisse und Probleme, die das Team lösen sollte
  2. Die Liste der Hindernisse und Probleme, die der Scrum Master lösen muss

Um die linke Seite des Flipcharts „Team“ kümmert sich das Development-Team 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 1 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 empfiehlt der Scrum Guide 2017 mindestens eine Prozessverbesserung mit hoher Priorität, die in der letzten Retrospektive identifiziert wurde, in das Sprint Backlog aufzunehmen.
Am Ende der nächsten 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 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.

Scrum Impediment Backlog

Das Impediment Backlog bei agilen Projekten

Darauf sollten Sie beim Management des Impediment Backlogs achten

Das Impediment Backlog ist sichtbar. 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. Als Scrum Master ist man nicht allein für die Beseitigung von Hindernissen verantwortlich. Auch das Entwicklungsteam und der Product Owner sind dafür verantwortlich. Der Scrum Master delegiert diese 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 das Development-Team behindert das Sprintziel zu erreichen. Stattdessen sollte der Scrum Master dem Development-Team helfen, dass dieses zunehmend selbst in der Lage ist ähnliche Probleme selbstständig zu lösen (Selbstorganisation). 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 kann das Development-Team selber lösen, wie z.B. unklare Spezifikationen klären oder Probleme mit anderen Teammitgliedern lösen. Organisiert sich ein Development-Team wirklich selbst, wenn es für alle auftretenden Probleme einen Scrum Master benötigt diese zu lösen? Ein Scrum Master, der die meisten Probleme löst, tut einem Development-Team keinen Gefallen. Er oder sie behindert aktiv die (wachsende) Fähigkeit des Development-Teams, seine 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 das Development-Team ganz auf die Lösung eines großen technischen Problems konzentriert. 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 ein negativen Einfluss auf den Arbeitsfortschritt des Development-Teams. 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 das Development-Team wird, desto mehr Impediments kann und sollte es 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!

 

HAT DIR DIESER ARTIKEL GEFALLEN?

Erhalte monatlich meine Blog-Updates und mein kostenloses eBook: Projektplanung

E-Mail Adressen werden vertraulich behandelt und nie weitergegeben

Posted in Agiles Projektmanagement.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.