Bei agilen Transformationen habe ich immer wieder Muster entdeckt, die sich wiederholen. Vor einigen Jahren habe ich ein kleines Modell erstellt, das genau diese Muster darstellt: Die Pyramide der Impediments.
Was ist die Pyramide der Impediments?
Die Pyramide der Impediments ist eine vereinfachte Darstellung des Anteils der Arbeitszeit, den ein Scrum Master (oder Agile Coach) zu Beginn der Arbeit in einem Scrum Team in verschiedene Themenbereiche investieren kann und muss. Die Impediments, die vom Team kommuniziert oder vom Scrum Master entdeckt werden, ballen sich zu verschiedenen Zeitpunkten in diesen Themenbereichen.
Zunächst drehen sich die meisten Probleme um das Methodenwissen. Wie schaffen wir es, das Daily Scrum in 15 Minuten durchzuführen? Wie kann ich als Product Owner mein Backlog optimal gestalten? Was ist Value? Wie schätzen wir richtig?
Solche und viele weitere Fragen gehören für mich auf die unterste Stufe, die „Agilen Methoden“. Dabei ist es egal, ob die führende Methode Scrum, Kanban oder etwas anderes ist – die zu lösenden Probleme spielen sich auf der Methodenebene ab.
Kurz danach, meist aber schon gleichzeitig, muss man sich als Scrum Master darum kümmern, dass aus den vorhandenen Personen ein Team wird. Man hilft also dabei, noch während man Methodenfragen beantwortet, das Team durch die Tuckman-Phasen zu führen, also „Forming“, „Storming“, „Norming“ und „Performing“. Meiner Erfahrung nach sind es selten Teammitglieder, die hier Probleme sehen oder transparent machen. Viel häufiger befindet sich die Gruppe noch im „Forming“ und ist entsprechend zurückhaltend. So liegt es am Scrum Master, Konflikte zu sehen, transparent zu machen und durch das Team bewältigen zu lassen.
Sind die größten Hindernisse auf den ersten beiden Ebenen beseitigt, so verschiebt sich der Fokus häufig auf die „Engineering Excellence“, also die technischen Aspekte der Umsetzung. In der Softwareentwicklung sind das Fragestellungen rund um die Testautomatisierung, Clean Code, Produktarchitektur, etc. In der Hardwareentwicklung dreht es sich zusätzlich meist um Fragen der Lieferantenkoordination und Prototypendesign. Auch in anderen Bereichen gibt es entsprechende Fragen, die sich immer damit befassen, wie wir in der Abarbeitung der Anforderungen mit mehr Spaß schneller, qualitativ hochwertiger und günstiger werden können. Manche Aspekte der Umsetzung liegen allerdings nicht mehr in der Gestaltungsmacht der Teams, sondern in der umgebenden Organisation. Daher erfolgt hier der Übergang von der Teamentwicklung in die Organisationsentwicklung.
Ist auch die Engineering Excellence erreicht, ist das Team meist hochperformant und hat Spaß an der Arbeit. Der Problemfokus verschiebt sich dann aus dem Team heraus auf „verwandte Prozesse“ entlang der Wertschöpfungskette. Warum braucht eine Kundenanforderung sechs Wochen, um bei uns anzukommen? Wozu ist es hilfreich, die Qualitätssicherung außerhalb des Teams durchzuführen? Mit welchem Ziel wird unser Produkt außerhalb des Teams betrieben?
Werden diese Fragestellungen gelöst, so werden immer größere Anteile der Wertschöpfungskette agil und Agilität durchdringt die Organisation Stück für Stück.
Damit folgt unweigerlich der letzte Fokuswechsel auf „allgemeine Prozesse“. Damit meine ich alle organisatorischen Aspekte, die außerhalb der direkten Wertschöpfungskette liegen, die Teams also aus Produktentwicklungssicht nur indirekt betreffen. Hier geht es um Karrierepfade, Budgetierungsprozesse, Belohnungssysteme und manchmal sogar um die Aufbauorganisation des Unternehmens. Als Scrum Master arbeitet man dann also mehr mit dem Management als mit dem eigenen Team.
Warum eine Pyramide?
Die oben angesprochenen Probleme sind von Anfang an auf allen Ebenen vorhanden. Die Frage für den Scrum Master ist somit, worauf die Energie und Arbeitszeit fokussiert werden sollte. Die Antwort darauf ist vom Grundgedanken her die Pyramide: Solange es Arbeit auf den unteren Ebenen zu tun gibt, macht es wenig Sinn, die oberen Ebenen anzugehen. Was hilft uns ein agiler Budgetierungsprozess, wenn das aktuell vorhandene Budget nicht sinnvoll abgearbeitet wird? Wieso sollten wir mit dem Management konstruktiv um Verbesserungen streiten, wenn das Team in sich zerstritten ist?
Was passiert, wenn der Reifegrad eines Teams drastisch steigt?
Je „reifer“ das Team und die Organisation werden, desto mehr Arbeitszeit kann der Scrum Master in die Adressierung von Problemen auf höheren Ebenen investieren. Würde man die Arbeitszeit entsprechend messen, so sähe man irgendwann eine auf dem Kopf stehende Pyramide: Wenig Zeit wird in das Team und Methoden investiert (denn da läuft ja alles bereits gut) und viel Zeit fließt in die Optimierung übergreifender Prozesse. Aber Vorsicht: Sobald es auf den unteren Ebenen Probleme gibt, verschiebt der Scrum Master seinen Fokus wieder auf diese.
Sollte man die Arbeiten auf der Team- und Organisationsebene nicht personell voneinander trennen?
Nicht jeder kann alles gleich gut, das ist klar. Ich habe schon Scrum Master erlebt, die hervorragende Arbeit auf der Teamebene geleistet haben, aber im Umgang mit Managern durchaus noch Verbesserungspotenzial hatten. Umgekehrt habe ich aber noch keinen Agile Coach getroffen, der gut mit dem Management umgehen konnte, auf der Teamebene versagt hat und trotzdem gut für die Transformation war. Meiner persönlichen Meinung nach kann nur jemand gut auf den oberen Ebenen wirken, der auch auf den unteren Ebenen zuhause ist. Sonst kommt es zu einem „Disconnect“, einer Entfremdung von den wirklichen Problemen auf der Arbeitsebene. Ich empfehle daher stets, dass jeder Scrum Master, Agile Coach oder ähnliche Rollen immer auch mindestens ein Team aktiv begleiten müssen. Im Elfenbeinturm entstehen selten hervorragende Lösungen.
Fazit
Die Pyramide der Impediments ist ein Modell, das den Zeitaufwand des Scrum Masters (oder Agile Coaches) bei der Fokussierung auf verschiedene Themenbereiche schematisch darstellt. Sie hilft dabei, sich aktiv Gedanken über den richtigen Schwerpunkt beim jeweiligen Reifegrad des Teams und der Organisation zu machen. Außerdem unterstützt sie die Diskussion mit dem Team und den Stakeholdern in der Organisation.
Hast du Fragen oder Anregungen zur Pyramide der Impediments? Sprich mich gerne an!
Im Professional Scrum Master Training gehen wir übrigens auch auf dieses Modell ein.
