Selbstorganisation klingt nach Autonomie und Freiheit: Selbstbestimmung und mehr Möglichkeiten für die Teams und Abgabe der Verantwortung durch die bisher „Verantwortlichen“ an die, welche die eigentliche Wertschöpfung betreiben. Also in jedem Fall eine tolle Sache, oder?
Neulich im Büro…
Was Ist passiert?
(1) Ein Teil des Frameworks wurde weggelassen. Es gab auch einen „guten“ Grund dafür: Hier war es in der ersten Betrachtung die Effizienz, die häufig wie ein Mantra in unseren Unternehmen verwendet wird. Dahinter steht eine Denkweise, die aus den Anfängen des Industriezeitalters stammt.
Kommt Euch das so oder ähnlich bekannt vor?
Und weiter…
(2) Der Gedanke „wir haben doch selbst-organisierende Teams“ kam auf. Verlockende Idee, im ersten Reflex die Verantwortung für die Abstimmung an die Teams abzugeben.
Die Effizienz-Falle bei der Adaption eines agilen Frameworks:
Effizienz bedeutet allgemein, mit wenig Aufwand zu gewünschten Ergebnissen zu kommen und ist im ökonomischen Bereich ein Maß für die Wirtschaftlichkeit, beinhaltet also konsequentes Kosten-Nutzen Denken.
Effizienz= Ergebnis / Aufwand
Voraussetzung dafür ist ganz allgemein, dass es sich um wohlbekannte Prozesse handelt die im Wesentlichen linear ablaufen, also wenig Komplexität beinhalten. Da sieht man sich einfach die einzelnen Schritte an und versucht diese zu optimieren.
Angewendet auf ein komplexes agiles Framework führt dies aber oft nicht zum Erfolg. Greife ich einen Teil heraus, laufe ich Gefahr eine lokale Optimierung zu machen, welche sich jedoch auf das Gesamtsystem negativ auswirken kann.
Im Scrum Guide heißt es beispielsweise: „Das Scrum-Rahmenwerk besteht aus Scrum-Teams und den zu ihnen gehörenden Rollen, Ereignissen, Artefakten und Regeln. Jede Komponente innerhalb des Rahmenwerks dient einem bestimmten Zweck und ist unentbehrlich für den Einsatz von Scrum und dessen Erfolg.“ Dies gilt genauso für skalierende Frameworks wie LeSS, SAFe, Scrum@Scale, Nexus, etc.
Die einzelnen Komponenten bestehend aus Rollen, Ereignissen, Artefakten und Regeln bilden ein Gesamtsystem und hängen wie ein mehrdimensionales Netz zusammen. Schön veranschaulicht wird das in einem mechanischen Tensegrity Modell, dessen einzelne Komponenten flexibel miteinander verbunden sind. Wenn man an einer Stelle zieht oder drückt, ändert sich die komplette Struktur.
Kann ich denn hier nicht auf Selbstorganisation zählen?
Wenn Mechanismen fehlen, die den Teams in der übergreifenden Zusammenarbeit helfen, dann ist die Misere vorprogrammiert: Die Teams sollen zu ihrer bisherigen oft übergroßen Last sich selbst und übergreifende Themen organisieren und
möglicherweise auch noch mangelnde Priorisierung kompensieren, wozu sie kaum in der Lage sein werden. Dann bilden sich Kommunikationstunnel, Einzelpersonen oder Grüppchen reden miteinander, andere nicht, ein Team versucht etwas anzuschieben, wird aber nicht unterstützt – letztendlich chaotische Zustände. Schließlich habt ihr fehlerhafte übergreifende Features, unvollständig, unkoordiniert implementiert, die nicht getestet werden können etc.
Selbstorganisation – ein unbedingtes „ja!“, aber …
… eben nicht als Ausgleich für fehlende Struktur. Wenn die richtigen Strukturen vorhanden sind, in denen Selbstorganisation stattfinden kann ja, ansonsten Finger weg!
Selbstorganisation in der Gruppe benötigt einen förderlichen, stabilen Rahmen, in dem sie stattfinden kann. Fehlt dieser, dann findet auch eine Art „Selbstorganisation“ statt, dies aber auf eine chaotische Weise. Das skalierende agile Framework muss also sauber eingeführt sein – zusammen mit allen Mechanismen, welche die Selbstorganisation der Teams erst ermöglichen. Lasst euch mit der Adaption des Frameworks viel Zeit, um Erfahrung zu sammeln, um zu spüren wie sich das als Gesamtes anfühlt. Bis Ihr schließlich auch merkt, wo ihr Schwierigkeiten habt und warum bzw. wo die wirklichen Ursachen liegen, und was Selbstorganisation eigentlich genau bedeutet. Erst dann könnt Ihr langsam anfangen, an den Stellschrauben zu drehen.
Viel Spaß beim ausprobieren und Erfahrung sammeln!
Mir hat auch der Abschnitt über ‚Selbstorganisation‘ sehr gut gefallen:
Welche Voraussetzungen erfüllt sein müssen, damit Selbstorganisation auch funktionieren kann.
Daß ‚Selbstorganisation‘ eben nicht ein sich auf ‚magische Weise‘ selbstorganisierendes Chaos bedeutet.
Das ist – auch – in der Startphase einer Organisation wichtig, da hier per Definition kaum Strukturen vorhanden sind, die den Rahmen halten (z.B. Start Ups).
Sehr gut dass Du das Thema Effizienz thematisierst. Das ist die Dringlichkeitsfalle. Ich muss vorwärts machen, obwohl ich das Big Picture noch nicht verstanden habe. Die Organisation muss eigentlich noch mehr lernen, aber wegen der Dringlichkeit geht das nicht. Manchmal muss zum lernen auch hinfallen. Solange das nicht existentiell ist kein Problem.
Hi Henrik, danke für Deinen guten und hilfreichen Artikel. Ich glaube, dass viele die agile Projektarbeit irgendwie gut finden, aber oft dann doch indirekt ablehnen, weil ihnen die Selbstorganisation der Teams suspekt ist. Ich selber habe es erlebt, was Du als fehlenden förderlichen Rahmen beschreibst; vor allem ein Top-Management, das auf strikte Einhaltung von Meilensteinen gepocht hat und die Rolle des Projektleiters „altmodisch“ interpretiert hat. Ich glaube, es ist enorm wichtig für jedes Projekt klar zu definieren, was Agilität in der jeweiligen Umgebung genau heißt und wieviel davon möglich ist. Dann wird es klappen und man erhält bessere Ergebnisse als in der klassischen Wasserfallmethode .
schöner Artikel