Wir arbeiten jetzt alle nach SAFe. Mit unserem Spotify-Modell sind wir bereit für die Zukunft. Mit den Scrum of Scrums werden wir alle Teams zusammen führen. Wichtige Entscheidungen können wir bis zum Chief Product Owner eskalieren. Dank agilem Portfoliomanagement haben wir alle Abhängigkeiten im Griff.
So oder so ähnlich schon mal erlebt? Ups. Da hat vielleicht jemand die wichtigste Regel der agilen Skalierung übersprungen.
Was ist überhaupt agile Skalierung?
Aber der Reihe nach. Bevor wir zur wichtigsten Regel kommen, sollten wir uns einig werden, was agile Skalierung überhaupt bedeutet. Kurzer Sprung ans Ende dieser Erklärung: Es gibt keine festgeschriebene Definition.
Schon beim zweiten Blick offenbart sich: Agilität selbst ist total erklärungsbedürftig! Die einen verstehen darunter eine Ausrichtung auf Geschwindigkeit, andere auf Adaptationsfähigkeit, wieder andere auf Flexibilität, manche gar auf Kundenwert. Was ist Agilität? Zu welchem Zweck dient sie? Diese Frage sollte ganz am Anfang stehen. Gleich hinter der Überlegung “warum gibt es eigentlich dieses Unternehmen”?
Legen wir also fest, zumindest für diesen Artikel: Agilität bedeutet die Anpassungsfähigkeit der gesamten Organisation an die Bedürfnisse des Kunden. Obacht, da steht
- Fähigkeit zur Anpassung; nicht, es “muss sich alles ständig ändern”.
- gesamte Organisation; nicht “ganz viele Einheiten, die agil arbeiten”.
- Bedürfnisse des Kunden; nicht “einfach das machen, was der Kunde sagt”.
Gut. Geschafft. Weiter. Skalierung. Was bedeutet das? Frage ich mich auch. Also versuchen wir es mit einer freundlichen Annäherung. Die unter Agilität gemeinhin gefassten Arbeitsweisen gehen von einer dezentralen, lokalen Gestaltung aus. Fast immer gibt es dabei das Team als Einheit. Das ist gewissermassen das Atom der Organisation. Genauso, wie das Atom die kleinste (menschgedachte) Einheit eines chemischen Elementes ist. Ja klar, es gibt noch kleinere Teile aber für die Betrachtung in der Chemie sind das Atom und in der Agilität das Team die jeweils kleinste Einheit.
Wenn mehr als ein Team benötigt wird, um eine Lösung zu liefern, dann ist es eine skalierte Agilität. Da alle beteiligten Teams an einer Lösung arbeiten, gemeinsam am Strom der Wertschöpfung beteiligt sind, müssen sie sich abstimmen. Dazu gehört, dass sie gemeinsam planen und Rückmeldungen gemeinsam verarbeiten. Das ist in einem synchronisierten Takt deutlich leichter.
Gibt es mehrere Wertschöpfungsströme (Produkte/Lösungen), die voneinander weitgehend unabhängig sind, müssen sie nicht in einem Takt arbeiten, der Planung, Umsetzung, Inspektion und Adaptation (PDCA-Zyklus) synchronisiert. Es spricht aber auch wenig dagegen ausser Bandbreite und Räumlichkeiten für die Events bereit zu stellen zu müssen.
Wofür wird ein agiles Rahmenwerk gebraucht?
SAFe, LeSS, DaD, SaS, Enterprise Scrum, Nexus…allein bei den Rahmenwerken, die sich selbst so nennen, gibt es gleich eine ganze Palette. Und dann gibt es noch Modelle, die mehr als einmal anzutreffen sind, aber irgendwie nicht so zum Modell einer Organisation tauglich sind. Zum Beispiel Spotify, Agile Portfolio Management, OKR. Was auch immer es bedeutet sich nach diesen zu organisieren. Allerdings will ich an dieser Stelle nicht darüber urteilen, ob und wann welches Sinn ergibt.
Ganz kann ich mir einen Kommentar jedoch nicht verkneifen: Immerhin 19% der Antworten auf die Frage “which framework does your organization follow to help scale Agile?” im 15. State of Agile Report lauten auf “don’t know”. Ich frage mich zwar schon seit ein paar Jahren, wer da so antwortet und welche Repräsentativität dieser Bericht hat, aber für ein Schmunzeln reicht es allemal, wenn skaliert wird und die Befragten nicht wissen, nach was für einer Idee. Nicht-Wissen kann nicht der Grund sein, das gibt es als eigene Antwortoption.
Was ist also der allgemeine Vorteil die Organisation nach einem dieser Rahmenwerke auszurichten?
Aus nicht repräsentativen Begleitungen von Entscheidern in Unternehmen kann ich folgendes berichten. Ein Rahmenwerk gibt eine Orientierung für Abläufe, Verantwortungen und Artefakte. Rahmenwerke bieten Muster, um komplexe Zusammenhänge zu strukturieren. Sie nutzen erfolgreiche Praktiken, Methoden, Techniken. Rahmenwerke schaffen Vergleichbarkeit zu anderen Unternehmen, die sich ebenfalls daran orientieren. Manchmal bieten sie sogar Muster zur Einführung an.
Es spricht also einiges für Rahmenwerke. Spricht auch etwas dagegen?
Ein Argument, das mir in Artikeln, Vorträgen und in Gesprächen begegnet, ist dass Unternehmen ja gar keinen Wettbewerbsvorteil mehr haben können, wenn sie sich nach dem selben Rahmenwerk organisieren.
Dieses Argument, dass mit dem selben Rahmenwerk die Organisation sich gleicht, trifft allerdings auf kein mir bekanntes Rahmenwerk zu.
Hier ist nämlich eine wichtige Unterscheidung notwendig. Es ist ein Rahmenwerk, keine Blaupause und kein Modell. Kein einfach so übertragen. Wer es doch versucht, stellt ziemlich schnell fest, dass es nicht funktioniert. Zu viel muss organisationsspezifisch angepasst werden. Zunächst gilt es zu verstehen, was eigentlich die Produkte der Organisation sind. Hier ein früherer Artikel, der erklärt, wie Produkte definiert werden können.
Und dann zu analysieren, wie Wertschöpfung passiert. Hier ist ein voran gegangener Artikel, der Value Stream Identifikation erklärt.
Im Anschluss zu identifizieren, wo regelmässig Verschwendungen geschehen und wo Engpässe sind.
Leider verführen Rahmenwerke manche Entscheider anscheinend dazu, vorschnell in Lösungen zu denken.
Zu einfache Lösungen sind problematisch
Unternehmen sind komplex. Sie sind komplex, weil zu keinem Zeitpunkt alle Vorgänge so determiniert werden können, dass zukünftige Ereignisse sicher vorhergesagt werden können. Ähnlich wie Wetterprognosen. Mit einer gewissen Wahrscheinlichkeit kann das Wetter von morgen vorhergesagt werden aber je turbulenter es ist, desto schwieriger fällt es. Das Wetter in vier Wochen vorherzusagen, ist hingegen kaum möglich. Vielleicht ändert sich das durch künstliche Intelligenz. Sowohl für das Wetter wie für die Organisation.
Um mit dieser Komplexität umgehen zu können, müssen Organisationen selbst komplex sein. Eine Lösung, die weniger komplex als das Umfeld ist, in dem sie angewendet wird, wird nicht den Herausforderungen gerecht. Meine nicht nur ich. Es gibt eine Regel, genannt Ashby’s Law of Requisite Variety. Diese besagt, dass Organismen auf alle Reize angemessen reagieren können müssen, um als Spezies langfristig zu überleben. Für diese Reize benötigen sie also eine notwendige Vielfalt. W. Ross Ashby hat Wissen aus der Zoologie, Biochemie, Medizin und Mathematik eingebracht – ein ausgesprochener Autodidakt und Universalwissenschaftler. Optimale Voraussetzungen, um in den 1950er Jahren das Wissenschaftsfeld der Kybernetik mitzugestalten.
Warum ist diese Regel der notwendigen Vielfalt wichtig?
Einfach ein agiles Rahmenwerk aufzuspielen, wird nicht der Komplexität gerecht, in der sich Unternehmen bewegen.
Und wird es doch versucht, dann gilt nur vordergründig der Rahmen des Rahmenwerkes. Aber um allen Herausforderungen gerecht zu werden, sind die Menschen darin regelrecht dazu gezwungen sich eigene Wege zu suchen, um schlichtweg “zu liefern”. Ziemlich bald ist das neue agile Rahmenwerk eine Fassade, hinter der sich die Menschen ihre eigenen Arbeitsweisen suchen.
Und dann steht es um die notwendige Komplexität grösser als notwendig. Die Organisation ist komplexer, als sie sein müsste. Warum ist klar: Es gelten die Regeln aus dem Rahmenwerk und es bestehen/entstehen im Hintergrund Praktiken um trotzdem “was fertig zu bekommen”. Menschen sind da überaus selbstorganisiert und finden ihren Weg. Dummerweise hat dann die agile Skalierung genau das Gegenteil des Beabsichtigten erreicht.
Die wichtigste Regel der Skalierung ist…
…nicht zu skalieren.
Die wichtigste und allererste Überlegung sollte sein: Wie kann ich die bestehende Organisation vereinfachen?
Wie kann die Wertschöpfung so organisiert werden, dass möglichst kleine, voneinander möglichst unabhängige Einheiten möglichst selbstständig arbeiten?
Je höher die Freiheit der Organisation jeder Einheit ist, desto höher ist die Fähigkeit zur Anpassung. Die Einheit kann dann intensiver mit den jeweiligen Stakeholders arbeiten. Und dennoch steigt die Agilität der gesamten Organisation, weil die Einheiten sich bestenfalls nicht gegenseitig beeinflussen.
In der Software ist diese Idee seit ein paar Jahren zum Leitbild der Umsetzung neuer Architekturen geworden. Die Softwarelösung mit Bausteinen, die aus ineinander integrierbaren Teilen bestehen, sind schlichtweg anpassungsfähiger an zukünftige Entwicklungen. Klar, dafür benötigt es Nahtstellen, die diese Einheiten verbinden. Dafür wiederum liefern die agilen Rahmenwerke jedoch passende Abläufe.
Bevor die Einführung von skalierter Agilität oder einem agilem Portfolio entschieden wird, sollte die bestehende Organisation vereinfacht werden. Die Organisation muss dazu gewissermassen “deskaliert” werden.
Strategien zum “Deskalieren”
1. Reduzieren
Kann die gleiche Arbeit durch weniger Personen erfolgen?
Bill Gates wird mit den Worten zitiert:
“A great lathe operator commands several times the wages of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.”
Eine kleine Einheit exzellenter Personen kann in Zusammenarbeit mehr schaffen, als wenn diese über eine grössere Organisation verteilt sind und sich dann der durchschnittlichen Leistung anpassen. Reed Hastings und Erin Schmidt beschreiben in ihrem Buch (s.u. bei der Verlosung), wie Netflix sukzessive eine Hochleistungskultur mit wenig Regeln entwickelt hat.
2. Unabhängig gestalten
Kann der Strom der Wertschöpfung so verändert werden, dass unabhängigen Einheiten möglich werden?
Die zweite Strategie baut auf der ersten auf. Wenn eine kleine Einheit exzellente Leistungen schafft, wie viel könnten dann viele kleine Einheiten schaffen? Einheiten, die sich nur wenig abstimmen müssen, weil sie über die Technologie und Organisation verfügen, die sicher stellt, dass Ergebnisse integriert werden können. An dieser Stelle ist eine Unterscheidung wichtig: Die interne Organisation und die von Kunden wahrgenommenen Produkte sind zweierlei. In diesem Artikel gehe ich deutlich tiefer darauf ein. Ja, diese Strategie bedeutet mehr Value Streams zu definieren. Aber wenn diese nach aussen in Summe weniger abzustimmen haben, sinkt die organisationale Komplexität im Vergleich zu einem grossen Value Stream mit mehr Abstimmung nach “innen”.
3. Dezentralisieren
Kann ein Portfolio dezentralisiert werden?
Die dritte Strategie baut auf der zweiten auf. Wenn dezentrale Entscheidungen “besser” als zentrale, dann benötigt es keines Portfoliomanagements. Die Verantwortung für die Verbesserung des Wertstromes obliegt dann jeder Einheit selbst. Richard Hackman bezeichnet diese Einheiten als “self-designing units”. In seinem Meilensteinartikel bezieht er sich zwar auf Teams -ohne diese exakt zu beschreiben- aber die Logik lässt sich übertragen. Das “self-design” kann durchaus mit vorab zentral entschiedenen Regeln erfolgen. Diese Leitplanken definieren, was nicht möglich ist, lassen aber innerhalb einen Raum des Möglichen, ohne mehr vorzugeben. Hier ist ein Beispiel für einen Workshop, bei dem sich bei der Bank of America innert von drei Stunden 100 Personen selbst in Teams organisieren und diese gestalten.
Quelle
Aus der Darstellung lässt sich ein weiteres Element herauslesen. Es kann immer noch notwendig oder zumindest hilfreich sein mache Entscheidungen zu zentralisieren. Die übergreifende Unternehmensstrategie ist DAS Beispiel dafür. Solche und weitere Governance-Entscheidungen werden zentral abgestimmt und die einzelnen Einheiten müssen dann innerhalb der vorgegebenen Leitplanken agieren.
4. Ashby’s Law gilt weiterhin.
Die Anforderung der notwendigen Komplexität des Systems ist auch in einer Organisation mit einer Vielzahl unabhängiger Einheiten gegeben.
Komplexität wird verteilt, sie liegt bei den Einheiten, statt in einem Zentrum der Koordination. Die Chance besteht darin, dass die Reaktion auf einen Reiz dann dort erfolgt, wo das lokale Wissen eine bessere Antwort ermöglicht. Daraus erwächst aber auch eine Herausforderung. Diese besteht darin manche Informationen angemessenen schnell mit allen zu teilen zu können. Das kann durch eine zentrale Koordination erfolgen oder durch einen Ablauf, der dies sicher stellt.
Frage an Dich
Wurde in der Organisation “deskaliert”?
Falls ja, wie habt Ihr das gemacht?
Falls nein, wäre es besser gewesen?
Unter den Personen, die hier kommentieren, verlosen wir das Buch “No Rules rules” von Reed Hastings und Erin Schmidt. Die beiden beschreiben darin, wie Netflix seine Organisation Schritt für Schritt vereinfacht hat. Es geht nicht um Agilität und auch nicht um Rahmenwerke, vielleicht macht genau dies das Buch umso lesenswerter.
Write a comment