Der Scrum Master als Impediment (II)

Bild: Pixabay / Robin Higgins - Lizenz

Um es vorwegzunehmen: ich bin grosser Fan von Scrum im Allgemeinen und von der Rolle des Scrum Masters im Besonderen. Wie aber bei allen guten Ideen gibt es aber leider auch hier die Möglichkeit, sie so umzusetzen, dass sie eher schadet als nützt. Das kann schon bei der Ausgestaltung und Besetzung der Rolle beginnen (siehe hier), es kann aber auch sein, dass der Rollen-Inhaber sich (ggf. unbewusst) kontraproduktiv verhält. Um einen solchen Fall soll es hier gehen.

Ein Verhaltensmuster, das immer wieder zu beobachten ist, ist dass der Scrum Master bestimmte Tätigkeiten auf sich monopolisiert. Das kann auf den ersten Blick sinnvoll erscheinen, da die Absicht dahintersteckt das Team zu entlasten oder zu beschützen, im Ergebnis führt ein solches Verhalten aber meistens zu Flaschenhälsen in der Kommunikation, zu Unselbstständigkeit des Teams und zur Errichtung von Barrieren zwischen Menschen die eigentlich zusammenarbeiten sollten.

Der Klassiker unter diesen Monopolisierungen betrifft die Moderation der Meetings. Obwohl im Scrum Guide nicht vorgegeben ist, wer die Moderatoren-Rolle einzunehmen hat, wird sie in gefühlt 99 Prozent der Fälle vom Scrum Master übernommen. Dafür gibt es auch Gründe (der einfachste ist der, dass er es am besten kann), die Konsequenz ist aber häufig, dass in seiner Abwesenheit die Termine ausfallen, unstrukturiert ablaufen oder einen externen Moderator brauchen. Alles nicht im Sinn der Idee.

Ebenfalls problematisch ist die Monopolisierung des Impediment-Lösens. Auch hier ist die Absicht meistens eine gute: die anderen Teammitglieder sollen sich auf ihre Arbeit konzentrieren können und für die Stakeholder soll ein durchgehender Ansprechpartner da sein. Das Ergebnis sind aber häufig stille Post-Effekte und verlangsame Kommunikation, da die von Problemen betroffenen Personen und die, die es lösen können nicht mehr in direktem Kontakt sind.

Ein dritter Problemfall tritt auf, wenn die Koordination zwischen den Teams vor allem über deren Scrum Master läuft, z.B. wenn nur sie an einem Scrum of Scrums teilnehmen, neben dem es keine anderen gemeinsamen Kommunikations-Gelegenheiten gibt. Stille Post-Effekte und verlangsame Kommunikation sind auch in diesem Fall wahrscheinlich und werden oft dadurch verstärkt, dass die Scrum Master keinen technischen Hintergrund haben.

Die Lösung für diese (und viele weitere) Probleme ist es, gezielt nach den Themen zu suchen, die bisher ausschliesslich beim Scrum Master liegen und dafür zu sorgen, dass auch andere Mitglieder des Scrumteams Übung darin bekommen, sie zu übernehmen. Das ist am Einfachsten möglich bei der Meeting-Moderation, relativ einfach bei den teamübergreifenden Abstimmungen und am schwierigsten bei der Impediment-Lösung. Möglich ist es aber in allen Fällen.

Zuletzt noch zu möglichen Gegenargumenten. Anders als häufig angenommen wird gibt der Scrum Guide nicht vor, dass bestimmte Themen ausschliesslich dem Scrum Master zugeordnet sind. Um die häufigsten Missverständnisse zu nennen - "ensuring that all Scrum events take place" bedeutet eben nicht, dass er sie alle moderiert (im Daily ist nichtmal seine Anwesenheit nötig), und "causing the removal of impediments" bedeutet eben nicht, dass er sie alle selbst beseitigt.

Auch das Argument, dass die Übernahme von Meeting-Moderation, Impediment-Lösungen und übergreifender Kommunikation die Team-Mitglieder von ihrer "eigentlichen Arbeit" abhält, ist mindestens fragwürdig. In Scrum sind "self-management and cross-functionality" explizit für das gesamte Team vorgesehen, eben um zu verhindern, von einzelnen Personen abhängig zu sein. Die (scheinbaren) Scrum Master-Aufgaben zu übernehmen gehört also explizit zur Arbeit dazu.

Natürlich muss man diese Ansichten nicht teilen, man kann auch der Meinung sein, dass es effizienter oder effektiver ist, derartige Aufgaben vom Team fernzuhalten. Der Punkt ist aber: selbst wenn man das aus dem besten Willen heraus tut, wird man sehr schnell in einen Widerspruch zu den Regeln von Scrum geraten. Und jemand, der die Regeln von Scrum unterläuft oder aufhebt, ist per Definiton ein Impediment, selbst dann wenn diese Person der Scrum Master ist.