Warum explizites Coaching in Scrum unmöglich ist!
Eine kühne These, zugegeben. Mal sehen, ob Sie sie nach diesem Artikel teilen.
Fangen wir ganz vorn an. Scrum Master sind für die Effektivität des Scrum Teams verantwortlich. Sie sollen die Teammitglieder laut Scrum Guide in „Selbstmanagement und interdisziplinärer Zusammenarbeit“ coachen1. Coaching ist ein zentraler Bestandteil2, um die im Scrum Guide beschrieben Zielzustände zu erreichen. Wie genau Scrum Master das umsetzen, bleibt ihnen überlassen, wie vieles anderes auch.
Wenn man sich nun enger mit explizitem Coaching (explizit = mit Auftragsklärung; implizit = ohne Auftragsklärung) und systemischer Beratung befasst, ist ein wesentlicher, wenn nicht der wesentlichste Bestandteil die Auftragsklärung3 4 5 6. Sie klärt, auf welches Ziel der Coach mit dem Coachee hinarbeitet. Das Ziel wird üblicherweise zu Beginn definiert und kann im Laufe des Coachings jederzeit nachjustiert werden. Das ist sinnvoll, denn erste Erkenntnisse können verdeutlichen, dass anfängliche Zielzustände nicht die erhofften Ergebnisse mit sich bringen würden. Ein Beispiel aus dem klassischen Coaching (explizit): Das ursprüngliche Ziel war die berufliche Weiterentwicklung der Führungsfähigkeiten. Bei der Erarbeitung kann sich herausstellen, dass die Führungsaufgabe selbst nicht, wie angenommen, zur eigenen Persönlichkeit passt. Eine neue berufliche Orientierung ergibt sich im Laufe des Coachings als neues Ziel.
Schauen wir uns an, wie die Situation im Scrum Framework aussieht. Welcher Auftrag wird hier wann mit wem festgehalten? Im Framework bringt jeder auf Basis seiner Erfahrungen und seines Vorwissens sein eigenes Verständnis und seine eigene Interpretation von Scrum mit. Diese sind in den seltensten Fällen deckungsgleich. Es ist eher die Frage, wie groß die Abweichung zwischen den Beteiligten ist und nicht, ob es eine gibt. Konträre Ziele, Erwartungen und Wege sind also eher die Regel als die Ausnahme. Völlig normal.
Wie kann das sein? Es gibt zumeist keine Auftragsklärung zwischen der Organisation, dem Teammitglied und dem Scrum Master. Das ist unsere Triade. Es gibt eine Vereinbarung (Contract inklusive Aufträgen) zwischen Organisation und Teammitglied („Du entwickelst mit Scrum Software.“) und eine Vereinbarung (Contract inklusive Aufträgen) zwischen Organisation und Scrum Master („Du unterstützt das Team und die Organisation, agiler zu werden.“). Lassen wir mal die unterschiedlichen Qualitäten dieser Vereinbarungen außer Acht, können wir den wesentlichen Punkt erkennen.
Und das ist meine elementare Kritik an Scrum: Es gibt keine vorgesehene Vereinbarung inklusive Auftragsklärung zwischen Teammitglied und Scrum Master und – was noch schwerwiegender ist – kaum wirksame Möglichkeiten diesen Umstand zu kompensieren.
Sie fragen sich, warum der Scrum Master sich nicht einfach eine Beauftragung zu den wichtigen Themen beim Teammitglied holt?
Das wäre, als ob Ihre Schwiegermutter (die auch im Haus wohnt) Ihnen vorschlägt, in den Urlaub nach Sizilien zu fahren und dort ein Boot zu mieten, weil sie überzeugt ist, dass dies Ihnen guttun würde.
Sie wollen aber viel lieber in Island wandern und wären wahrscheinlich nicht bereit, viel Energie für den Vorschlag der Schwiegermutter aufzuwenden, weil Sie dieses Ziel nicht teilen. Was anderes ist es, wenn Sie selbst im Gespräch mit der Schwiegermutter auf Sizilien kommen, oder?
Was können Konsequenzen sein?
Zahlreiche Szenarien sind denkbar:
Sind z. B. die zugrunde liegenden Annahmen, Zielzustände, Methoden, Selbstbild vom Teammitglied und Fremdbild vom Scrum Master ähnlich, dann teilt man eine vielversprechende Schnittmenge (z. B. wie offen und respektvoll ist das Team; welche Prozessänderungen, Tools und Konfigurationen helfen die Ziele zu erreichen). Das führt zu kontinuierlichen Verbesserungen. Teammitglieder haben selbst gute Ideen, probieren sie gern aus und organisieren sich zunehmend selbst. Ein Scrum Master kann diesen Vorgang sicher vielfältig beschleunigen, grundsätzlich ist das Team aber auch ohne den Scrum Master auf dem richtigen Weg.
Was aber wenn die Annahmen, Zielzustände, Methoden sowie besonders das Selbstbild der Teammitglieder und das Fremdbild durch einen Scrum Master stark voneinander abweichen (Teammitglieder: „Wir sind sehr agil!“; Scrum Master: „Wir haben viele Potentiale!“)? Der Scrum Master sieht viele Optimierungsmöglichkeiten und die Mehrheit der Teammitglieder nicht, weil in ihren Augen und nach ihrer Erfahrung alles prima läuft. ‚Inspect and Adapt‘ funktioniert kaum bis nicht, weil keine Probleme wahrgenommen werden oder akzeptiert sind. Daher gibt es auch nur eine überschaubare Bereitschaft, neue Ideen vom Scrum Master auszuprobieren. Nachvollziehbar. Dieser Effekt kann sich in Projektsituationen so verstärken, wie die Situation fordernd ist. Stellen Sie sich vor, ihre Schwiegermutter möchte 2 Wochen vor Ihrer großen Geburtstagsparty den Garten neugestalten. Wie offen sind Sie dafür? Kann besser werden, muss es aber nicht. Da ist es nur nachvollziehbar, dass der Widerstand im Team in dem Maße wächst, wie der Scrum Master eine Veränderung umsetzen möchte.
In einer solchen Situation ist auch ein Coaching ohne Auftrag (implizit) nicht erfolgsversprechend, weil viele Teammitglieder kein Motiv haben, etwas zu ändern („Wir arbeiten schon sehr agil und erfolgreich.“) und die jeweiligen Ziele der Teammitglieder („Weiter so!“) und Scrum Master („Lass uns Potentiale heben!“) zu stark differieren. Ohne einheitliches Ziel ist es schwer einen guten Weg dorthin zu finden. Das ist, als ob Ihnen die Schwiegermutter sagt, wo Sie ihre Kottelets kaufen sollen, weil sie dort gut und günstig sind, Sie aber Salat essen möchten.
Wie kann man einen solchen Teufelskreis verhindern oder durchbrechen?
Eine Möglichkeit ist es, den Fokus auf die Auftragsklärung zu legen. Hier sehe ich zwei Möglichkeiten.
Zum Einen kann man den Auftrag in Gesprächen in 1:1-Settings zwischen Teammitglied und Scrum Master zu Projektbeginn erarbeiten. Eine individuelle Klärung von Entwicklungszielen eröffnet dem Scrum Master einen größeren Handlungsspielraum, erhöht das Commitment des Teammitglieds und legitimiert ein späteres Anknüpfen an diese Vereinbarung. Dieses Vorgehen bedarf jedoch vieler Voraussetzungen wie Motivation, Offenheit und am wichtigsten Reflektionsfähigkeit auf Seiten des Teammitglieds. Je weniger diese und andere Eigenschaften anzutreffen sind, desto wichtiger wäre eine Entwicklung und desto unwahrscheinlicher ist sie. Selbst wenn diese Eigenschaften ausreichend gegeben sind, bleibt zwangsläufig eine Differenz zwischen den angestrebten Optimierungen des Teammitglieds und denen des Scrum Masters. Es bleibt das Risiko, dass eine große Abweichung nachhaltig negativ auf den Projekterfolg wirkt. Da die Initiative bei den Abweichungen nicht vom Teammitglied ausgeht, kann hier auch kein explizites Coaching stattfinden.
Zum Anderen kann der Scrum Master gemeinsame Ziele mit dem gesamten Team definieren (z. B. auf Basis einer gut visualisierten Fragebogenauswertung). „Wir wollen so mutig werden, dass wir regelmäßig neue Dinge ausprobieren und individuelle Anfragen an den PO oder SM umleiten.“ oder „Wir wollen die Kundenzufriedenheit um 25% steigern.“ sind Ziele, an die angeknüpft werden kann, um die Sensibilität und den Fokus im Team zu erhöhen. Aber auch hier ist der Scrum Master vom Commitment des Teams abhängig. Die Definition eines geeigneten Teamziels kann zudem sehr fordernd sein. Desto weicher das Thema, desto schwieriger. Denkt man z. B. an Motivation, Selbstverpflichtung und Offenheit, scheint die Messbarkeit erschwert. Eine detaillierte Festlegung von Kriterien kann hier schnell kontrollierend wahrgenommen werden und hätte negative Effekte. Es bleiben also auch hier große Lücken, in denen der Scrum Master eventuell keine Wirksamkeit hat. Auch hier geht die Initiative nicht vom Team aus und vielleicht werden sogar Themen vom Scrum Master gegeben, was entsprechend wirkt.
Wie kann man diese offenen Wirkungslücken positiv beeinflussen?
Indem man eine Technik einsetzt, die auch ohne Auftrag, Motiv oder einheitliches Ziel implizit Erkenntnisse hervorbringt. Und zwar mit systemischen Fragetechniken. Wenn Sie – in unserer genutzten Analogie – eine Schwiegermutter werden wollen, bei der die Gesprächspartner gute Ideen entwickeln, dann ist dieser Artikel interessant für Sie.
Fazit:
Im Framework Scrum ist es normal, viele Freiheiten zu lassen. Üblicherweise gibt es jedoch für die einzelnen Herausforderungen viele erfolgsversprechende Ansätze.
- Wie erstelle ich das Backlog?
- Wie schätzen wir?
- Welcher Item-Bearbeitungs-Workflow passt zu uns?
Die fehlende Auftragsklärung jedoch erweist sich als harte Nuss – in manchen Fällen vielleicht unknackbar – und dadurch als Strukturschwäche. Besonders nachteilig fällt das komplementäre Verhältnis von Entwicklungsbedarf und Wirkwahrscheinlichkeit auf. Desto höher der Bedarf bei einzelnen Teammitgliedern ist (z. B. durch geringe Motivation, Offenheit oder Reflektionsfähigkeit), desto geringer ist die Wahrscheinlichkeit eines wirksamen, impliziten Coachings ohne Auftrag. Ein Dilemma bei dem weitere Lösungsansätze (auch von Ihnen) generell hilfreich sind.
Abschließend bleibt die zentrale Frage: Wie lässt sich explizites Coaching im Scrum Framework wirksam umsetzen?
Ich wünsche Ihnen viel Erfolg und bedanke mich für Ihre Aufmerksamkeit.
Bitte beachten Sie, dass im gesamten Artikel Bezeichnungen wie ‚Scrum Master‘ geschlechtsneutral verwendet werden und immer alle Geschlechter gleichermaßen einbeziehen.
Literaturverzeichnis
Barthelmess, Manuel: Die systemische Haltung. Was systemisches Arbeiten im Kern ausmacht, Göttingen: Vandenhoeck & Ruprecht GmbH & Co. KG 2016
Fischer-Epe, Maren: COACHING: Miteinander Ziele erreichen, Überarbeitete Neuausgabe, Reinbek bei Hamburg: Rowohlt Taschenbuch Verlag GmbH 2004
McShane, Niall: Responsive Agile Coaching. How to accelerate your coaching outcomes with meaningful conversations, USA: Lifestyle Entrepreneurs Press 2020
Radatz, Sonja: Beratung ohne Ratschlag. Systemisches Coaching für Führungskräfte und BeraterInnen, 10. unveränderte Auflage, Wolkersdorf, Österreich: Literatur-VSM e.U. 2018
Schlippe, Arist von / Schweitzer, Jochen: Lehrbuch der systemischen Therapie und Beratung I. Das Grundlagenwissen, Göttingen: Vandenhoeck & Ruprecht GmbH & Co. KG 2012
Schwaber, Ken / Sutherland, Jeff: Der Scrum Guide. Der gültige Leitfaden für Scrum: Die Spielregeln, 2020
- Schwaber/Sutherland 2020, S. 7 ↩︎
- vgl. McShane 2020, S. 11 ↩︎
- vgl. Barthelmess 2016, S. 146 ff, S. 165 ff ↩︎
- vgl. Fischer-Epe 2002, S. 26 ↩︎
- vgl. Radatz 2018, S. 130 ff ↩︎
- Schlippe/Schweitzer 2012, S. 235 ff ↩︎
Dieser Beitrag wurde verfasst von:
