Der ScrumMaster als Coach im Heimatsystem

Dass ein ScrumMaster auch Berater sein soll, ist für mich selbstverständlich. ScrumMaster müssen in der Lage sein, das Rahmenwerk Scrum in der Organisation so einzusetzen, dass es Früchte trägt. Diese Erwartungshaltung ist auch für den ScrumMaster nicht die schlechteste - gibt sie ihm doch die Möglichkeit, seine Existenz zu rechtfertigen. Ich helfe, also bin ich. Zugespitzt formuliert: Der klassisch denkende Projektmanager muss doch merken, dass der ScrumMaster (und nicht er) die Lösung seiner Probleme kennt.Sonja Radatz schreibt von drei Beratungshaltungen, die ein differenzierteres Bild aufzeigen:

• Die Expertenhaltung. Sie beruht auf einem klaren Wissensgefälle: Der Kunde braucht den Berater, weil nur dieser das Wissen um die Lösung hat.
• Die Arzt-Patienten-Haltung geht noch einen Schritt weiter: Der Berater gibt nicht nur die Lösung vor, sondern erstellt darüber hinaus die Diagnose.
• Die Coaching-Haltung: Hier wird die Problemlösung beim Kunden belassen, der Berater gibt den Anstoß dazu.

Radatz warnt vor einer „konsequenten“ Anwendung der ersten beiden Beratungshaltungen. Dadurch könne der Kunde seine Verantwortung problemlos an den Berater delegieren und gerate so in eine Abhängigkeit des Kunden vom Berater (Radatz 2000, 88-92). Allein eine konsequente Coaching-Haltung, in der der Coach Verantwortung für den Prozess und der Coachee Verantwortung für die Inhalte (Probleme, Problemlösung) trägt, führe zur Selbstständigkeit des Kunden beim Bewältigen seiner Probleme (ebda.).Auch diese Dreiteilung in Experte, Arzt und Coach entpuppt sich bei genauerem Hinsehen für die Rolle des ScrumMasters als zu einfach. Nehmen wir als Beispiel die Rolle des ScrumMaster im Daily.Die anfängliche Verantwortung des ScrumMasters im Daily Scrum, nämlich dem Team beizubringen, wie das Daily funktioniert, lässt sich am besten mit einer zeigenden oder vormachenden Haltung wahrnehmen. Ein Beispiel: Unerfahrene Entwicklungsteams schreiben häufig Tasks (Aufgaben), die kaum Aussagekraft besitzen. So schrieb neulich eines meiner Teammitglieder, das Teile einer neu entwickelten Schublade anpassen wollte, das Wort "Anpassungen" auf seinen Task-Zettel. Nach dem Daily nahmen wir uns den Zettel gemeinsam vor. Wir schrieben dann für jede Anpassung an jedem Teil der Schublade jeweils einen Task. So war aus ursprünglich einer Aufgabe ein gutes Dutzend Aufgaben entstanden, die klein und aussagekräftig genug waren, um im Laufe eines Tages erledigt zu werden.Die Körpersprache des betroffenen Teammitglieds verriet zu Beginn, dass er den Sinn meiner Aufforderung in dem Augenblick nicht nachvollziehen konnte. Er tat es vermutlich, weil ich es als ScrumMaster, der Autorität über den Prozess hat, von ihm gefordert hatte. Im nächsten Daily fragte ich mein Team am Beispiel dieser neu formulierten Tasks nach der Sinnhaftigkeit des Herunterbrechens von Tasks auf kleine Aufgaben. Das Team erkannte mehrere Vorteile (z.B. wird für andere nachvollziehbar, was der Teamkollege gerade macht). Mein Vorgehen war also dreistufig: Ich gebe vor, wie etwas zu machen ist, mache es dann gemeinsam mit einem Teammitglied - und stoße dann das Team an, darüber selbst zu reflektieren.Jetzt wird deutlich, warum die Dreiteilung von Radatz zu grob ist, um der Arbeitswelt des ScrumMasters gerecht zu werden. Scrum ist nämlich keine Schritt-für-Schritt-Anleitung zum Lösen von Problemen. Scrum ist eher ein Prozess, dessen Befolgung das Erkennen und Bewältigen von Problemen leichter macht. Jedes Meeting in Scrum, vom Daily bis zur Retrospektive, kann als Übung zur Stärkung der Reflektions- und Wahrnehmungsfähigkeit des Teams in Bezug auf eine gelungene Produktentwicklung ausgelegt werden. Deshalb passt die Anwendung von Coaching-Techniken (ich denke hier beispielsweise an die Wunderfrage oder die Skalenarbeit) nahezu nahtlos in die Arbeitswelt des ScrumMasters.Sowohl systemisches Coaching als auch Scrum sind ein Prozess, der die Handlungsmöglichkeiten des Kunden erweitert, indem er ihn dazu ermuntert, von seinen eigenen Ressourcen stärker Gebrauch zu machen.Ein relevanter Unterschied bleibt jedoch mit der beabsichtigten Einmischung des ScrumMasters im Heimatsystem seines Teams und des gesamten Unternehmens. Ein Coach arbeitet mit dem Coachee nur im Beratungssystem - das Heimatsystem bleibt dem Coachee vorbehalten (Radatz 2000, 76-78). Als ScrumMaster habe ich diese Grenzziehnung nicht: Wir erklären dem Kunden wie Scrum funktioniert, und sind im nächsten Schritt schon mitten dabei, im Tagesgeschäft zu intervenieren. Wir greifen damit im Heimatsystem aktiv ein.Diese Einmischung ist zugleich Chance und Gefahr des Berater- und ScrumMaster-Jobs. Zum einen ermöglicht sie das, was unser Beratungsverständnis bei bor!sgloger auszeichnet und so besonders macht: Wir wollen dem Kunden keine Ratschläge geben, sondern mit anpacken. Deshalb ziehen wir uns auch nicht zurück, wenn der Kunde mal nicht mitmachen mag, sondern setzen uns mit ihm hin und zeigen durch Vor- und Mitmachen, wie zum Beispiel ein gelungenes Daily aussehen kann. Zum anderen birgt diese Einmischung in das Heimatsystem die Gefahr, dass der ScrumMaster zum neuen Projektleiter wird, der in klassischer Manier dem Team diktiert, was es zu tun hat. Für das Entwicklungsteam kann es ja durchaus komfortabel sein, wenn ihr ScrumMaster der Vorturner vom Dienst bleibt. Diese Gefahr besteht aber nur dann, wenn der ScrumMaster sich wie ein schlechter Sporttrainer verhält, der vor lauter Eigeninitiative und Gestaltungsdrang vergisst, dass es am Ende nicht um seine eigene Entwicklung geht.Radatz, Sonja (2000): Beratung ohne Ratschlag. Systemisches Coaching für Führungskräfte und BeraterInnen. Literatur-VSM e.U.