5 Ursachen, die agile Teams scheitern lassen

In vielen klassischen Definitionen zur Rolle des Scrum Masters, verantwortet er das Rahmenwerk. 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 endet bei manchen Projekten sein Aufgabenbereich. Das führt dann dazu, 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. Ich habe häufig beobachtet, dass das zu folgenden Problemen führt:

1. Kolleg:innen fühlen sich nicht „enabled“ oder „empowered“, sondern schlicht überfordert. Die Vorteile der neuen agilen Arbeitsweise sind unklar und vor allem nicht spürbar. Ein Developer zum Beispiel sollte selbstwirksam Prozesse ohne Umwege verändern können und Probleme in multifunktionalen Teams mit großem Handlungsspielraum sofort lösen. Ist diese Voraussetzung nicht gegeben, bedeutet das scheinbar nur Mehraufwand ohne sichtbaren Nutzen. Neue Rituale und Meetings fühlen sich wie eine zusätzliche Last an.

2. Hochmotivierte Kolleg:innen preschen los und erfinden ihre eigenen Prozesse. Da sie bisher nicht organisationsübergreifend gearbeitet haben, vergessen sie aber, 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 eine hohe Abhängigkeit von einzelnen Personen. Sind diese krank oder auch nur länger in Urlaub, fällt das Kartenhaus zusammen. Wird die agile Arbeitsweise gleich in mehreren Abteilungen ausgerollt, ohne die selbst geschaffenen Prozesse zu synchronisieren, ist eine spätere Skalierung schwer bis unmöglich, da an den selbst entwickelten Prozessen festgehalten wird.

Klingt nach einer großen Führungsherausforderung? Genau das ist es auch! Die Hierarchien fallen zwar weg, 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 wie ein Coach, der die intrinsische Motivation fördert und Hürden aus dem Weg räumt.

Übernimmt eine disziplinarische Führungskraft, die in der sonstigen Unternehmenshierarchie über den Teammitgliedern steht, diese Aufgabe, kommt es immer wieder zu Problemen – wo wir wieder bei der richtigen Besetzung wären. 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 ja, 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.

Unterschiedliche Umstände und Teams erfordern vom Scrum Master situatives Führen. Leider liegt der Fokus viel zu häufig auf den Prozessen, nicht 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 innerhalb der Teams, sondern allen Stakeholder im Unternehmen gegenüber.