Und täglich lügt man sich gegenseitig an – „…ich habe keine Impediments“

Kennen Sie die Situation, dass beim Daily die Entwickler reihum ihre drei Fragen durchgehen und auf die dritte Frage stets mit „ich habe keine Impediments“ antworten. Danach geht man wieder an die Arbeit und der ScrumMaster hat einen angenehmen Arbeitstag.
Was läuft in einem solchen Umfeld verkehrt?
Antwort: Die Definition eines Impediments wurde nicht ausreichend verstanden.

Was ist eigentlich ein Impediment (Hindernis)?
Ein Impediment ist ein Ereignis oder ein Zustand, das dafür verantwortlich ist, dass

• ein oder mehrere Teammitglieder nicht effizient genug arbeiten,
• nicht effektiv arbeiten,
• technische Schulden aufbauen,
• gegen einen Scrum-Wert (Offenheit, Mut, Fokussierung, Verbindlichkeit, Respekt) verstoßen,
• eine Scrum-Regel nicht beachten oder
• das unmittelbare Umfeld einen negativen Einfluss hat.

Hierzu ein paar real existierende Beispiele aus meiner Tätigkeit als Agile Coach.

Beispiel 1:
Ein Team wird beim Fertigstellen seiner Aufgaben blockiert, da der Ausfall einer Testumgebung nicht unmittelbar wieder behoben werden kann. Das Team wird durch den Ausfall deutlich verlangsamt und hätte eigentlich schneller seine Aufgaben erledigen können. Hält die Blockade für längere Zeit an, ist das Sprintziel gefährdet.

Beispiel 2:
Der Anteil an möglichen zu automatisierten Tests ist im Verhältnis zur manuellen Testabdeckung zu gering, d.h. es wird zu viel manuell getestet, obwohl die Testautomatisierung aus fachlicher und technischer Sicht erweitert werden könnte. In diesem Fall leidet die Qualität der Software, da Regressionstests am Ende eines Sprints nicht vollständig ausgeführt werden können und der Zeitfaktor unnötigerweise belastet wird. Automatisierte Tests könnten „auf Knopfdruck“ zur Ausführung kommen, müssen aber aufgrund von einem Mangel an Know-how zur Testautomatisierung zeitraubend manuell getestet werden.

Beispiel 3:
Mehrere Teams, die ein gemeinsames Produkt entwickelten und gemeinsam Testdatensätze nutzen, haben die einzelnen Nummernkreise nicht aufgeteilt. Nutzen nun zeitgleich mehrere Entwickler aus unterschiedlichen Teams einen Datensatz, hängt sich bei einem Entwickler die Applikation auf. Es musste der Testfall erneut mit neuem Testdatensatz begonnen werden. Hier liegt ein typischer Fall von Ineffizienz vor, der bei entsprechender Aufteilung der Testdatensätze vermieden werden kann.

Beispiel 4:
Der PO ist sich bei einer zu treffenden Entscheidung unsicher und stellt ausnahmsweise eine Analyse-Story in sein Backlog. Der Entwickler analysiert den Sachverhalt und erstellt ein 12-seitiges Word-Dokument. Bei der Präsentation wird nicht weiter auf dieses Dokument eingegangen und der PO bittet den Entwickler die entscheidenden Kriterien am Flipchart kurz zu visualisieren. Daraufhin wird eine Entscheidung getroffen. Die Zeit, die in die Erstellung dieses Dokumentes investiert wurde, war unnötig und hätte bei einer klaren Definition des Arbeitsumfanges in Form von Akzeptanzkriterien vermieden werden können.

Beispiel 5:
In einem Umfeld, in dem mehrere Teams an einem Produkt arbeiten, ist ein Team frustriert, da es nur noch Wartungsaufgaben erhält und keine innovative Neuentwicklung durchführen darf. Dem PO wurde die Wartung übertragen und somit priorisiert er nur noch Fehler. Dem Vorgesetzten fehlt der Mut, dies dem Team offen mitzuteilen und eine mögliche Lösung gemeinsam mit dem Team zu erarbeiten. Wir erinnern uns, Mut ist ein Scrum-Wert.
Für die Teammitglieder liegt auch hier ein Impediment vor, da sie fortan mit sich selbst beschäftigt sind und viel Zeit mit schier endlosen Diskussionen verschwenden, um mögliche Ursachen, um Aufgabenverteilungen in dem Unternehmen und sich Gedanken machen, um andere Teams, die scheinbar die viel interessanteren Aufgaben erhalten. Diese Zeit der ausufernden Diskussionen hätte besser für die Arbeit am Sprint-Backlog oder für einen fachlichen oder technischen Austausch genutzt werden können.

Auf die ScrumMaster kommt es an
Die Aufgabe eines ScrumMasters besteht darin, diese Impediments zu identifizieren, in einem Backlog transparent zu machen, zu priorisieren und eine Auswahl anhand der Wichtigkeit und Dringlichkeit zu treffen, um deren Beseitigung anzugehen. Die kontinuierliche Arbeit eines ScrumMaster an seinem Backlog verdeutlicht, dass die Rolle des ScrumMasters nicht nur eine Teilzeitbeschäftigung ist, die nebenbei von einem Entwickler mit übernommen werden kann. Vielmehr stellt sie eine herausfordernde Tätigkeit dar mit dem klaren Ziel ein hochperformantes Team zu bilden.

Wenn Sie sich davon überzeugen wollen, ob Ihre ScrumMaster den Begriff des Impediments verstanden haben, laden Sie Ihre ScrumMaster doch heute noch zu einem Meeting ein und jeder soll sein Impediment-Backlog mitbringen.

Fazit
Die Stärke eines Scrum-Teams lässt sich auch daran erkennen, wie es mit Impediments umgeht. Werden diese überhaupt von ScrumMaster und Team als Hindernis erkannt, akzeptiert und auf transparente und ehrliche Weise angegangen. In einem solchen Umfeld beschränkt sich die Identifizierung von Impediments nicht nur auf blockierende Ereignisse und die Aussage der Teammitglieder im Daily „keine Impediments“ stellt eine Ausnahme dar.

Andreas Becker

Kontaktieren Sie Andreas Becker

Andreas Becker ist Agile Transition Coach, Senior Consultant und Trainer bei HOOD GmbH / Agile-by-HOOD. Er begleitet Unternehmen bei der Transition zu agilen Organisationen und unterstützt bei der Implementierung von „Lean Thinking“. Im Fokus seiner Arbeit stehen agile Teams und Business Analysten in agil skalierten Umfeldern. Er ist in der Lean, Agile und Scrum Community aktiv und veröffentlicht Artikel, hält Vorträge und führt Workshops auf internationalen Konferenzen durch und ist zudem Lehrbeauftragter an der Hochschule Rosenheim für "Agile Produktentwicklung". Herr Becker ist zertifizierter Scaled Agile Framework - Program Consultant (SAFe), ScrumMaster und Product Owner. Neben seiner langjährigen Erfahrung im agilen Umfeld hat er in den Bereichen Requirements Engineering, Softwaretest- und Qualitätsmanagement in unterschiedlichen Branchen gearbeitet.