Jedes agile Team kennt Probleme und Störungen, die den Projekterfolg gefährden. In Scrum-Teams ist es die Aufgabe des Scrum Masters, diese sogenannten „Impediments“ zu erkennen, zu dokumentieren, zu verwalten und idealerweise zu beseitigen. Der Umgang mit Impediments ist anspruchsvoll, denn nicht alle Situationen, die das Team behindern, fallen auf den ersten Blick als Impediments auf. In diesem Artikel stelle ich neben typischen Impediments auch eine Methode vor, die sich in den von uns begleiteten Scrum-Teams bewährt hat.
Was sind Impediments?
Impediments sind Einflüsse oder Hindernisse, …
- die nicht durch die Selbstorganisation innerhalb des Teams beseitigt werden können
- die das Team bei der Arbeit behindern und den Fortschritt verlangsamen
- die die Anwendung des agilen Scrum Frameworks einschränken
- die das Team davon abhalten, noch besser zu werden
Impediment-Beispiele aus dem agilen Arbeitsalltag
- Räumlichkeiten, die keine Face-to-Face-Kommunikation im Team ermöglichen
- Überhitzte Räume im Sommer
- Zu viele kranke Teammitglieder
- Unzureichende technische Ausstattung (z.B. kleine Monitore oder fehlende Testing-Umgebung)
- Schlechte Erreichbarkeit des Product Owners
- Skill-Mängel im Team
- Skill-Mängel beim Scrum Master (z.B. Mediationsfähigkeiten bei Konflikten)
- Fehlendes Commitment des Managements
Transparenz von Impediments
Schritt 1 auf dem Weg zu einem effizienten Umfang mit Impediments ist Transparenz. Das Team muss sich einig sein, dass Probleme aktiv angesprochen werden und eine kontinuierliche Optimierung nur auf Basis regelmäßiger, selbstkritischer Reflektion möglich ist.
„In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.“ (aus dem Agilen Manifest)
Für Scrum Teams hat sich die Retrospektive als regelmäßiges Meeting etabliert. Doch ist es in vielen Fällen nicht sinnvoll, auf die nächste Retrospektive zu warten. Ist das Sprintziel gefährdet, bietet sich das Daily Scrum an, um Hindernisse zu kommunizieren. Ein aufmerksamer Scrum Master wird außerdem auch Impediments antizipieren, die nicht auf der Hand liegen – beispielsweise mangelhafte Konfliktlösung im Team oder Schwächen bei der Priorisierung der Tasks durch den Product Owner.
Der Umgang mit Impediments
Kann ein Problem beim Daily Scrum oder im Rahmen der Retrospektive nicht direkt gelöst werden, muss es in einem Impediment Backlog erfasst werden. Denn summieren sich in Vergessenheit geratene und ungelöste Impediments, ist meist nicht nur das nächste Sprintziel, sondern im schlimmsten Fall das gesamte Projekt in Gefahr. Und selbst bei einem scheinbar unproblematischen Projektverlauf lässt sich meist noch etwas verbessern. Ein vollkommen leeres Impediment Board ist deshalb eher ein Zeichen für ein fehlendes agiles Mindset – die Aufgabe des Scrum Masters wäre in diesem Fall, stärker bei der Problem-Identifikation zu helfen und ein offenes, vertrauensvolles und diskussionsfreudiges Klima zu schaffen.
Ziel ist eine intensive Auseinandersetzung mit Problemen und eine zeitnahe Lösung von Impediments. Wichtig: Auch wenn der Scrum Master die Rolle des „Impediment-Beseitigers“ innehat, so ist er doch nicht allein für die Lösung der Probleme verantwortlich. Ein effizientes Impediment-Management sollte auch im Interesse des Managements liegen, so dass der Scrum Master die nötige Unterstützung – ggf. auch durch zusätzliche Ressourcen oder Hilfe von außen – erhält.
Das Impediment-Backlog
Nach unserer Erfahrung hat sich für die Dokumentation von Impediments eine Tabelle mit folgenden Spalten bewährt:
- Case: Beschreibung des Problems im Kontext des Sprints
- Priority: Wie dringlich ist die Beseitigung des Impediments auf einer Skala von 1 (kann warten) bis 5 (sehr kritisch)? Beispielsweise ist die Bereitstellung von Logs für Produktionsumgebung wichtiger als Logs für die Testumgebung. Aber auch die Häufung von gleichen oder ähnlichen Problemen kann die Priorität der Beseitigung erhöhen.
- Who: Welches Teammitglied / welche Teammitglieder können das Problem lösen? Ist eine konkrete Zuordnung schwierig, sollte zumindest der Kontext des Impediments verständlich dokumentiert werden (z.B. betroffener Server oder eService).
- Stakeholder: Wer hat das Impediment eingereicht?
- Datum: Wann ist das Problem aufgetreten bzw. wann wurde das Hindernis erkannt?
- Solution: Welche Lösungsideen gibt es zur Behebung des Impediments? Entscheidend ist, dass sich Solutions auf die tatsächliche Behebung der Problemursache beziehen und nicht nur einzelne Symptome beseitigen („Heilung statt Linderung“). In Absprache mit dem Product Owner (!) kann auch bereits ein Product Backlog Item für die Verbesserung formuliert werden.
- Status: Welchen Bearbeitungsstand hat das Impediment?
- JIRA Ticket: Sofern Atlassian JIRA genutzt wird, wird in dieser Spalte das zugehörige Ticket der Lösungsidee ergänzt und automatisch eine Nummer generiert, die das genaue Zuordnen von Lösungen zu den einzelnen Impediments ermöglicht.
Ob das Impediment Backlog auf einem Whiteboard visualisiert wird oder mit einem Tool wie JIRA gepflegt wird, ist zweitrangig. Wichtig ist, dass es für das Team jederzeit leicht zugänglich ist und ein Verdrängen oder Vergessen verhindert.
Tipp
Status Quo von Impediments
Der Status der erfassten Impediments sollte in den Retrospektiven regelmäßig überprüft werden. Arbeiten Teams erst seit kurzer Zeit selbstorganisiert und agil, häufen sich anfangs erfahrungsgemäß Impediments – in diesem Fall haben wir gute Erfahrungen mit „Communities of Practice“ gemacht. Ähnlich wie Task Force Teams reflektieren diese in kurzen Abständen (z.B. wöchentlich 30 bis 60 Minuten) mit den betroffenen Teammitgliedern die erfassten Impediments, nehmen neue Probleme auf und stimmen die Umsetzung von Solutions untereinander ab.
Tipp
Fazit
Nicht immer ist es möglich, Impediments schnell und einfach zu beseitigen. Voraussetzung für ein gutes Impediment Management – und damit für einen optimalen Teamflow – sind Mut, Beharrlichkeit, Kommunikationskultur und Transparenz.