Scrum-Master Tipp #1: Coach oder Trainer? Lass es das Team wissen!

In dem du wie ein Schiedsrichter darauf achtest, dass das Team die Spielregeln von Scrum einhält? In dem du Vorschläge zur Verbesserung machst? Indem du beobachtest und versuchst, durch Fragen/Diskussionen das Team sich selbst entwickeln zu lassen? Oder Experimente vorschlägst, die das Team in einem bestimmten Feld über den Tellerrand gucken/arbeiten lässt?

Als Scrum Master wissen wir, dass das alles irgendwie zutrifft, denn wir lesen viel, haben Erfahrungen gesammelt, sind zertifiziert (?) und haben uns häufig genug mit Kollegen ausgetauscht. Wir haben diese Momente, wo aus dem Team Vorschläge z. B. zur Verbesserung des Prozesses kommen, die uns glücklich machen, denn sie zeigen einen gewissen Reifeprozess.

Oder diese Gespräche in der Küche mit nur einem Teammitglied, die uns das Verhalten oder bestimmte angesprochene Punkte in der Retrospektive besser einordnen lassen. 
Was mir bei meiner Tätigkeit als Scrum Master erst spät aufgefallen ist (vielleicht bin ich da ein Spätzünder), ist der Spagat, den wir zwischen Coaching und Training hinlegen müssen. 

Coach oder Trainer?

Wie ich das meine? Der Begriff Coaching hat im deutschen Sprachraum zwei Bedeutungen:  Einmal die Übernahme des Begriffes aus dem Englischen, wo er ein Synonym für Training (Coach = z. B. Trainer eines Sportteams) ist und einen lehrenden Aspekt hat; 

„Coaching refers to guidance and feedback about specific knowledge, skills, and abilities involved in a task. (Coaching bezieht sich auf die Anleitung und die Rückmeldung zu spezifischem Wissen, Fertigkeiten und Fähigkeiten für eine bestimmte Aufgabe.)“
– Bernard. M. Bass: The Bass Handbook of Leadership, Theory, Research & Managerial Applications, 4th edition, New York, 2008, p. 1091

-> "Ich weiß was, was du nicht weißt und bringe es dir bei." 

und der Begriff Coaching wird im deutschen Sprachraum für eine Beratungsleistung benutzt: 

"Kennzeichen des C. ist die «indiv. Beratung auf der Prozessebene, d.h., der Coach liefert keine direkten Lösungsvorschläge», sondern begleitet bei der Entwicklung eigener Lösungen."
– DORSCH, Lexikon der Psychologie (https://portal.hogrefe.com/dorsch/coaching/)
-> "Ich helfe dir, die Lösung selbst zu finden."

Genau hier sehe ich die Herausforderung für uns Scrum Master: sind wir Coach (beratend) oder Trainer (lehrend)?
Klar, die Antwort habe ich oben schon gegeben: wir sind beides.

Aber warum ist das ein Problem? 

In meinen Augen ist das ein Problem, weil die Erwartungshaltung jeweils eine andere ist. Wenn ich einen Trainer vor mir habe, gehe ich davon aus, dass ich etwas Neues lerne. Dass er mich weiterbringt und jeder Workshop oder jedes Meeting vom Können und der Vorbereitung des Trainers abhängig ist. Nicht selten habe ich als Scrum Master in einem neuen Team erlebt, dass das Team genau dies von mir erwartet hat: für das Outcome des Meetings verantwortlich zu sein. 

Aber auch als Scrum Master habe ich eine Erwartungshaltung bzw. Absichten. Entweder bringe ich etwas bei "Workshop/Training" oder ich coache das Team und helfe, dass das Team selbst Lösungen entwickelt - "Coaching". 

Spezialist vs. Unterstützer 

Als Trainer bin ich Spezialist auf einem Gebiet; wer etwas nicht weiß, kommt zu mir und ich kenne die Antwort bzw. weiß mindestens, wo die Antwort steht ;)
Ich bringe also das Team dadurch weiter, dass ich Wissen teile und Erfahrungen weitergebe. 
Die Rolle als Coach bedeutet für mich, dass ich berate und helfe, dass Lösungen aus dem Team kommen können. Durch geschickte Rückfragen, oder durch das zur Verfügung stellen bzw. das Erklären von Metriken, die dem Team helfen sollen, sich selbst einzuschätzen und Schritte zur Verbesserung zu entwickeln. 
Für uns als Scrum Master aber auch für das Team ist es meiner Meinung nach wichtig, den Unterschied zu kennen und zu verstehen, dass wir beide Rollen abdecken. 

Probleme 

Werde ich zu sehr Trainer, dann pushe ich das Team in eine bestimmte Richtung. Das sorgt im besten Fall dafür, dass die Performance steigt und Abläufe optimiert werden; oder auch dafür, dass das alles zerfällt, wenn ich nicht mehr da bin, oder ein anderer Scrum Master das Team übernimmt. Buzzword-Warning: Die "Nachhaltigkeit" fehlt. 
Bin ich zu sehr Coach, kann es sein, dass das Team sich nicht weiterentwickelt. Entweder weil nicht genug Wissen bzw. Erfahrung da ist, um zu wissen, wohin man als Team eigentlich hinmöchte. Oder, weil es ja gerade so schön läuft und sich alle vertragen. Warum sollte ich als Teammitglied dieses schöne Gefühl zerstören, um in einem Punkt zu wachsen? 
Gerade die Retrospektive ist ein Ort, an dem ich als Scrum Master in kürzester Zeit die Rollen immer wieder wechseln muss. Geht das Team davon aus, dass ich der Trainer bin, der alles besser weiß, führt das zu Passivität. Setze ich aber keine Impulse, bleibt die Weiterentwicklung im schlimmsten Fall auf der Strecke oder dauert viel zu lange. 

Die Lösung 

Um zwischen den Rollen eine gute Balance zu finden hilft natürlich vor allem Erfahrung, aber auch die persönliche Reflexion. Mein Tipp: Mach nach jedem Meeting eine Quick-Retro mit dir selbst, in der du den Schwerpunkt auf die Rollen setzt: War ich gerade mehr Coach oder Trainer? Habe ich das Team dadurch weitergebracht? Was wäre sinnvoll gewesen? 
Also:
Sei dir im Klaren, dass du als Scrum Master eine gespaltene Persönlichkeit bist ;) und lass das Team gerade am Anfang wissen, wann du welche Rolle einnimmst, damit keine Missverständnisse aufkommen und kein Vertrauensbruch entsteht. 

Wie seht ihr das? Habt ihr Erfahrungen gemacht, wo ihr oder euer Scrum Master zu sehr in eine der Rollen abgedriftet ist? Oder sehe ich ein Problem, wo gar keines ist? Freue mich auf Kommentare dazu!