Wann ist der Scrum Master ein Agiler Coach?

Auch wenn die nachfolgende Betrachtung sehr kategorisiert, vielleicht sogar sehr absolut in ihren Annahmen stattfindet, so gilt es deutlich zu machen, dass bei jeder agilen Rolle agile Werte über allem stehen. Das agile Mindset schlägt zu jedem Zeitpunkt Rollen, Aufgabenbeschreibungen und Verantwortlichkeiten. Diesem Umstand trägt dann aber auch die Rolle des Scrum Masters sowie des Product Owners, Rechnung. Beide haben ihren Ursprung im Scrum Guide und sind daher detailliert beschrieben. Zu dieser Beschreibung gehört, dass der Scrum Guide die Werte Fokus, Commitment, Openness, Respect als auch Courage voraussetzt.

Sowohl beim Agile Coach als auch bei mutmaßlich kontextabhängigen, angrenzenden Rollen, welche zunehmend in Erscheinung treten, wie zum Beispiel dem Agile Master, Agile Manager oder Scrum Coach wird diese Definition ungenauer. Im deutschsprachigen Raum trat der Begriff vor ca. 10 Jahren das erste Mal in Erscheinung. Damals noch exklusiv im Umfeld der agilen Communities. Mittlerweile, so scheint es, wird dem Agile Coach mehr Bedeutung zugeschrieben, als dem Scrum Master. Das Recruiting gibt es vor, Klientenanfragen und deren Ausschreibungen erwarten es: Man muss agiler Coach sein.

Aber was heißt das eigentlich im Detail? Die Antwort auf diese Frage kann auf mehreren Ebenen betrachtet werden:

• Die Haltung, welche die jeweilige Rolle in ihrer Arbeit dem agilen Unternehmen gegenüber einnimmt.
• Die persönliche Erfahrung, welche die ausübende Person vorweisen kann.
• Die Aufgabenkontexte, welche konkret betrachtet werden.

Mit Haltung meine ich, wie sich der Scrum Master bzw. der Agile Coach seinem Umfeld gegenüber positioniert. Ein Scrum Master wird tendenziell immer pragmatischer arbeiten als es ein Agile Coach dies tut. Er wird häufiger „anpacken und selber machen“, wohingegen der Agile Coach – und eben das besagt dieser Begriff nunmal, Hilfestellungen zur Selbsthilfe geben wird. Er wird spiegeln, Fragen stellen und zurückhaltender auftreten. Natürlich gibt es hier aber kein schwarz und weiß, sondern viel grau.

Dort ist aber dann auch direkt der notwendige Zusammenhang zur (beruflichen) Erfahrung zu sehen. Die Wahrnehmung, wann ein Team unter Anleitung selbst ein Problem lösen kann und wann ein Abwarten nur schaden würde, muss erlernt werden. Meiner persönlichen Ansicht nach ist es vermessen, sich als agiler Coach zu verkaufen, bevor man vier bis fünf Jahre berufliche Erfahrung in dem Umfeld sammeln konnte.

Erfahrungen unterschiedlicher Art benötigt ein Agilist auch in den einzelnen Aufgabenfeldern, in welchen er sich bewegen kann. Es ist nicht notwendig alle aufgezeigten Felder zur Perfektion zu beherrschen. Es ist wie in einem agilen Team: Know-how ist eher T-Shaped bzw. M-Shaped zu erwarten. Jedoch können diese typischen Aufgaben auf die unten abgebildete Achse gelegt werden, um zu zeigen, welche von einem Scrum Master und welche von einem Agile Coach zu erwarten sind.

Eine Aufgabe, die dem Scrum Master zugeschrieben ist. Im Scrum Guide steht dazu:

• Facilitation of Meeting
• Den Scrum Prozess einführen
• Das Impediment Backlog führen

Die Aufgabenstellungen bedingen eine sehr hohe Bindung an die jeweiligen Teams. Ich behaupte, dass es einem Scrum Master bei 100 %iger Ausübung der Rolle durchaus möglich sein muss, bis zu drei Teams – jedoch auch nicht mehr – zu betreuen. Die Aufgabenstellungen eigenen sich auch prima, um ganz junge Scrum Master auszubilden. Insbesondere dann, wenn sie einen erfahrenen Scrum Master zur Seite stehen haben.

Auch bei diesen Aufgaben befinden wir uns noch im Rahmen der Rollenbeschreibung für den Scrum Master gemäß Scrum Guide. Jedoch bedarf es mehr Erfahrung in dieser Rolle, um auch wirklich authentisch eine Mentor-Rolle einzunehmen. Ein Scrum Master, der seinem Development-Team zzgl. des Product Owners Erfahrungen mit an die Hand geben möchte, sollte diese idealerweise aus erster Hand kennengelernt haben. Zu diesen Erfahrungen zählen zum Beispiel Anpassungen der Arbeitsprozesse. Potentielle Fragestellungen sind häufig, wieso Sprints nicht fertig werden, warum der Test am Ende des Sprints überlastet ist oder wie die Arbeit mit Storypoints funktioniert.

Zudem ist es in diesem Umfeld notwendig, einen direkten oder indirekten Draht zum Management zu haben, um die komplexeren Impediments, welche nicht durch das Team selbst beeinflusst werden können, zu beheben. Dieser indirekte Draht kann dann durchaus über einen Agile Coach bestehen. Hier verschwimmen die Grenzen erstmalig.

Frei übersetzt besagt der 2020er Scrum Guide, dass es Aufgabe des Scrum Masters ist, die Scrum Theory und die Methoden sowohl dem Scrum Team verständlich zu machen, wie auch jedem anderen Mitarbeiter der Organisation. Diese Aufgabe skaliert in dieser Rolle jedoch nur zu einem gewissen Maße. Zumal ein ganzheitlicher Blick in den Aufbau und die Strategie der Organisation fehlen mag. Sicherlich ist es nicht gewollt, dass etwaige Scrum Schulungen ohne ein abgestimmtes Ausbildungskonzept durchgeführt werden. Somit kann man hier von gemeinsamen Anstrengungen von Scrum Mastern und Agile Coaches (abhängig auch von der Größe der Organisation) sprechen.
Meist übernimmt ein Team von Agile Coaches die Planung der theoretischen Ausbildung, geht in den Lead und wird von den lokal angesiedelten Scrum Mastern unterstützt. Ein Training zu agilen Methoden muss nicht ausschließlich im Sinne der Ausübung von Scrum erfolgen. Ein solches Training kann auch im Zuge der Einführung weiterer Frameworks wie Kanban, SAFe oder Design Thinking erfolgen.

Die Affinität zur Technologie ist ein Aufgabenfeld, welches in beiden Rollen vorhanden sein kann, aber je nach Kontext nicht vorhanden sein muss. So kamen die ersten Scrum Master mit relativ großer Sicherheit aus dem IT-Umfeld und damit stieg die Anzahl der – am Anfang noch – Quereinsteiger. Mittlerweile dürften die große Mehrheit der Scrum Master und Agile Coaches ehemalige Führungskräfte oder Projektmanager sein und solche, die direkt von der Universität in die Rolle eingestiegen sind. Dennoch täuscht das nicht darüber hinweg, dass das Framework Scrum und das agile Arbeiten seinen Hype im Rahmen der Softwareentwicklung begründen konnten. Dementsprechend sind agile Technologien sowie angrenzende Methoden wie Testautomatisierung, Deployment-Pipelines, Clean Code Development und DevOps bei ca. 50 % aller agilen Teams relevant. Vor dem Hintergrund des Beseitigens von Impediments und dem Anspruch an Ausbildung durch Trainings ist es durchaus erwartbar, dass viele Scrum Master und Agile Coaches sich nicht nur auf die Methodik zurückziehen können. Beide Rollen sind von dem Aufgabenfeld ähnlich betroffen, wobei der Scrum Master eher auf Team- oder Projektebene agiert und der Agile Coach auf Organisationsebene. Das bedeutet, dass der agile Coach sich primär auf unternehmensarchitektonische Systeme und Tools sowie entsprechende Methoden konzentriert, wohingegen der Scrum Master seinen Fokus auf die lokale Anwendung derer legt.

Change bedingt Kommunikation. Und eine Transformation eines Unternehmens hin zu einer agilen Struktur ist ein außergewöhnlich großer Change, der auch außergewöhnlich viel Kommunikation bedarf. Neben den Sponsoren des Changes seitens des Managements ist es auch immer wichtig einem Experten der Agilität – sei es intern oder von externer Seite engagiert – eine Bühne zu geben. Dies können etwaige Townhalls, BarCamps oder FishBowls sein, in denen die Veränderung aus den geschlossenen Büros heraus an die betroffene Belegschaft kommuniziert wird (hoffentlich im Sinne der Agilität so schnell und transparent wie möglich). Diese Auftritte vor größerer Runde sollten mit großer Erfahrung und einem sicheren Standing verbunden sein, da kritische Rückfragen zu erwarten sind. Ein ausgeprägtes Fachwissen ist unabdinglich. Zudem spricht der Blick für das Große und Ganze im Change tendenziell dafür, dass diese Events durch einen Agile Coach durchgeführt werden. Scrum Master können aber unterstützend zur Seite stehen. Ihre Position in der operativen Umsetzung wird dabei auch sehr gestärkt, dass sie sichtbar das Backup „von oben“ haben.

Agilität bedingt immer ein agiles Mindset, welches häufig noch erarbeitet werden muss. Aber auch die strukturellen Aspekte, wie:

•  Wie arbeitet die Organisation in Zukunft zusammen, wie ist der Prozess?
• Was ist das Produktportfolio und welche Teams werden benötigt?
• Wie sieht der Wertstrom über die agilen Teams hin aus?
• Wird ein Skalierungsframework benötigt? Wenn ja, welches?
• Welche Experten werden in welchen Bereichen benötigt?
• Muss ggf. noch eingestellt werden?

Dies sind Fragestellungen, welche weitreichender Expertise bedürfen. Der Agile Coach – und ich beziehe mich hier mittlerweile explizit auf ihn – sollte einer solchen Aufgabenstellung schon mindestens einmal zuvor begegnet sein, bevor er in einem Change in den Lead geht. Die Verantwortung für solch weitreichende Veränderungen ist groß und es ist immer wichtig, ein Verständnis dafür zu haben, dass das Ergebnis – das Inkrement des Changes – dynamisch ist und niemals abgeschlossen.

Warum eigentlich das Ganze? Die agile Transformation eines Unternehmens kann nicht einfach nur im Idealismus begründet sein. Ein Agile Coach muss Kenngrößen präsentieren können, um den Erfolg oder den Misserfolg seiner Arbeit identifizieren zu können. Diese Kenngrößen können sich auf verschiedene Dimensionen beziehen:

• Das Ziel einer agilen Transformation.
• Der Fortschritt einer agilen Transformation.
• Mehrwerte, welche innerhalb der Teams durch die neue Aufstellung generiert werden.
• Risiken und deren Abwägungen im Change.
• Potenzielle zukünftige Erlösmodelle.

Solche Kenngrößen sollten nicht wie folgt formuliert sein: „Wenn Sie das agile Framework XY einsetzen, erhöht sich Ihre Produktivität um 27 %“. Vielmehr muss der Coach den Prozess in den organisatorischen Kontext einordnen können und an einigen Stellschrauben mehr ziehen und dafür an anderen weniger. Es gibt hierfür Frameworks, wie zum Beispiel OKR oder aber unterstützte Frameworks wie Lean StartUp.

Fragensteller, Provokateur oder begleitender Schatten. Es gibt viele Rollen, die ein Coach einnehmen kann. Aber es ist für überwiegend beratende oder steuernde Persönlichkeiten schwierig, die nötige Coaching-Distanz aufzubauen und zu halten. Coaches sind Begleiter bei der „Hilfe zu Selbsthilfe“. Sie greifen per Definition nicht aktiv mit ein, sollte der Coachee vor Herausforderungen stehen, auch wenn sie potenziell die Antwort kennen. Ziel soll hier nicht die schnelle, operative Lösung sein, sondern eine nachhaltige Antwort auf Herausforderungen. Der Coachee ist am Ende des Coachings befähigt, in ähnlichen Situationen alleine zu agieren.

Der Erfolg dieser Rolle hängt dabei aber von drei relevanten Kriterien ab:

• Das Standing dem Coachee (oder des jeweiligen Auftraggebers) gegenüber, Probleme nicht selbst lösen zu müssen. Also die Fähigkeit und das Zutrauen „nein“ zu sagen.
• Die Selbstdisziplin, nicht selbst in diese Muster zu verfallen und zum Berater oder Mentor zu werden. Der Druck von der Coaching-Haltung abweichend zu agieren, kommt nicht nur von außen, sondern auch von innen.
• Die Erfahrung, die richtigen Fragen zu stellen, sich dabei auf seine Distanz zu verlassen und Intentionen hinter den Worten herauskitzeln zu können. Dies ist ein Ergebnis jahrelanger Übung und keine Fähigkeit, welche in einem Lehrbuch erlesen werden kann.

In diesem Kontext der Aufgabenstellungen des systemischen Coaches stellt sich beim Begriff „Agile Coach“ schon eine definitorische Herausforderung: Ein Coach in Zusammenhang mit einer fachlichen Expertise? Ist er also ein Coach, der Erfahrung in agilen Umfeldern hat? Oder doch ein Mentor oder Berater, der fälschlicherweise als Coach bezeichnet wird?

Ich glaube, die Antwort auf die Frage ist eine Beraterantwort: Es kommt darauf an. Wie schon gesagt, wird jeder Scrum Master und jeder Agile Coach die zuvor genannten Aufgabenstellungen in unterschiedlicher Art und Weise bedienen können. Einige Aspekte vielleicht gar nicht und andere in vollster Ausprägung. Das bedeutet auch, dass der zuletzt beschriebene Agile Coach nicht zeitgleich der operativen Rolle des Scrum Masters gerecht werden kann. Und das ist auch gut so. Denn meiner Meinung nach haben wir als agile Experten (und ich vermeide hier absichtlich Rollenbezeichnungen) unsere individuellen Stärken basierend auf unseren früheren Erfahrungen. Zumal es letztendlich auf das Umfeld ankommt, welche Rollen und Schwerpunkte in welchen Situationen benötigt werden. Dementsprechend sollten auch die Stellengesuche oder Ausschreibungen formuliert sein.