Mittwoch, 29. April 2015

Scrum Master oder Team Coach?

FS
Bild: Wikimedia Commons/Isolethetv - CC BY 2.0

Unter Scrum Mastern und Scrum Practicioners dürfte es eines der absoluten Dauerbrenner-Themen sein: Wie bestimmend darf ein Scrum Master seinem Team gegenüber auftreten? Ich erinnere mich an mehrere Diskussionen zu dem Thema auf Meetups in Köln, Hannover und dem Ruhrgebiet, bei denen die Antwort immer die gleiche war - wenig bis gar nicht. Praktisch jeder der anwesenden Scrum Master gibt bei derartigen Gelegenheiten fast schon reflexartig eine Anekdote zum Besten, wie ein Team dem er besonders viel Freiheit gelassen hat sich aussergewöhnlich gut enwickelte, hervorragend performte und sich zu höchsten Graden der Selbstorganisation aufgeschwungen hat. Häufig sind diese Erzählungen verbunden mit der Aussage, gar nicht als Scrum Master aufgetreten zu sein sondern nur als Team Coach, um selbst das im Namen Scrum Master implizit mitschwingende Hierarchiegefühl (wie in Master and Servant) gar nicht erst aufkommen zu lassen. Das mag auch alles so gewesen sein, trotzdem ist es meiner Meinung nach nur die halbe Wahrheit. Die andere Hälfte ist die, dass man auch die entsprechenden Teammitglieder und das entsprechende Teamumfeld für eine solche Erfolgsgeschichte braucht. Wenn man diese Faktoren nicht hat sieht die Situation sofort ganz anders aus.

Auch diese Geschichte können viele Scrum Master nämlich erzählen: Teams die sich von Beginn an gegen jede Form der Agilität gesträubt haben, sie boykottieren und sabotieren. Gründe dafür gibt es viele - die Angst vor der Verantwortung, die Sorge, für ausbleibende Erfolge verantwortlich gemacht zu werden, der im Hintergrund sein Unheil treibende Abteilungsleiter, dogmatischer Methodismus, schlechte Erfahrungen mit (angeblich) agilen Projekten, eine generelle Frustration und Desillusionierung durch jahrzehntelanges Leiden in kafkaesken Konzernstrukturen, etc., etc., etc. Die Liste ließe sich endlos erweitern. Das alles bedeutet zwar keineswegs, dass Agilität mit solchen Kollegen unmöglich ist - wenn ihnen langsam bewusst wird, dass die Performance steigt und dass ihnen keiner bei Fehlern den Kopf abreißt, dann kommt die Bereitschaft vielleicht auch bei ihnen auf1. Häufig muss aber zuerst eine initiale Totalverweigerungshaltung überwunden werden. Ohne einen eher bestimmenden Scrum Master ist das nahezu unmöglich. [Edit: mehr zu den Risiken die mit einem bestimmenden Scrum Master verbunden sind gibt es hier]

Man sollte nur wissen - wann ist welcher der beiden Typen (Scrum Master oder Team Coach) der Richtige für das Team? Ich glaube, dass sich diese Frage mit dem bekannten Scrum Master Reifegrad-Modell (Scrum Master Maturity Model) beantworten lässt, das folgendermassen aussieht:
Inspiriert von Angel Medinilla: Developing Scrum Masters
Zugegeben, auf den ersten Blick hält sich der Erkenntnisgewinn in Grenzen. Der Team Coach wird gleichgesetzt mit dem Scrum Master der höchsten Stufe, für die niedrigste Stufe wird der Begriff des "Scrum Master-Imitators" hinzugefügt2, in der Mitte bleibt die Bezeichnung gleich. Es wird zwar genauer ausgeführt was er tut, aber nicht wann welches Verhalten sinnvoll ist. Was an dieser Stelle die entscheidende Zusatzinformation ist, ist die, dass jeder Reifegradstufe eines Scrum Masters/Team Coach auch eine korrespondierende Stufe des Scrum Teams gegenübersteht. Wie oben gesagt - für eine agile Erfolgsgeschichte braucht es ein Team das Scrum vorantreiben will und auch weiß wie es geht. Umgekehrt werden unwissende und unwillige Teams es ihrem Scrum Master schwer machen zu höheren Stufen emporzusteigen. Ein aus dem Scrum Master Reifegrad-Modell abgeleitetes Scrum Team Reifegrad-Modell sähe demnach etwa so aus:
Inspiriert von Angel Medinilla: Developing Scrum Masters
An dieser Stelle wird auch die Zuordnung von Scrum Master/Team Coach zu den Reifegrad-Stufen klar. Je selbstständiger und in Agilität erfahrener das Team, desto besser kann der Scrum Master sein, bis hin zur hoch über den Dingen des Alltags schwebenden Coach-Rolle. Und umgekehrt - je "unreifer" und unwilliger das Team, desto dominanter muss der Scrum Master sein, wenn er nicht will, dass die Methodik ausgehöhlt und unbrauchbar wird. Der Begriff der "Scrum-Suppenkasper" für die Teammitglieder ist in diesem Zusammenhang sicher kontrovers zu betrachten, da auch in ihm ein Menschenbild mitschwingt. Da ich ihn aber mittlerweile mehrfach gehört habe, und da er eingängig und gut erinnerbar ist, finde ich ihn durchaus passend. Er beschreibt eine leider in der Realität durchaus vorkommende (allerdings eher auf Unwissenheit als auf Böswilligkeit beruhende) destruktive Haltung, der zumindest am Anfang mit freundlichem Zureden nicht mehr beizukommen ist.

Letzteres wird übrigens nicht überall so gesehen, ich kenne auch (anerkannt gute) Scrum Practitioner die der Meinung sind, auch unreife und explizit unwillige Teammitglieder durch sanftes Coachen verbessern zu können. Aus meiner Erfahrung heraus habe ich daran allerdings starke Zweifel, lasse mich aber gerne durch Beispiele vom Gegenteil überzeugen. Der Vollständigkeit halber sei auch noch erwähnt, dass die Unterscheidung zwischen zurückhaltendem Team Coach und dominantem Scrum Master (noch) kein allgemeiner Sprachgebrauch ist, man findet durchaus auch abweichende Definitionen. Vom Gefühl her3 würde ich allerdings sagen, dass sich die hier vorgestellte Definition langsam verbreitet.


1Voraussetzung dafür ist natürlich, dass es sich nicht um totale Menschenfeinde handelt und dass sie in einem Unternehmen arbeiten das Agilität zulässt.
2Bisher noch nicht erwähnt, da es sich um keinen erstrebenswerten Status handelt.
3Ich weiß, keine Statistische Relevanz. Aber trotzdem.
Powered by Blogger.