Chaos

Bild: Pixabay / Geralt - Lizenz

Vielleicht habe ich in letzter Zeit zu viele Grundlagenschulungen zum Thema agile Produktentwicklung gehalten, aber irgendwie ist mir danach etwas zum Thema Chaos zu schreiben. Nicht etwa weil sie chaotisch verlaufen wären, sondern weil ich dort entweder die Stacey Matrix oder das Cynefin Framework einsetze, um zu erklären, wo es Sinn macht agil zu arbeiten und wo nicht. In beiden Modellen kommt ein chaotischer Bereich vor und in beiden wird er oft anders beschrieben als ich es für sinnvoll halte.

Um mit der offensichtlichsten Frage zu beginnen - was ist das eigentlich, dieses Chaos? Vereinfacht gesagt handelt es sich bei ihm um einen Zustand der Unordnung, der sich durch (Eigen)Dynamiken und Vernetzung so schnell verändert, dass es nicht möglich ist, sich einen Gesamt-Überblick zu verschaffen und Ursache-Wirkungs-Zusammenhänge zu erkennen. Die Veränderungsgeschwindigkeit und Unübersichtlichkeit sind so gross, dass Informationen obsolet werden bevor sie vollständig sind.

Aus dieser Erklärung ergibt sich auch, dass Chaos kein gottgegebenes Schicksal ist. In beiden Modellen entsteht es durch die Zunahme der fördernden Faktoren, kann aber durch deren Eindämmung auch reduziert werden. Das ist ein wesentlicher Unterschied zu den Erklärungen die ich von vielen Beratern, Scrum Mastern und Agile Coaches gehört habe: in ihnen ist Chaos etwas was in bestimmten Situationen oder Umgebungen kategorisch da ist oder eben nicht.

Ein weiteres Missverständnis besteht darin, dass es angeblich methodische Vorgehensweisen gibt, mit denen man im chaotischen Bereich strukturiert arbeiten kann. Vor allem bei einer Bildersuche nach der Stacey Matrix findet man zahlreiche Visualisierungen, die unterstellen, dass man in ihm Agile- oder Lean- Ansätze wie Lean Startup, Design Thinking, Scrum oder Kanban einsetzen könnte. Beim Cynefin Framework ist dieses Missverständnis seltener, aber auch hier kommt es vor.

Dass es ein Missverständnis ist, ist dabei eigentlich leicht zu verstehen: egal ob es um das Testen eines MVP in Lean Startup oder eines Prototypen im Design Thinking geht, um Inspect & Adapt in Scrum oder um das Verbessern eines Arbeitsdurchflusses in Kanban - in jedem dieser Frameworks folgt ein zweiter Schritt auf einen ersten. Wenn die Ergebnisse des ersten sich im Chaos aber ständig verändern, dann hat der zweite Nichts worauf er aufbauen kann und das ganze Vorgehen bleibt ergebnislos.

Häufig wird dem in meinen Trainings mit dem Argument begegnet, dass das nur für manche, aber nicht für alle Menschen gelten würde. Wer schnelle Auffassungsgabe, grosse Erfahrung oder "agiles Mindset" habe bekäme auch Chaos in den Griff. Auch da fürchte ich - ein Missverständnis. In chaotischen Situationen wie Börsencrashs, Erdbeben oder Massenpaniken kann auch das grösste Genie keinen Überblick mehr herstellen (und BTW: viele IT-Grossprojekte haben Eigenschaften von Massenpaniken).

Was man in chaotischen Situationen machen kann, ist für Genies und Nicht-Genies gleich: Firefighting (verhindert kurzfristig Schäden, verbessert aber die Gesamtsituation nicht), Triage (im Vergleich weniger wichtige Elemente werden dem Untergang überlassen um die wichtigeren zu retten) und eine ggf. rabiate Reduktion von Chaos-Faktoren, indem diese (egal ob Einzelpersonen, Gruppen oder Systeme) ausgesperrt, isoliert oder in ihrer Wirkungskraft eingeschränkt werden.

An dieser Stelle wird auch klar, warum der im Chaos tatsächlich gegebene Handlungsspielraum nur selten thematisiert wird - es würde klar werden, dass das was ins Chaos hineingeraten ist, nur in Teilen zu retten ist, bzw. nur um den Preis der Beschädigung anderer Teilsystme. Das ist eine Wahrheit, die sich viele Berater ("es gibt für alles eine Lösung") und Manager ("kommen Sie mit Lösungen zu mir, nicht mit Problemen") nicht eingestehen wollen oder können.

Auch das ist übrigens menschlich und verständlich, dass man nur sehr ungern etwas verloren gibt, in dessen Aufbau man Zeit und Aufwand investiert hat, dürfte jeder nachvollziehen können. Die tragische Ironie dieser Geschichte ist aber, dass durch das verzweifelte Festhalten an umfassenden Rettungsvorhaben und unrealistischen Steuerungsphantasien das Chaos nur noch schlimmer wird, da es den realistischen Optionen Ressourcen entzieht.

Der beste Umgang mit Chaos ist daher, es gar nicht erst entstehen zu lassen. Und hier entfalten die zu Beginn genannten Modelle Stacey Matrix und Cynefin Framework ihre wahre Stärke: wenn man es einmal akzeptiert hat, dass Vorhaben in ihnen nicht einem der vier Bereiche (Einfach, Kompliziert, Komplex, Chaotisch) fest zugeordnet sind sondern sich zwischen ihnen bewegen, kann man gegensteuern sobald es klar ist, dass es in Richtung Chaos geht.

Geschehen kann das wie weiter oben beschrieben, durch die Eindämmung und Zurückdrängung von Chaos fördernden Faktoren. Das kann anstrengend werden, da dieses Zurückdrängen häufig aus System-Refactorings besteht, deren Sinn sicht Nicht-Technikern nicht erschliesst oder aus der bewussten Entscheidung Wünsche von Kunden oder Managern nicht zu erfüllen wenn dadurch Instabilität entsteht. Es ist aber immer noch deutlich weniger anstrengend als das Chaos selbst.

PS: da wir gerade bei Missverständnissen sind - zu den grössten gehört die Gleichsetzung von Chaos und Anarchie. Anarchie ist Ordnung ohne Herrschaft, Chaos ist Unordnung. Ein wesentlicher Unterschied.