Die Pyramide der Impediments

Bei der Arbeit mit verschiedenen Kunden beobachte ich ein sich wiederholendes Muster von Impediments. Dieses Muster hängt eng mit dem agilen Reifegrad des Teams (und der Organisation) zusammen. Ich nenne es die „Pyramide der Impediments“.

Pyramide der Impediments

Zu Beginn der Zusammenarbeit mit einem neuen Scrum Team drehen sich alle Fragen darum, was Scrum ist, wie es funktioniert und wie es im ganz konkreten Kontext erfolgreich angewendet werden kann. Ein verstreutes Team könnte zum Beispiel die Frage stellen, wie ein Daily Scrum effizient durchgeführt werden kann. Ein anderes Team könnte die Frage stellen, wie man die Retrospektiven mit mehr Spaß und Erfolg umsetzen kann. Die Fragen variieren natürlich, aber sie ähneln sich immer. Sie bilden die „Basis“ der Pyramide.

Normalerweise muss ich als Scrum Master zeitgleich beginnen, aus Individuen ein Team zu schmieden. Während sie also Scrum erlernen begreifen die Teammitglieder allmählich, dass sie sich gegenseitig vertrauen können und gemeinsam als Team verantwortlich handeln müssen. Typisch sind in dieser Phase Teamkonflikte oder das Beschützen individueller „Königreiche“ im Aufgabenbereich. Diese „Team-Ebene“ formt die zweite Stufe der Pyramide.

Sobald das Team halbwegs gut zusammen funktioniert und auch Scrum im Grundsatz verstanden hat verändern sich die Art der Impediments meist in Richtung der Technologie. Fragen wie: „Hey, wir wollen alle zwei Wochen ausliefern, aber uns fehlen dazu automatisierte Regressionstests!“ oder: „Wir brauchen eine Continuous Integration Umgebung wenn wir mit den anderen Teams zusammenarbeiten wollen!“ tauchen dann auf. Wenn alle Stricke reißen, kann ich als Scrum Master diese Themen auch durch die Hierarchie eskalieren. Diese „Technologie-Ebene“ bildet die dritte Stufe der Pyramide und reicht zum ersten Mal sichtbar über die Teamgrenze hinaus.

Sobald die Technologie im Griff ist, bewegt sich der Impediment-Fokus auf verknüpfte Teams / Abteilungen / Funktionen / Rollen. Dies kommt daher, dass zwar das Scrum Team jeden Sprint ein fertiges Produkt liefern kann, der Rest der Organisation bei dieser Geschwindigkeit aber nicht mithalten kann. Während also das Scrum Team alle zwei Wochen liefert brauchen die Anforderungen vielleicht acht Wochen um beim Team anzukommen oder das QS-Team braucht nach der Lieferung nochmal sechs Wochen für die Freigabe. Verständlicherweise fragt das Entwicklungs-Team dann, warum es so häufig liefern soll, wenn andere das nicht tun. Ein guter Product Owner wird bemerken, dass die Realisierung des Business Values entsprechend lange verzögert wird – und wird Veränderungen der betroffenen Prozesse anstreben. Auf dieser Stufe der Pyramide beginnt der Scrum Master entlang der Wertschöpfungskette der Produkterstellung (normalerweise im Bereich von – Ideengenerierung – Innovation – Anforderungsdefinition – Product Backlog refinement – Produkterstellung (dieser Teil funktioniert hier meist schon) – Qualitätssicherung (sofern es noch Elemente gibt, die losgelöst behandelt werden) – Integration (Insbesondere bei mehreren Teams oder großen Produkten) – Release) mit der Optimierung der angrenzenden Prozesse.

Sobald die gesamte Wertschöpfungskette optimiert ist treten im Regelfall andere Prozessthemen in den Vordergrund. Diese betreffen meist die gesamte Organisation und verursachen – mindestens dem Scrum Team – Schmerzen. Am häufigsten sind Budgetierung, Karrierepfade, Gehaltsmodelle, Portfoliomanagement, etc. betroffen. Spätestens auf dieser Spitze der Pyramide agiert der Scrum Master vollständig als Change Agent auf Unternehmensebene.

Natürlich wird kein einziges Impediment alleine durch den Scrum Master gelöst. Stattdessen coacht dieser die involvierten und betroffenen Parteien so, dass sie eigene Lösungen finden und diese auch regelmäßig hinterfragen. Selbstverständlich verändern sich die betroffenen Parteien je nach Stufe der Impediments. Ein exzellenter Scrum Master kann die genannten Themen alle adressieren. Falls Sie diesen exzellenten Scrum Master nicht zur Verfügung haben, können Sie natürlich auch ein Team von Scrum Mastern mit unterschiedlichen Schwerpunkten einsetzen (z.B. könnten ein Experte für Teambildung und ein Change Agent Hand in Hand zusammen arbeiten während sie sich gleichzeitig um ihre eigenen Teams kümmern und die Organisation beeinflussen…), die sich gegenseitig ergänzen. Beachten Sie bitte, dass alle Ebenen der Pyramide während der gesamten Lebensdauer des Produktes/Teams relevant bleiben. Sie werden häufig auf eine der unteren Ebenen „zurück fallen“ und müssen die betreffenden Themen dann adressieren, bevor Sie zu den höheren Ebenen zurückkehren. Das ist ganz normal. Allerdings wächst mit dem Reifegrad des Teams auch die Zeit, die Sie für Impediments im oberen Bereich der Pyramide aufwenden können.

Zwar sind alle Modelle falsch, aber einige sind hilfreich. Ich hoffe, dass dieses Modell Sie dabei unterstützt die Veränderung der Art und der Qualität der Impidiments über die Zeit besser zu verstehen und den oder die richtigen Scrum Master zu finden, Ihre eigene Scrum-Implementierung zu evaluieren, oder die Frage zu beantworten, was „ein Scrum Master den ganzen Tag tut“.