Gelerntes verlernen oder warum gute ScrumMaster keine Antworten geben

Wenn Mike Cohn davon spricht, dass der Übergang zur Agilität mit Scrum schwer ist, dann meint er Eigenheiten wie: Der angestrebte Endzustand ist unvorhersehbar, Veränderungen treten schneller als jemals zuvor ein oder dass der Wandel nicht ausschließlich von oben nach unten oder von unten nach oben erfolgt. Scrum wirkt sich nicht nur auf alles aus, was Menschen tun, sondern konterkariert auch das, was sie irgendwann mal gelernt und für gut befunden haben. Vor Scrum mussten Tester zum Beispiel prüfen, ob Spezifikationen eingehalten werden. Entwickler  dagegen sollten erst nach der Problemanalyse und mit einem (perfekten) Lösungsentwurf in der Tasche mit dem Programmieren loslegen. Und jetzt, mit Scrum? Tester müssen lernen, die Bedürfnissen der Anwender zu verstehen und Entwickler müssen lernen, dass man auch ohne perfekten Entwurf mit dem Programmieren beginnen kann.
Kurzum: Sie müssen Gelerntes wieder verlernen und stattdessen auf eine unvertraute Art und Weise denken und handeln. Scrum ist deutlich anders.

Linear-kausal war einmal

Die Menschen, die die verantwortungsvolle Rolle des ScrumMasters übernehmen, sind vom Anderssein bzw. Anderswerden nicht weniger betroffen – ganz im Gegenteil. Der ScrumMaster muss in diesem Wirkungsgefüge, dem offenkundigen Widerspruch begegnen, zwar ein führender Helfer des Teams zu sein, aber das ohne Anspruch auf Autorität realisieren zu müssen. Damit beschränkt sich die Autorität des ScrumMasters erstmal (nur) auf die Kontrolle des Prozesses. Anders als ein Projektleiter kann er sich in seinem Tun nicht auf die Position „Sie machen das jetzt, weil ich es Ihnen sage“ beziehen. Um dem Team bei der Anwendung von Scrum zu helfen oder Hürden jeglicher Art aus dem Weg zu räumen, braucht der ScrumMaster somit ein Werkzeug, mit dem er dieses (scheinbare) Autoritätsdefizit überwinden kann. Dazu muss auch er gewohnte Handlungsarten ablegen bzw. verlernen. Wir sind es gewöhnt, linear-kausal zu denken: Aus A folgt B und A ist „schuld“, dass B entsteht. Linear-kausales Denken ist immer vergangenheitsbezogen und damit ursachenorientiert. Das heißt, es gibt konkrete Ursachen für bestimmte Auswirkungen und damit eindeutig nachweisbare Verantwortliche für bestimmte Ergebnisse. So nachvollziehbar ein Ergebnis sein wird, so gefährlich ist der Versuch, Komplexität auf diese vereinfachende Weise zu reduzieren und dabei Wechselwirkungen vollkommen zu ignorieren.
Gute ScrumMaster suchen niemals nach Ursachen oder Schuldigen, sondern analysieren, welche „Muster von Kommunikationen, Beziehungen und Handlungen im Zusammenhang mit anderen Mustern zu einem Ergebnis führen“ (Radatz, 2000, S. 67), d.h. sie denken systemisch. Systemisch Denken heißt, in Auswirkungen zu denken und davon auszugehen, dass nie nur einer allein Schuld an der Entstehung einer bestimmten Situation hat, wenn mehrere, in welcher Form auch immer, beteiligt sind/waren. Daher ist es auch vollkommen unerheblich, wer der Ver-Ursache-r war. Ein systemisch denkender ScrumMaster blickt nicht in die Vergangenheit (Problemsicht), sondern in die Zukunft (Lösungs- und Zielsicht):
[quote author = “Steve de Shazer”]”Problem talking creates problems. Solution talking creates solutions.”[/quote]
De Shazer möchte vor allem so verstanden werden, dass die Lösung (das Ziel) mit dem Problem niemals etwas zu tun hat. Wenn man also einen Menschen bei seiner Problemlösung unterstützen möchte, dann bringt es nichts, ausführlich über das Problem und dessen Ursachen zu konferieren.
Merke: Das Problem hat nichts mit der Lösung zu tun.

Warum warum niemanden weiterbringt

Natürlich schließt systemisches Denken die aktive Auseinandersetzung mit der Vergangenheit nicht aus, aber eben nicht, um Ursachenforschung zu betreiben oder misslungene Handlungsmuster zu analysieren. Statt analysierend-statisch über Vergangenes nachzudenken, geht es darum, zukunfts-, verhaltens- und zielorientierte Aspekte zu erfragen und mit dem Befragten wohlgeformte Lösungsbilder zu erarbeiten:

Weg von Problemfragen … … hin zu Lösungsfragen
Welche Ursachen hat das Problem? Was müsste wer/wann zukünftig anders tun, damit ein besseres Resultat herauskommt?
Wer hat es verursacht? Was müsstest du vor allem/als erstes tun/unterlassen?
Wer hat mehr Schuld? Was willst du mit deinem geänderten Verhalten erreichen?
Was ist das Schlimmste daran? Was soll in Zukunft anders sein?
Was ist in der Vergangenheit schief gelaufen? An welchem Verhalten von dir würde jemand anders merken, dass du dein Ziel erreicht hast?

Wenn ihr euch als ScrumMaster jetzt an systemischen Fragen versuchen wollt, dann beginnt mit zweierlei:

  • Versucht, weniger geschlossene Fragen zu stellen. Geschlossene Fragen sind Entscheidungsfragen, d.h. euer Gegenüber kann erstmal nur mit Ja oder Nein antworten. Natürlich gehört das auch dazu und ist ebenfalls wichtig. Wenn ihr jedoch Kommunikation vorantreiben wollt, dann sind geschlossene Fragen keine „Challenge“ für den Befragten. Geschlossene Fragen heißen geschlossen, weil sie kommunikationsschließend sind.
  • Ersetzt eure Fragen, die mit „Warum, wieso, weshalb oder weswegen“ anfangen durch andere W-Fragen.

Ihr fragt euch jetzt sicher: Warum?
Wenn man die Gründe für etwas herausfinden will, dann ist es wenig erkenntnisreich, nach dem Warum zu fragen. Menschen antworten auf eine Warum-Frage meistens mit bereits zurechtgelegten Antworten. Und diese fördern das Verständnis der Situation kaum. Ein Warum, Wieso oder Weshalb ist fast immer mit negativen Konsequenzen verbunden und zieht den Befragten wieder tiefer in den Problemsog.
Wie fragt man, wenn man nicht warum fragen soll? Eine Inspiration findet ihr, wenn ihr die Geschichte aus der Zauberwerkstatt vom „empfindlichen Fragezeichen“ lest. Probiert es aus. Und wann merkt ihr, dass ihr eine gute Frage gestellt habt? Je länger der Befragte braucht, um die Frage zu beantworten, desto einschneidender war sie.
Eins steht fest: Wer richtig fragt, muss keine Antworten geben, weil sich die Befragten in vielen Situation ihre Antworten selbst geben und die Wirkung einer Frage dazu führt, die eigenen Gedanken zu ordnen, zu strukturieren und aus einem anderen Blickwinkel zu betrachten bzw. zu hinterfragen.
 
Literatur:
Sonja Radatz (2000). Beratung ohne Ratschlag. Systemisches Coaching für Führungskräfte und BeraterInnen. VSM.
Alexa Mohl. Metaphern-Lernbuch: Geschichten und Anleitungen aus der Zauberwerkstatt. www.junfermann.de
Steve de Shazer (2010). Worte waren ursprünglich Zauber. Von der Problem zur Lösungssprache. Carl-Auer.

Geschrieben von

bgloger-redakteur bgloger-redakteur

TEILE DIESEN BEITRAG

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.