Agile Transformation (dt.) oder Agil Transition (eng.) bezeichnet den Übergang von einer klassischen Organisation, hin zu einer agileren Organisation. Im Rahmen des Führungskreis IT hatte ich die Gelegenheit mich mit diesem Thema zu beschäftigen und beantworte für euch in diesem FRITZ Tipp die zentralen Fragen der Teilnehmer.
Inhalt
Was ist Agile Transformation?
Mit einer agileren Organisation ist eine Organisationsstruktur gemeint, die für ein Umfeld mit hoher Änderungsrate konzipiert ist. Dabei sollten sich min. 30% der definierten Anforderungen pro Monat ändern.
Quelle: FRITZ Führungskreise
Woran würde ich eine agilere Organisation erkennen, wenn ich sie auf der Straße treffe? Für den Organisationssoziologen Kühl ist eine agilere Organisation durch vier Elemente erkennbar:
- Abbau von Hierarchien – bis hin zu deren Abschaffung.
- Auflösung von Abteilungen – die Zerstörung der Silos.
- Zurücknahme von Formalisierung – Reduzierung der Regeln.
- Arbeit in Inkrementen (Timeboxing).
Die Punkte 1-3 sieht Kühl sehr kritisch, alle Organisationsformen schaffen durch Arbeitsteilung ihre eigenen Silos, egal wie wir sie nennen. Nach Parsons stellt das sogar die Leistungsfähigkeit der Organisationen sicher. Punkt 4 findet er als Wiederentdeckung jedoch spannend. Hier zum Nachhören:
Warum Agile Transformation?
Ein typisches Problem im IT-Umfeld sind Change Requests oder Änderungsanträge. Das heißt der Fachbereich ist mit einer ausgelieferten Funktionalität noch nicht zufrieden und wünscht Änderung. Häufig gibt es von diesem Change Request viel zu viele, alle scheinen gleich wichtig zu sein und sollten sofort umgesetzt werden. Natürlich bei konstanten IT-Ressourcen.
In diesem Kontext kommt gerne der Ruf nach agilen Methoden. Schließlich verspricht Jeff Sutherland mit seinem genialen Buchtitel: Scrum: The Art of Doing Twice the Work in Half the Time. Die doppelte Arbeit in der halben Zeit ist absoluter Bullshit. Dennoch lohnt sich ein vertiefter Blick auf SCRUM & Co, da diese Methoden für ein Umfeld mit hoher Änderungsrate konzipiert wurden.
„Die Workshops im Führungskreis IT sind in einem überraschend pragmatischen und wirksamen Format, sowie die Themen meist direkt wichtig und brennend für jeden IT-Manager, der in der Brandung steht… Sehr empfehlenswert.“
Wie gelingt Agile Transformation?
OK, wir haben Bereiche bei uns identifiziert die mit einer hohen Änderungsrate kämpfen. Häufig sehr wissensintensive Bereiche. Jetzt wollen wir agil werden! Wie gehen wir es an? Wie sieht die Roadmap für eine agile Transformation aus? Leider gibt es hier kein Patentrezept.
Stattdessen hat sich in der Szene der Grundsatz durchgesetzt, die agile Transformation als ein agiles Projekt durchzuführen. Learning SCRUM by doing SCRUM. Dazu wird zunächst ein Transition-Team gegründet, das die Rolle des SCRUM Master oder Agile Coach der agilen Organisation übernimmt. Zur Erinnerung, der SCRUM Master bzw. Agile Coach kümmert sich u.a. darum das SCRUM-Teams produktiv arbeiten können.
Das Transition-Team beauftragt SCRUM-Teams Produkte zu entwickeln. Diese SCRUM-Teams melden an das Transition-Team zurück, welche Probleme bei der agilen Entwicklung auftreten. Dieses Prinzip kennen wir bereits aus der klassischen Organisationsentwicklung. Die Steuerungsgruppe setzt Projekt-Teams auf, um die strategischen Zielsetzungen zur Veränderung hin zu einer agileren Organisation zu erreichen. Mehr zum Transition-Team von Boris Gloger:
Agile Transformation Roadmap
Bei der Veränderung hin zu einer agileren Organisation gibt es im Kern drei Ansatzpunkte oder Handlungsfelder. Man könnte auch von einer Agile Transformation Roadmap sprechen:
Input
Viele IT-Abteilungen kämpfen mit zu vielen Change Requests die alle scheinbar gleich wichtig sind. Egal mit welcher Methode ich arbeite, es lohnt sich den Input ins System zu drosseln. Je länger die Warteschlange, desto träger wird das System. Der Fachbegriff im IT-Umfeld dazu lautet Demand Management. Nachfrage-Management trifft es aus meiner Sicht recht gut. Es geht darum den Input ins System besser zu koordinieren und priorisieren.
SCRUM bringt in diesem Zusammenhang zwei schöne Grundgedanken mit. Zum einen sagt nicht der Umsetzer (=IT-Abteilung) was umgesetzt wird, sondern der Kunde (=Fachabteilung). Das heißt die Fachabteilungen müssen vor dem Hintergrund einer begrenzten Umsetzungskapazität entscheiden, was in den Tunnel gelassen wird und in welcher Reihenfolge. Zum anderen gilt es diese Arbeit mit einem SCRUM-Board zu visualisieren.
Agile Methoden
In den Bereichen wo es Sinn macht, also die Änderungsrate bei min. 30% pro Monat liegt, lohnt es sich auf agilen Methoden wie SCRUM, Kanban oder Design Thinking zu setzen. Ohne auf die einzelnen Methoden im Detail eingehen zu wollen, erscheinen mir folgende Grundsätze wichtig:
- Ask the team: Wir gehen davon aus, dass multidisziplinäre Teams schlauer sind und geben ihnen deshalb die Umsetzungsverantwortung. Ähnlich einer Task Force.
- Deliver: Wir wollen in kürzeren Abständen liefern. Hier bietet es sich an eine einheitliche Timebox über alle Teams zu legen, die nach agilen Methoden arbeiten.
- Review: Im Anschluss an die Timebox muss es ein gemeinsames Review mit dem Auftraggeber geben, damit das Team schnelleres Feedback bekommt. Auch im Sinne eines gemeinsamen lernen.
- Repeat: Wenn sich die agile Arbeitsweise bewährt hat, das muss sie nämlich nicht zwangsläufig, gilt es den Prozess zu wiederholen und dabei besser zu werden.
„Führungskräfte sind ja keine verschlossenen Menschen, aber die unkomplizierte Offenheit im Führungskreis Essentials war doch überraschend und für einen echten Erfahrungsaustausch die perfekte Basis.“
Output
Wie beim Input, gilt es auch beim Output Transparenz durch Visualisierung zu erzeugen. Ein SCRUM-Board bietet sich hierzu bestens an. Wenn es sein muss auch digital. Was man in diesem Zusammenhang von KANBAN lernen kann, ist der Fokus auf Prozessverbesserung durch passende KPIs. WICHTIG! Häufig fühlen sich Mitarbeiter in SCRUM-Teams sehr wohl, weil die Kommunikation besser fliest. Das heißt aber noch lange nicht das der Output höher oder besser ist. 
Beispiele für Agile Transformation
Die Königsbeispiele einer agilen Transformation sind immer wieder Spotify, Netflix und ING. Hier das dazu passende Video der ING. Nach Selbstbekundung, die erste agile Bank:
Im Endausbau gäbe es bei einer vollständigen agilen Transformation der Organisation nur noch interdisziplinäre Teams, die sich im Netzwerk organisieren und Kundennutzen stiften. Als Extrembeispiel sei das chinesisches Unternehmen Haier genannt, welches aus 4000 Microenterprises besteht:
Die Hoffnung dahinter? Firmen mit hoher Marktkomplexität profitieren von kleineren, funktional integrierten, marktfähigen Einheiten mit hoher Autonomie, damit hohe Marktpassung entstehen kann, so Löffler.
Wenn jedes interdisziplinäre Team unabhängig von anderen arbeiten könnte, wäre eine vollständige agile Transformation der Organisation keine große Hexerei. Wenn diese Teams jedoch miteinander arbeiten müssen, wird es kniffelig.
In der Szene werden die entstehenden Koordinationsprobleme unter dem Begriff Scaled Agile (LeSS, SAFe und Nexus) oder DevSecOps diskutiert. Spotify hat sich hier zum Vorbild für die Entwicklung einer agileren Organisation gemausert.
Das Spotify Modell
Das Kernstück des Spotify Modell sind sogenannte Squads mit 8-10 Personen. Damit sind vertikal geschnittenen Teams gemeint. Alle Fachleute, die zur Befriedigung des Kundenbedürfnisses erforderlich sind, werden in ein Team entsendet. Spotify möchte, dass ein Squad den Charakter eines Startups hat.
Wie bei SCRUM gibt der Product Owner das WAS vor. Das Squad kümmert sich um das WIE. Und der Agile Coach, besser bekannt als SCRUM Master, hilft dabei Hindernisse zu erkennen und zu beseitigen.
Bei einem Tribe mit bis zu 150 Mitarbeitern handelt es sich um eine Gruppe von Squads, die am gleichen Produkt arbeiten. Jeder Tribe hat einen Leiter. Der Tribe-Leiter hat die Aufgabe, eine optimale Arbeitsumgebung für die Squads zu schaffen und den Austausch der Squads untereinander sicherzustellen.
Der systemimmanente Nachteil von vertikal geschnittenen Teams ist der fehlende Austausch von Menschen mit demselben Fachwissen. Deshalb gibt es die sogenannten Chapter und Guilds. In ihnen kommen diese Menschen mit den gleichen Kompetenzen und Fähigkeiten zusammen.
Ein Chapter (fachliches Netzwerk) besteht aus Mitgliedern eines Tribes, die über dieselbe Expertise verfügen. Guilds (übergreifende Communities) beschränken sich nicht auf einen Tribe, sondern beziehen die gesamte Organisation mit ein. Hier kommt es zum regelmäßigen Austausch zwischen den Mitgliedern. Die Chapter-Leitung, früher Abteilungs- oder Bereichsleiter genannt, ist dafür zuständig, Mitarbeiter in ihrer Entwicklung zu begleiteten.
Das klassische Projektmanagement würde beim Spotify Modell von einer reinen Projektorganisation sprechen, mit speziellen Rollenbezeichnungen. Projekte werden von der sekundären zur primären Organisationsform des Unternehmens. Dabei ist Scrum keine Vorgabe für die Squads. Deshalb nennt Spotify den SCRUM Master agile Coach.
Die Vorteile des Spotify Modells sind klar: Schnelle Kommunikation, kurze Entscheidungswege und Fokus auf Kundenbedürfnisse. Die Nachteile dürfen nicht verschwiegen werden: Standards, und damit effiziente Prozesse, sind in vertikalen Teams schwer aufrecht zu erhalten. Die grundsätzliche Spannung zwischen interner Logik und extern Anforderungen bleibt bestehen, sie wird nur ins Team verlagert.
Fazit – Agile Transformation einer Organisation
Bei aller Begeisterung, die ich für das Thema habe, möchte ich mit einer Warnung schließen. Agilität macht nur Sinn, wenn sich min. 30% der definierten Anforderungen pro Monat ändern. Man könnte auch von komplexen Problemen sprechen. Wenn dem nicht so ist, bitte sein lassen. Warum sollte ich im IT-Helpdesk SCRUM einführen? Blödsinn!
Wer das trotzdem machen möchte, erliegt einem alten Traum, der eigentlich ein Alptraum ist. Abbau von Hierarchien, Auflösung von Abteilungen und Zurücknahme von Formalisierung. Was wir aktuell unter Management-Moden wie Holacracy und New Work erleben, erzeugt Schatten-Hierarchie und Zentralisierung von Entscheidungen. Deshalb muss zumindest die Durchlaufzeit vorher und nachher miteinander verglichen werden!
Dr. Patrick Fritz
Kommentar verfassen