Interview mit Paul Weißhaar: Warum agile Teams so häufig scheitern
Sie haben in letzter Zeit in vielen Konzernen agile Projekte und Teams begleitet, die ins Stocken geraten sind. Was hatte man sich von ihnen erhofft und woran hakte es in den meisten Fällen?
Agile Teams sollen eigentlich in der Lage sein, schnell auf Veränderungen zu reagieren und selbstständig Entscheidungen zu treffen. Vom Konzept her ist das in der heutigen Zeit, die von Krisen und schnellen Veränderungen geprägt ist, natürlich genau der richtige Ansatz mit selbstorganisierten und meist abteilungsübergreifenden Teams zu arbeiten. In der Praxis beobachte ich oft, dass die Pilotteams, beispielsweise von Scrum-Prozessen, in den Unternehmen zwar oft erfolgreich waren, es aber beim weiteren Ausrollen plötzlich hakt. Das ist auch kein Wunder, denn die Pilotteams bestehen häufig aus Teammitgliedern, die sich dafür freiwillig gemeldet haben und hochmotiviert sind. Leichtes Spiel für alle am Prozess Beteiligten. Später ist es aber immer entscheidender, dass die Rollen in den agilen Teams richtig besetzt sind. Sonst herrscht schnell Frust und Überforderung. Welche Rolle am häufigsten fehlbesetzt oder an der gespart wird, ist die des Scrum Masters.
Was ist denn die Aufgabe des Scrum Masters?
Der Scrum Prozess ist eine agile Methode, bei dem klassische Hierarchien wegfallen. Es wird zwar meist ein Ziel vorgegeben, beispielsweise die möglichst effiziente Entwicklung eines Produktes oder einer neuen Dienstleistung. Wie dieses Ziel erreicht wird, bleibt allerdings dem Team selbst überlassen. Statt Hierarchien gibt es mehrere Rollen: den Srcum Master, den Product Owner und den Developer.
In vielen klassischen Definitionen zur Rolle des Scrum Masters, ist er für das Rahmenwerk verantwortlich. Er hält dem Team den Rücken frei, trifft Rücksprachen mit dem Product Owner und übernimmt administrative Aufgaben. Er führt die Prozessregeln ein und prüft deren Einhaltung. Und hier hört es bei manchen Projekten dann auch schon auf. Ich beobachte häufig, dass nach dem Ausrollen der Scrum Rituale und einer theoretischen Einführung das Team sozusagen allein gelassen wird. Es soll sich ja schließlich selbst organisieren. Das führt häufig zu folgenden Problemen:
1. Kolleg:innen fühlen sich nicht „enabled“ oder „empowered“, was sie eigentlich sollten, sondern schlicht überfordert. Die Vorteile der neuen agilen Arbeitsweise, zum Beispiel als Developer selbstwirksam Dinge ohne Umwege zu verändern und Probleme in multifunktionalen Teams mit großem Handlungsspielraum sofort zu lösen, sind unklar und vor allem nicht spürbar. Der Mehraufwand schon. Die neuen Rituale und Meetings fühlen sich als zusätzliche Last an.
2. Oder die bereits gut selbstorganisierten Kolleg:innen laufen los und erfinden ihre eigenen Prozesse. Da sie bisher aber häufig noch nicht organisationsübergreifend gearbeitet haben, vergessen sie, den Rest des Teams abzuholen. Zu groß ist die Versuchung, schnelle Lösungen zu finden und sich damit selbst ins Rampenlicht zu stellen. Dadurch entsteht zum einen eine hohe Abhängigkeit von einzelnen Personen, mit denen alles steht und fällt. Sind sie krank oder auch nur länger in Urlaub, fällt das Kartenhaus zusammen. Zum anderen führt das vor allem dann zu Problemen, wenn die agile Arbeitsweise gleich in mehreren Abteilungen ausgerollt wird und verschiedene agile Teams parallel laufen. Werden die Prozesse nicht von Anfang an unter den einzelnen Teams synchronisiert, ist eine spätere Skalierung schwer bis unmöglich, da sie an den selbst entwickelten Prozessen festhalten werden.
Es ist daher unvermeidlich, dass der Scrum Master auch während des Prozesses Schwierigkeiten aus dem Weg räumt. Dazu gehören mangelnde Kommunikation, Probleme bei der Zusammenarbeit oder persönliche Konflikte. Aber auch Störungen von außen muss er begegnen, damit das Team in Ruhe arbeiten kann – zum Beispiel, wenn die Fachabteilung ihren Mitgliedern zusätzliche Aufgaben zuteilt. Die Verantwortung des Scrum Masters ist es, sowohl Stakeholder als auch die Teammitglieder zu „erziehen“, den Fokus und das Commitment für die gesteckten Ziele nicht zu verlieren. Wenn nötig ist er sogar verpflichtet, Eskalationen durch das Management einzuleiten.
Das klingt eigentlich doch nach klassischen Führungsaufgaben…
Genau das ist der Punkt. Die Hierarchien fallen zwar weg und trotzdem braucht gerade der Scrum Master ausgezeichnete Führungskompetenzen. Er ist eine dienende Führungskraft für das Entwicklungsteam. Er führt nicht disziplinarisch mit Anweisungen, sondern eher als Coach, der die intrinsische Motivation fördert und Hürden aus dem Weg räumt. Auch wenn es Führungskompetenzen braucht, gibt es aber deshalb auch Schwierigkeiten, wenn eine disziplinarische Führungskraft, die in der sonstigen Unternehmenshierarchie über den Teammitgliedern steht, diese Aufgabe übernimmt. Ich beobachte leider immer wieder, dass die Rolle so besetzt wird. Das führt zu mehreren Problemen: Eine Führungskraft aus dem Unternehmen ist meist nur für einen Teil des Teams disziplinarisch verantwortlich. Denn die Idee von agilen, selbstorganisierten und empowerten Teams ist, dass sie multifunktional vertreten sind. Es herrscht mit Mitarbeiter:innen aus anderen Abteilungen ein Ungleichgewicht im Team. Die direkt unterstellten scheinen besser zu hören. Er soll aber eigentlich gar nicht per Anweisung führen oder die Mitglieder bewerten.
Sondern?
Offiziell moderiert der Scrum Master vor allem die einzelnen Rituale und Prozesse wie die Sprint Retrospektive, das Sprint Planning und das Backlog Refinement. Unterschiedliche Umstände und Teams erfordern vom Scrum Master allerdings situatives Führen. Leider liegt der Fokus viel zu häufig auf den Prozessen statt auf den Menschen. Statt zu coachen und wirklich zu führen, wird nur die Theorie referiert, wie sie im besten Fall funktionieren soll. Aber jedes Team, jede Abteilung und jedes Unternehmen haben ihre eigenen Arbeitsweisen und ihre eigene Kultur. Einzelne Abteilungen und ihre Mitglieder sind in Sachen agilem Mindset weiter als andere.
Situatives Führen erfordert zwei Komponenten: aufgabenbezogenes Führen und menschenbezogenes Führen. Ersteres erfordert Delegationsgeschick, letzteres ein tiefes Verständnis für die unterschiedlichen Persönlichkeiten. Menschen sind so unterschiedlich wie ihr Fingerabdruck. Um die Teammitglieder wirklich zu motivieren und zur Selbstorganisation zu befähigen, muss sich eine Führungskraft immer an sie anpassen. Sie braucht ein unglaubliches Kommunikationsgeschick. Nicht nur den Teams gegenüber, sondern aller Stakeholder im Unternehmen.
Wer übernimmt diese Rolle denn am besten, wenn keine erfahrene Führungskraft aus dem Unternehmen?
Die Rolle des Scrum Masters ist eine Vollzeitstelle – zumindest zu Beginn. In der Praxis werden aber wie gesagt, Führungskräfte damit betraut, die diesen Job zusätzlich zu ihrem eigentlichen Job aufgebürdet bekommen. Im besten Fall bekommen sie noch eine zweitägige Scrum-Master-Schulung und sollen dann die Theorie in die Praxis umsetzen. Der Fokus liegt dann so sehr auf der Technik, dass für wirkliche Führung – sprich, die Menschen dort abholen, wo sie sind, und sie durch den Changeprozess zu begleiten – keine Zeit bleibt.
So verlieren wichtige Rituale, wie „die Retrospektive“ schnell an Bedeutung. Dabei ist gerade die Retrospektive ein mächtiges Werkzeug, um das Team Schritt für Schritt zu formen und dessen Arbeitsweise kontinuierlich zu verbessern. Am Ende eines jeden Sprints, dient sie dazu, die bisherige Arbeitsweise zu reflektieren, um Ansätze zur Steigerung der Effizienz zu identifizieren, die dann im nächsten Sprint umgesetzt werden. Dabei soll das Team seine Arbeitsweise in einem geschützten Raum offen und ehrlich überprüfen können. Das ist noch ein Punkt, warum es schlecht ist, wenn der Scrum Master über Teile des Teams auch disziplinarisch verfügt.
Wird dagegen ein Kollege oder eine Kollegin für diese Rolle ausgewählt, fehlt schlicht und einfach in den meisten Fällen die Führungserfahrung. Die Retrospektive verkommt bei fehlender Führung leider häufig zu einer „Auskotzrunde“. Es werden Probleme im außen aufgezeigt, allerdings ohne Konsequenz, denn dem Scrum Master aus dem eigenen Team fehlt es häufig an den notwendigen Ressourcen, um nach außen signifikante Veränderungen herbeizuführen. So bleiben Themen wochen- oder monatelang nicht bearbeitet und die Motivation sinkt. „Passiert ja eh nichts“ – so der Eindruck.
Wie geht es denn besser?
Ich plädiere mittlerweile tatsächlich dafür, dass Unternehmen zumindest für das Ausrollen der agilen Projekte auf Externe setzen, die in Scrum ausgebildet sind und über langjährige Führungserfahrung verfügen. Beides braucht es für erfolgreiche Veränderungen. Wenn die Person aus dem Unternehmen kommt, muss es auf jeden Fall eine erfahrene Führungskraft sein, die eine Scrum Schulung durchlaufen hat, für diese Rolle die volle Arbeitszeit zur Verfügung hat und aus einem fremden Bereich kommt – also keine direkte Vorgesetzte/direkter Vorgesetzter eines Teammitglieds ist. Hier sollten Unternehmen wirklich nicht sparen und eine Vollzeitstelle schaffen.
Sobald ein gewisses Level an Eigenorganisation erreicht ist, kann sich der Scrum Master auch ruhig wieder zurückziehen und seine Moderations-Aufgaben an Teamkollegen übergeben oder daraus eine rotierende Aufgabe machen. Aber auf dem Weg zur Selbstorganisation müssen eventuell noch Prozesslücken im Unternehmen aufgedeckt werden, die vorher durch Individuen besetzt wurden etc. Diese Rahmenbedingungen müssen erst stimmen und das Team braucht klare Leitplanken, in denen es sich sicher bewegen kann.
Stockt es in einem Team bereits, rehabilitiere ich häufig nach den Gesprächen mit den Mitgliedern und Stakeholdern die Retrospektive wieder. So lassen sich die Themen der Einzelnen wieder für das ganze Team transparent darstellen. Dabei bleibt es allerdings nicht, denn sie müssen auch wieder ihre Selbstwirksamkeit und Handlungsmacht spüren. Daher werden erst Themen identifiziert, die sie aus eigener Kraft lösen können. Prozesse werden abgestimmt, Entscheidungsrahmen gesetzt und nach kurzer Zeit können sie bereits Verbesserungen feststellen. Der Mensch und seine Bedürfnisse im Prozess werden wieder stärker in den Fokus genommen. Jeder dort an die Hand genommen, wo er oder sie gerade steht und in der eigenen Geschwindigkeit durch den Change begleitet. Das macht einen riesen Unterschied und ist am Ende erfolgsentscheidend.
Größere Unternehmen mit mehreren Abteilungen, welche die agile Arbeitsweise Konzernweit ausrollen und skalieren wollen, sind gut beraten, von Anfang an eine Zentrale Abteilung, eine Art „Agile Competence Center“ zu etablieren. Diese Abteilung besteht im besten Fall aus professionellen Change-Agents und Coaches, die zusammen mit den Teams „best practice methods“ entwickeln und diese in allen Bereichen synchronisieren. Denn für erfolgreiches agiles Arbeiten braucht es einiges mehr als nur die einzelnen Rollen Scrum Master, Product Owner und Entwicklungsteams. Neben den Rollen müssen weitere Bausteine, wie die „Agile Fundamentals“, das „Backlog Management“, die „Performance“ und „Behavior“, sowie das „Alignment“ stetig weiterentwickelt und in den Teams etabliert werden.