Selbst ist das Team

Eigenverantwortliches Handeln von Menschen in interdisziplinären Teams ist eine der ebenso großen wie entscheidenden Veränderungen, die nötig sind um schnell und gut auf Veränderungen reagieren zu können. Dabei geht es auch immer darum, Probleme zu lösen.

Das bequeme Verständnis vieler Mitarbeiter sieht die Aufgabe des Problemlösens bei Führungskräften. Dabei ist es erst mal unwichtig, ob die Führungskraft klassisch organisiert disziplinarische oder fachliche Verantwortung hat, oder ob die Führung in einem agilen Kontext eher bei einem Scrum Master, Agile Coach oder Product Owner gesehen wird. Letztendlich ist die Annahme häufig: es gibt eine mehr oder weniger klar definierte Rolle deren Aufgabe es ist, Probleme zu lösen, weil sie dafür mehr Macht, Einfluss, Wissen oder Erfahrung hat oder weil es schlichtweg die Rollenbeschreibung ist.

Natürlich ist das totaler Quatsch! Eigenverantwortliches Handeln beinhaltet maßgeblich auch das eigenständige Lösen von Problemen jeglicher Art. Nur so entsteht eine schnelle Aktions- und Reaktionsfähigkeit. Und tauscht man bei einer Veränderung von einer Linien- zu einer agilen Organisation bezüglich der Verantwortung für die Lösung von Probleme nur die Rollen von (disziplinarischer) Führungskraft zu Scrum Master oder Agile Coach, die sich in ihrer Rolle um die Impediments der Mitarbeiter und Teams kümmern sollen, ist nicht viel gewonnen. Der Engpass wurde lediglich verschoben. Mit Eigenverantwortung hat das nicht viel zu tun.

Es ist weder die Aufgabe einer disziplinarischen Führungskraft, noch die des Scrum Masters oder Agile Coaches, als “Mädchen für alles” jedes Problem zu übernehmen oder zu lösen. Dafür haben sie  häufig weder Zeit, noch die größte Kompetenz, die meiste Erfahrung oder das tiefste Wissen. Um Engpässe zu vermeiden und eigenverantwortliches Arbeiten zu fördern, muss die Problemlösung bei selbstorganisierten, interdisziplinären Teams belassen werden – zumindest in den meisten Fällen.

 

Problemlöser ausbilden statt Probleme lösen

Vorab ein kleiner sinngemäßer Auszug aus dem Buch “Der Minutenmanager” von Kenneth Blanchard:

Ein neuer Projektmanager ruft bei seiner Führungskraft, dem Minutenmanager, an und sagt: “Herr Minutenmanager, ich habe ein Problem”. Darauf antwortet der Minutenmanager: “Super, denn zum Lösen von Problemen habe ich Sie eingestellt!” und legt wieder auf.

Die Aufgabe von Führungskräften – egal ob disziplinarisch oder fachlich oder in Form von Scrum Mastern und Agile Coaches – ist es Mitarbeiter zu befähigen, alle ihre Probleme selbst zu lösen, sich als ein Problemlösungsteam aufzustellen, statt selbst als Problemlöser aktiv zu werden. Ein großer Teil der Probleme kann besser eigenverantwortlich an dem Ort und von den Menschen gelöst werden, die das eigentliche Problem haben.

Eine gute Führungskraft zeichnet sowohl eine möglichst geringe Anzahl an übernommenen Eskalationen aus, als auch ihre Herangehensweise an diese Eskalationen. Sie weiß genau, wann sie selbst als Problemlöser gefordert ist und wann nicht, ganz unabhängig, ob sie in Form einer Eskalation um Problemlösung gebeten wurde oder nicht.

 

Die spannende Frage: wie kann ein Scrum Master, ein Agile Coach oder eine Führungskraft herausfinden, wann sie als Problemlöser gefordert ist und wie sie mit einer möglichen Eskalation am Besten umgeht?

Wann liegt die Problemlösung beim Team und wann nicht?

Die üblichen Fragen sind: “Wer kann das Problem am Einfachsten lösen?” oder “Wer kann das Problem am Schnellsten lösen?”.  Und Führungskräfte, die sich als “servant leader” verstehen, ergänzen gerne noch: “Was kann ich alles noch tun, um zu helfen?” Diese Fragen führen schnell weg von den Personen, die sich eigentlich kümmern sollten. Wenn es um die Eigenverantwortung von Mitarbeitern und Teams geht, dann geht es nicht immer um “einfach” oder “schnell”, sondern um “nachhaltig” und “richtig”. Besser sind andere Fragestellungen. Joseph Grenny (erfolgreicher Autor der New York Times) hat in einem Artikel dazu fünf Fragen oder Prinzipien benannt, die bei der Entscheidung helfen, ob eine Führungskraft selbst oder die Mitarbeiter ein Problem lösen sollen.

Wem gehört das Problem?

Bevor die Frage beantwortet wird, wie ein Problem gelöst werden kann, muss geklärt werden, wem das Problem eigentlich gehört – wer also für die Lösung des Problems verantwortlich ist und sich entsprechend darum kümmern sollte.

Beispiel: Ein Team bekommt durch einen internen Kunden unangemessen viel Druck, weil es mit den Auslieferungen in Verzug ist und es hat damit Schwierigkeiten. Damit gehört das Problems dem Team, weder irgendeine Führungskraft noch einem Agile Coach oder Scrum Master.

Natürlich könnte man jetzt sagen: das ist doch egal, Hauptsache das Problem ist gelöst. Die Gefahr aber ist: Wenn das Team das Problem nicht selbst löst, dann lernt es nicht ohne externe Unterstützung Grenzen zu setzen und für einen entsprechenden Umgang einzustehen. Das Team fühlt sich bestenfalls noch zuständig, aber nicht mehr verantwortlich, wird entmündigt und gibt dauerhaft einen Teil der Eigenverantwortung auf, macht sich abhängig von Anderen.

Bevor nun ein Scrum Master, Agile Coach oder eine Führungskraft vorschnell dem eigenen Bedürfnis Raum gibt,  das Team zu unterstützen oder zu schützen, sollte unbedingt die Frage geklärt werden, wem das Problem gehört und wer damit verantwortlich für die Beseitigung ist.

 

Besser schnell oder richtig?

Manchmal benötigen Probleme schnelle Entscheidungen. Sie bestehen vor allem aus zeitlichem Druck. Führungskräfte haben in der Regel mehr Macht. Da liegt der Schluss nahe, dass sie das Problem schneller gelöst bekommt. Und ja – mit mehr Einfluss und Macht kann es in der Regel zu schnelleren Entscheidungen kommen. Aber ist das gut?

Beispiel: Für ein zeitkritisches Projekt müssen Anforderungen der Kunden frühzeitig eingeholt werden und der Kunde reagiert nicht. Wenn der Kunde nicht schnell genug reagiert und damit das zeitkritische Projekt in Gefahr ist, wird schnell eine Führungskraft eingeschaltet und über Eskalationsebenen verhandelt.

Auch hier könnte man glauben, dass dieser Weg richtig ist. Die Gefahr in diesem Beispiel: Die Führungskraft kennt die konkreten Anforderungen nicht. Sie kann vielleicht eine rechtzeitige Lieferung sicherstellen, dabei aber nicht unbedingt gewährleisten, dass die gelieferten Informationen die Richtigen und Benötigten sind.

Die Frage für Scrum Master, Agile Coach oder Führungskraft ist in dem Fall, ob sie ausreichendes Wissen hat um die richtigen Anforderungen zu organisieren und ob es wichtiger ist, schnelle statt richtige und benötigte Informationen zu bekommen.  Auch hier ist es häufig besser, die Mitarbeiter bei der Problemlösung zu unterstützen, als aktiv in die Bresche zu springen.

 

Kann ich weniger tun?

Für viele Führungskräfte, gerade für die sehr mitarbeiterzugewandten oder auch für Agile Coaches und Scrum Master, ist es selbstverständlich, möglichst gut ansprechbar zu sein und so viel zu helfen wie möglich. Dabei übernehmen sie oft mehr, als sie sollten.

Wenn man weiß, wem das Problem gehört und wie groß der Zeitdruck gegenüber der Qualität des Ergebnisses wirklich ist, bleibt die Frage: Muss ich das alles wirklich tun für eine Unterstützung, oder kann ich auch weniger machen? Dabei geht es nicht um die eigene Faulheit sondern darum sicher zu stellen, dass der Mitarbeiter oder das Team das höchste Maß an Eigenverantwortung übernimmt, zu dem es in der Lage ist. Helfen können hier erfahrene Mitarbeiter, Führungskräfte oder auch Agile Coaches und Scrum Master dennoch.

Beispiel: Stell dir einen Manager vor, der den Schutzraum eines Scrum Teams ignoriert und am Product Owner vorbei zusätzliche Aufgaben im Team platziert. Das Team muss also einem Stakeholder, zu dem es wenig Kontakt hat, klare Grenzen aufzeigen. Schnell ist der Scrum Master auf dem Plan und weist den Manager in seine Schranken.

Besser wäre es, dem Team bei der Lösung des Problems zu helfen, indem zum Beispiel ein Gespräch mit dem entsprechenden Manager gemeinsam vorbereitet oder eine E-Mail gegen gelesen wird, um so im Laufe der Zeit beim Aufbau der Erfahrung zu helfen, die es dem Team zukünftig ermöglicht, sich selbst zu schützen.

 

Welche Art von Problem ist es?

Handelt es sich um ein inhaltliches Problem oder ein Muster oder um ein Beziehungsproblem? Die Antwort auf diese Frage hilft auch bei der Entscheidung, wer verantwortlich für die Lösung des Problems ist.

Bei inhaltlichen Problemen ist das Problem selbst auch das Problem. Wenn beispielsweise ein Mitarbeiter in einem Team eine Aufgabe zu einem bestimmten Zeitpunkt erledigen wollte, das aber nicht geschafft hat, dann ist das ein inhaltliches Problem. Das Problem ist die nicht bearbeitete Aufgabe.

Ein Muster bei Problemen besteht, wenn der problematische Umstand selbst häufiger Auftritt und damit nur Teil des ganzen Problems ist. Wenn also beispielsweise bestimmte Aufgaben in einem Team nie zum benötigten Zeitpunkt fertig werden, kann das ein Muster sein.

Beziehungsprobleme bestehen, wenn das Problem mit grundsätzlichen Bedenken hinsichtlich Kompetenz, Vertrauen oder Respekt zu tun hat. Diese Probleme erfordern meistens eine Änderung der Beziehung, der Struktur oder der Regeln und das sind Bereiche, in denen in aller Regel erst Scrum Master und Agile Coaches und dann auch Führungskräfte aktiv werden müssen, weil meistens nur sie in ihren Rollen die nötigen Möglichkeiten haben, um hier eine Lösung herbei zu führen.

 

In der Regel können und sollten Teams inhaltliche Probleme und Probleme, die als Muster auftreten, selbst lösen. Wenn also ein Mitarbeiter seine Aufgabe nicht rechtzeitig fertig bekommt, dann kann das Team gemeinsam überlegen, wie es helfen kann. Wenn es ein Muster gibt, nach dem bestimmte Aufgaben nie rechtzeitig fertig werden (weil beispielsweise die benötigen Informationen nie rechtzeitig vorliegen), kann das Team in den meisten Fällen auch selbst aktiv werden.

Wenn wir auf das Beispiel zurück kommen, in dem ein Manager immer wieder am Product Owner vorbei Themen im Team platziert, dann kann das der Grund dafür sein, dass Aufgaben immer wieder nicht rechtzeitig fertig werden. Das Problem gehört dem Team und es hat auch die meiste Erfahrung, um den Manager über die Konsequenzen aus diesem Handeln  aufzuklären – bei der Formulierung braucht es vielleicht noch etwas Unterstützung. Wenn das Problem nicht durch das Team, sondern kurzfristig durch den Scrum Master gelöst wird, dann wird bei weiter bestehendem Muster immer der Scrum Master gebraucht, um dem Team das Problem vom Leib zu halten.

Natürlich kann das Muster auch bei einer Lösung durch das Team weiter bestehen bleiben, selbst wenn das Team das Problem immer wieder adressiert – vielleicht ist dann trotz eigenverantwortlichem Handeln des Teams eine Eskalation nötig?

Eigenverantwortung trotz Eskalation?

Ja, manchmal hilft alles nichts – das Team fühlt sich verantwortlich für die Lösung eines Problems, es bekommt die nötige und richtige Unterstützung und trotzdem lässt sich das Problem nicht lösen. Meist ist es dann ein Beziehungsproblem und irgendwann muss eine Eskalationsinstanz – in unseren derzeitigen Unternehmen meist eine Führungskraft – aktiv werden. Auch hierbei kann sie die Eigen- und Teamverantwortung weiter stützen. Dafür muss die Eskalationsinstanz lediglich sicherstellen, dass alle Kontrahenten vorher versucht haben, ohne Eskalation das Problem zu lösen. Auch Eskalationsgespräche lassen sich besser in einem Dialog aller beteiligter Parteien führen. Außerdem sollten Eskalationsinstanzen immer zur Verfügung stehen, sich aber nur dann einbeziehen lassen, wenn alle beteiligten Parteien sich einig sind, dass die Eskalationsinstanz für die Problemlösung gebraucht wird.

Eine Eskalationsinstanz löst also die Probleme, die andere untereinander nicht gelöst bekommen. Sie tritt nicht als Unterstützer oder Vertreter einer Partei auf, sondern sorgt im gemeinsamen Dialog mit den Kontrahenten für eine Lösung.

 

Der wesentliche Beitrag von Scrum Mastern, Agile Coaches und Führungskräften ist das Entwickeln und Begleiten von hochperformanten Teams. Wesentlicher Treiber für hochperformante Teams und Organisationen ist ein hohes Maß an Eigen- und Teamverantwortung. Manchmal lassen sich Eskalationen nicht vermeiden, aber wenn sie auf ein Mindestmaß reduziert und richtig angegangen werden, dann hilft das beim Aufbau von erfolgreichen Teams.

(Das verwendete Bild ist von Alexander Baxevanis – Vielen Dank!)