Kunden und Kollegen verwickeln mich in letzter Zeit immer wieder in Gespräche über den Sinn und Unsinn von agilen Skalierungsframeworks. Keine Frage – sie haben einen gewissen Charme: Das Thema Agilität ist im Großen und Ganzen für Digitalisierung gesetzt. Eine zunehmende Anzahl an Unternehmen schafft es, durch Methoden wie Scrum oder Design Thinking dynamisch auf wechselnde Kundenanforderungen zu reagieren – und die, die es noch nicht geschafft haben blicken etwas neidisch zur Konkurrenz oder Fragen uns als Agile Coaches, wie ihnen das auch gelingen kann. Als Coaches werden wir heute wiederum nicht mehr gefragt, „Warum oder ob agil Sinn macht?“ – der Drops ist gelutscht. Die Frage lautet heute vielmehr „Wie schaffen wir die Transition ganzer Einheiten oder Unternehmen?“

Agile Entwicklungsmethoden Frameworks geben dabei in einer Phase der Unsicherheit und Dynamik einen gewissen Halt und Sicherheit. Agile Transitionen passieren ihrer Natur nach im laufenden operativen Betrieb, also am offenen Herzen des Unternehmens. Bei so einer Operation beruhigt es die Angehörigen, also Manager und Stakeholder wenn der Doktor erfahren ist, bewährte Techniken nutzt und sich regelmäßig methodisch fortbildet. Die Devise lautet „nur die beste Medizin für den Patienten“. – Und hier kommen Frameworks ins Spiel: Sie haben an anderer Stelle ja schon bewiesen, dass sie funktionieren. Sie lassen sich dazu je nach persönlicher Situation und Präferenz auswählen und implementieren:

Dean Leffingwells SAFe ist vor allem in großen Unternehmen beliebt, da es eine gewisse Struktur, Hierarchie und Rollen vorgibt, in denen sich Konzerne wiederfinden. Craig Larmans LeSS ist das genaue Gegenteil dazu: sehr puristisch, überzeugt auf den ersten Blick mit einem vergleichsweise geringen Overhead. Man könnte sagen, dass SAFe das ist, wo Konzerne herkommen und LeSS das ist, wo alle hin wollen. Dazwischen gibt es noch andere beliebte Modelle, wie Henrik Knibergs Spotify-Modell, dass leichtgewichtige Entwicklung mit Synchronisation innerhalb der bekannten Domainen verbindet und Malte Foegens Digi-Org-Modell, das sich weniger auf Frameworks dafür mehr an Prinzipien zur agilen Ausgestaltung von Gesamtorganisationen orientiert. Am Ende des Tages: Stangenware! – mit zwei Tücken:

Organisation ist bekanntlich ein Zusammenspiel aus Strategie, Struktur und Kultur. Verändert man die Struktur, beeinflusst das auch Strategie und Kultur. Wählt man also ein Framework, das nicht zu Strategie und Kultur passt, oder ändert man die Struktur schneller, als Strategie und Kultur mitziehen können, kracht’s.

Gefährlich wird es auch, wenn wir im Gewirr zwischen Squads und Tribes, CoPs und CPOs die Übersicht über die Vokabel verlieren und der Coach von der Entwicklungshilfe zum Erfüllungsgehilfen wird. Wir erkennen diese Situation meistens am Satz „ich will das genau so wie es da beschrieben ist, (aber…)“.

Das „Aber“ erfolgt in der Regel mehr oder weniger mittelbar und ist mehr oder weniger schwerwiegend. Grundsätzlich sind Frameworks genau das, was der Namen sagt: Leitplanken, im Rahmen derer ein Prozess gestaltet werden kann. Es gibt also jede Menge Raum für Anpassungen an den Kontext des Unternehmens. Es gibt also auch Platz für „Aber“. Allzu oft verlässt das „Aber“ dabei leider den Rahmen des Frameworks.

„Das geht vielleicht in der Software-Entwicklung, ABER in der Hardware-Entwicklung können wir das so nicht machen.“ – „Ja, ich verstehe das, ABER wir möchten erst einmal so anfangen.“ – „Ja, ich will Axt schleifen, ABER ich muss erst noch etwas mehr Holz hacken“

Auf das „Aber“ folgt das „Aber“

Frameworks sind keine Bauanleitungen, sondern abstrahierte Modelle, die konsolidieren, was im Rahmen eines Prozesses funktioniert hat. Dabei handelt es sich um einen gemeinsamen Nenner, die Reduktion hat dabei bereits stattgefunden. Anders gesagt: Klar kann man’s machen. Ist nur die Frage, ob das dann auch wirklich so funktioniert, wie man sich es anfangs vorgestellt hat.

„One fits all“

Tailorn muss man aber auf alle Fälle. Trotz des Haltes und der Sicherheit, die agile Frameworks vermitteln, darf man nicht in den Glauben verfallen, dass es sich um Stangenware handelt. Organisationen haben eine individuelle Kultur und damit unterschiedliche Konturen. Nur weil ein Modell, das einen Stand der (agilen) Entwicklung zu einem bestimmten Zeitpunkt beschrieben hat, in seinem Kontext funktioniert, bedeutet das nicht, dass es mit der Blaupause auf eine andere Organisation übertragen werden kann.

Die Tatsache, dass ein Framework zu einem bestimmten Zeitpunkt auf eine Organisation gepasst hat, bedeutet nicht einmal, dass es heute noch passt. Agile Frameworks entwickeln sich mit der Strategie und Kultur ihrer Anwendern laufend weiter.

Emergenz – die Crux der Digitalisierung

Und genau an dieser Stelle kommen wir zur Crux der Digitalisierung: Die hohe Emergenz unseres Umfeldes. Ein dynamisches Umfeld erschwert es, allgemeingültige Lösungen zu beschreiben. Selbst Lösungsmuster unterliegen einer laufenden Veränderung. Das Ziel einer Organisation liegt daher nicht darin, eine neue Plan-Struktur anzunehmen, sondern vielmehr darin, den Prozess der Veränderung zu verbessern und eine Kultur der Wandlungsfähigkeit zu etablieren.

Die Emerganz der Digitalisierung trifft uns aber auch auf strategischer Ebene: Digitalisierung bedeutet nämlich nicht nur, dass wir bestehende Wertströme digitalisieren müssen. IT ist nicht mehr nur Service, sie wird maßgeblicher Teil des Produktes. Digitalisierung verändert also die Art der Wertschöpfung. Das führt dazu, dass bestehende, analoge Produkte vom Markt gedrängt werden können. Für die Strategie bedeutet das, dass wir unser Produktportfolio (mitunter disruptiv) neu denken müssen.

Digitalisierung führt zu Veränderung in der Strategie, in der Organisation und in der Kultur. Veränderung in einem emergenten Umfeld darf dabei nicht als Operation oder Projekt, sondern als kontinuierlicher Prozess verstanden werden. Laufende Veränderungen in einem solchen, schnellen Umfeld führen dazu, dass wir Fehler machen werden, oder Sachen die gestern richtig erschienen, morgen nicht mehr passen werden. Die Kunst dabei ist es, aus Fehlern zu lernen und sie als Ausgangsbasis in einem laufenden Veränderungsprozesses zu verstehen. Entwicklung beginnt nämlich immer beim aktuellen Stand des Irrtums.