Viele agile Teams ergeben keine agile Organisation

Ich würde sogar soweit gehen, dass, selbst wenn alle Teams agil sind, ich nicht zwangsläufig eine agile Organisation habe. Und um noch eins draufzusetzen: Agil ist kein Ziel 😉 Ich habe mich vor ein paar Tagen mit zwei anderen Coaches unterhalten und habe diese Aussagen im Gespräch mal rausgehauen. Da die beiden sie so spannend fanden, möchte ich sie nun auch dir näherbringen.

Wie komme ich dazu? Bevor ich das erkläre, möchte ich erst einmal definieren, was ein agiles Team bzw. eine agile Organisation ist.

Definition agiles Team & agile Organisation

Disclaimer: Ehrlich gesagt, sind das nun nicht wirklich meine Definitionen (wie es sein sollte, erläutere ich später), aber so erlebe ich es häufig.

Gemäß meiner Erfahrung bedeutet „agiles Team“ häufig, dass ein Team das Framework Scrum oder die Methode Kanban nutzt. Dabei hat sich weit verbreitet, unabhängig von der Vorgehensweise die Scrum Rollen (lt. Scrum Guide 2020: Ergebnisverantwortlichkeiten) zu implementieren: Product Owner:in, Scrum / Agility Master:in und Developer:innen.

Die betroffenen Teams bestanden dabei teilweise schon vorher oder wurden im Zuge der agilen Transformation (cross-funktional) zusammengestellt. Dabei wurden im Hintergrund von Transformationsverantwortlichen die Produkte / Services definiert, die dann die Kernaufgabe eines Teams ausmachen.

Wenn ich dann frage, was denn nun die agile Organisation ausmacht, wird es schwieriger. Manchmal macht man zumindest den Fortschritt daran fest, wie viele Teams „agil“ sind, sprich einem Framework folgen. In der Regel will man aber eigentlich eher das (so meine Hypothese): ein dynamikrobustes Unternehmen, was schnell und adäquat auf Veränderungen im Markt reagieren kann und dabei immer den Kunden im Fokus hat.

Begründung meiner These

Vielleicht ahnt ihr jetzt schon, wie ich zu der These komme, dass viele agile Teams keine agile Organisation ergeben. Wenn ich mit „agile Organisation“ nämlich ein dynamikrobustes Unternehmen meine, dann bedeutet das, dass ich alles auf die Wertschöpfung ausrichten muss. Mit Wertschöpfung meine ich den Prozess von „Kunde ruft an“ bis „Kunde erhält sein Produkt“. Das muss möglichst schnell gehen. Und drumherum brauche ich sicher auch ganz viele weitere Prozesse. Und all diese Prozesse müssen auf den Kunden ausgerichtet sein.

Ihr merkt, dass das nichts mit agilen Frameworks zu tun hat, sondern mit Organisationsdesign. Deswegen ist „Agil“ eben auch kein Ziel. Der Griff in die „Agile Frameworks“-Kiste ist eben nur eine Möglichkeit dem gewünschten Organisationsdesign näher zu kommen und beschreibt damit nur einen Teil des Weges. 

Aber was passiert nun, wenn ich die Teams isoliert voneinander „agil aufsetze“? Meiner Erfahrung nach passiert genau das, was es vorher schon gab: Ich bekomme Silos, unabgestimmte Schnittstellen, unklare Verantwortlichkeiten usw.  Jetzt fragst du dich vielleicht, wie das sein kann, wenn die Teams doch agil sind… Gute Frage 😉 ich erlebe, dass diese Teams häufig nur einem Prozess folgen, der nun mal eben Scrum, Kanban oder so heißt. Wirkliche Ende-zu-Ende-Verantwortung für die Wertschöpfung gibt es häufig nicht, sodass man nicht wirklich nach links und rechts schauen muss.

Ein weiteres Phänomen, welches ich beobachte: diese Teams optimieren sich einzeln oft wunderbar. Der Haken ist nur, dass wir aus der Systemtheorie wissen, dass Lokaloptimierungen niemals zur Optimierung des Gesamtsystems führen. Ist ja auch klar: was für mein Team vielleicht gut ist, bedeutet aber eventuell eine langsamere Schnittstelle.

Keine Frage: es mag eine gute Idee sein, mit einzelnen Teams anzufangen. Früher oder später muss ich aber über meine gesamte Wertschöpfung nachdenken und den Teams helfen, über ihren Tellerrand zu sehen.

Exkurs: warum agil eigentlich eh nichts mit Frameworks zu tun hat

Jetzt denkst du vielleicht: „Hä?“ Wenn du mir kurz zu der Wurzel von der „agilen Bewegung“ folgst, dann wirst du es verstehen: Manifesto of Agile Software Development. All die Kritik, dass die Runde absolut nicht divers war, sondern nur weiße Männer gleichen Alters, lassen wir jetzt mal bitte außen vor.

Da trafen sich also Männer, die selbst schon unterschiedliche Frameworks entwickelt hatten. Um nur ein paar zu nennen: Jeff Sutherland und Ken Schwaber sind die Autoren von Scrum; Ron Jeffries, Kent Beck und Ward Cunningham sind die Begründer von Extreme Programming. Sie hatten also eigentlich unterschiedliche Ansichten, wie denn Software Programmierung „richtig“ geht. Aber sie haben sich alle gefragt, was haben sie denn gemeinsam? Welche Werte und Prinzipien können sie alle vertreten, unabhängig davon, wie man das dann konkret lebt? Das Ergebnis kennen wir: das Manifest.

Und darum hat agil erst mal nichts mit Frameworks zu tun: diese Männer haben sich damals bewusst dafür entschieden, die Details beiseite zu lassen und nur zu schauen, was wirklich wichtig ist. Wenn ich also agil sein will, kann ich einen Check gegen das Agile Manifest machen. Dafür brauche ich kein Framework. Es ist sogar so, dass wenn du deine Teams dazu zwingst, ein Framework zu nutzen, verstößt du gegen das Manifest, denn: Individuals and interactions over processes and tools. Das gilt genauso für uns Agile Coaches, denn die Verantwortung sollte beim Team liegen, wie sie am besten ihre Arbeit machen. Agil ist da vielleicht nicht immer der beste Weg. (Mehr dazu von Martin Fowler, ebenso Unterzeichner des Agile Manifesto: The State of Agile Software in 2018)

Fun fact: es ist wohl nur Zufall, dass „agil“ das Zauberwort ist. Im Rennen waren wohl auch noch „adaptability“ und „flexibility“. Man konnte sich aber eben nur auf Agil einigen 😉

Mein Tipp für eine „agile Transformation“

Lass‘ deine Teams die Arbeit machen und bringe sie nicht davon ab,  indem sie sich mit einem Framework beschäftigen müssen. Hilf‘ ihnen lieber, ihre echten Probleme zu erkennen. Eine Frage könnte hier sein: „Woher kommen gerade Unzufriedenheiten? Beim Kunden? Bei der Organisation? Beim Vorgesetzten? Im Team?“ Und dann gib‘ ihnen alles, was sie brauchen, damit sie die Probleme lösen können. Dann wirst du vielleicht merken, dass du agil gar nicht zu deinen Problemen passt. Also, pass‘ auf, dass du nicht mal sagen musst: „Ich habe eine Lösung, ich suche aber noch das Problem“ 😉

Und bitte sei auch okay damit, wenn dein Team zuerst einen un-agilen Weg wählt, denn die Verantwortung bei ihnen zu lassen, ist wahre Agilität.

Ein gute Hilfe bei dieser Art von Transformation ist das Engagement Model von Daniel Mezick: OpenSpace Agility. (Und ob es wirklich so gut ist, alles eine Transformation zu nennen, erläutere ich mal ein einem weiteren Beitrag.)

Hast du weitere Ideen? Schreib‘ mir gerne.

Schreibe einen Kommentar