Vertical Fluency oder: Wie die Versprechen der Vertikalisierung wahr werden
Einige der letzten Artikel dieses Blogs behandelten kundenorientierte Vertikalisierung. E-Commerce-Systeme, die über die Jahre zu groß geworden sind, werden mit diesem Ansatz in eine Handvoll Systeme zerlegt. Die Zerlegung erfolgt aus der Kundenperspektive. An die Stelle eines komplexen Systems treten mehrere kleine. Die Abhängigkeit der Teams, die jeweils ein System betreuen, ist minimal, so dass eine hohe Prozessgeschwindigkeit erreicht werden kann: das gewünschte Ziel der Vertikalisierung.
In der Formulierung "eine hohe Prozessgeschwindigkeit erreicht werden kann" verbergen sich Probleme dieses Ansatzes. Mit "hohe Prozessgeschwindigkeit" ist die Zeit gemeint, die es dauert, von der Idee eines Features zu seiner Realisierung am Markt zu gelangen. Je höher die Geschwindigkeit, desto schneller wird eine Idee im Markt verprobt. Je schneller eine Idee am Markt ist, desto schneller bekommt man das Feedback der Kunden und kann diese in weitere Iterationen einfließen lassen. Und das ist der kritische Erfolgsfaktor im E-Commerce. Aber "erreicht werden kann" heißt eben nicht, dass man wirklich schnell ist, sondern nur, dass man schnell sein könnte. Im Folgenden werde ich versuchen, die Faktoren zu benennen, die den Konjunktiv in einen Indikativ verwandeln, oder - weniger grammatikalisch - die die Idee der Geschwindigkeit Wirklichkeit werden lassen.
Die Zonen des Erfolges
Die zentrale Anleihe dieses Artikels ist der Begriff Agile Fluency. Er macht seit einigen Jahren in der agilen Szene die Runde, wenn es gilt, den Effekt einer agilen Adaption zu bezeichnen (Agile Fluency). Man muss, um weiterlesen zu können, den Begriff der Agile Fluency nicht kennen, ich werde ihn analog und eigenständig für ein Verständnis der Tiefe der Vertikalisierung entwickeln. (Fluency lässt sich mit Gewandtheit übersetzen und meint Praktiken, die uns in Fleisch und Blut übergegangen sind. Agile Fluency fragt danach, welche agilen Praktiken wir aus dem Effeff beherrschen.)
1. Focusing - nur die Organisation
Die erste Zone der agilen Gewandtheit heißt: Focusing. Sie meint, dass ich Scrum als Prozess für meine Software-Entwicklung einführe, die Struktur meiner technischen Systeme aber nicht verändere. Wo vorher ein Monolith entwickelt wurde, wird jetzt ein Monolith mit Scrum weiterentwickelt. Übertragen auf die Vertikalisierung heißt Focusing: Ich habe ein großes monolithisches E-Commerce-System. Ich arbeite mit vielen Teams an diesem System und diese Teams bekommen ihren Zuschnitt anhand der Customer Journey. Ich restrukturiere die Teamgrenzen und führe in meinen Teams einen agilen Prozess, oft Scrum, ein. Ich dehne die Vertikalisierung nicht auf die Software aus. Die Teams haben kein eigenes Stück Software, das sie autonom entwickeln und deployen können. Auf der technischen Seite bleiben die bestehenden Abhängigkeiten erhalten.
Dieses Modell treffen wir in der Welt der E-Commerce-Systeme vor allem dann an, wenn die Probleme mit dem bestehenden System nicht die Größe erreicht haben, die eine Investition in den Neuaufbau einer Plattform sinnvoll erscheinen lassen, oder wenn der Wille nicht da ist, das bestehende System zu ersetzen. Oftmals treten Probleme mit Systemen in verschiedenen Bereichen der Organisation zeitverzögert und mit unterschiedlicher Dringlichkeit auf. Während das Business über extrem lange Entwicklungszeiten klagt, ist die Technikabteilung ob der Stabilität ihres Systems noch ganz zufrieden.
Was gewinnt man mit dieser 'flachen', organisatorischen Vertikalisierung? Man erreicht keine wesentlich höhere Prozessgeschwindigkeit, aber man gewinnt Transparenz. Die Teams sind aufgrund der organisatorischen Schnitte in der Lage, User Stories autonom zu verwalten. Sie sehen, wie bei der Realisierung die Verantwortung schwimmt und spätestens im Kontext eines Deployments Wartezeiten zu kalkulieren sind, die sich eher am Wochen- als am Marktrhythmus orientieren. Kurz und gut, der Schmerz, den man erleidet, wird in dieser Form sichtbarer und eine Frustration entsteht, weil man gehofft hatte, dass die Entwicklungsgeschwindigkeit einen Boost erlebt.
2. Delivery - die technisch intensivste Zone
Der Name der nächsten Zone der vertikalen Transformation lautet 'Delivery'. Gemeint ist damit die Transformation, die auch das technische System umgestaltet. Waren in der ersten Zone die Team- und Organisationsstrukturen betroffen, so werden in der zweiten Zone auch die technischen Systeme an der Customer Journey ausgerichtet. Im Ergebnis hat jedes Team ein eigenes System, das von ihm entwickelt und betrieben wird. Zur Laufzeit ist es von keinem anderen System abhängig. Damit sind alle technischen Barrieren, die verhindern, dass schnell entwickelt und deployed wird, aus dem Wege geräumt. Diese zweite Zone ist die technisch intensivste. Entgegen der ersten ist der Aufwand für diese zweite Zone hoch. Egal, ob auf der grünen Wiese oder via schrittweiser Migration (über den Unterschied, der erheblich ist, wird an anderer Stelle zu schreiben sein) wird an der Stelle des alten monolithischen Systems ein neues System von Systemen errichtet. Es tritt der Effekt der unabhängigen Entwicklung der Teams und ihrer Vertikalen ein.
Ist damit das Versprechen der hohen Geschwindigkeit eingelöst? Ja und nein. Ja, denn die Kommunikation mit anderen Teams geht gegen Null und die Möglichkeit via Continuous Delivery Features wie am Fließband live zu stellen gehört zum technischen Zielbild. Nein, denn der Kommunikationsaufwand, die Diskussion mit den Stakeholdern, das Einbeziehen der nicht-vertikalisierten Restorganisation (der größte Teil der Organisation) ist von den Änderungen nicht tangiert. Je nach Organisation kann dieser Teil der Realisierung eines Features - im agilen Sprech ist es all das, was getan werden muss, damit eine Story als Ready ins Backlog wandern kann - wesentlich länger dauern als ihre Realisierung im Team. Kurz gesagt: die eine Hälfte der Strecke Idee-Produkt läuft auf Hochtouren, nämlich die Strecke von der Story des Sprints zum Produkt, die andere Strecke, von der Idee in eine Story des Backlogs, hat sich nicht verkürzt. Je nach Organisation kann damit ein wesentlicher Prozess maßgeblich verkürzt sein. Es besteht aber auch die Möglichkeit, dass das Ergebnis dieser Zone frustrierend ist. Man hat die Hälfte des Prozesses enorm beschleunigt, die andere Hälfte dauert nach wie vor sehr lange.
3. Optimizing - Fachpersonal ins Team
Erst mit der dritten Zone der Vertikalisierung werden ihre Versprechen im kompletten Umfang eingelöst, oder, um in der Diktion der Einleitung zu bleiben, wird aus dem Konjunktiv ein Indikativ. Die dritte Zone heißt in strikter Analogie zur Agile Fluency Optimizing. Sie meint die Reorganisation einer Struktur, bei der das Fachpersonal für die Entwicklung einer Vertikale in das Vertikalenteam wandert. Die Stakeholder werden Teil des Teams. Entscheidungen müssen nicht mehr mit Stakeholdern außerhalb des Teams abgestimmt werden, sie werden direkt im Team getroffen. Der Kern der Transformation dieser Zone ist die Reorganisation der fachlichen Verantwortlichkeit. Die Vertikalenteams werden zu wirklich cross-funktionalen Teams, die fachliche, technische und organisatorische Kompetenz vereinen. Erst wenn diese Transformation abgeschlossen ist, kann die Entwicklung Fahrt in allen Dimensionen aufnehmen. Wenn ein Team Features entwickelt, die komplett in seiner Entscheidungshoheit liegen, und wenn es über die technische und organisatorische Autonomie verfügt (Zone 1 und 2), gibt es kein Hindernis mehr, im Stundenrhythmus neue Versionen zu deployen. Ein Team, das so arbeitet, funktioniert wie ein kleines Start-Up im Unternehmen.
Was hindert ein Unternehmen daran, zielstrebig diese Zone der Vertikalisierung anzustreben? Zone eins bedeutet eine Reorganisation der vom Shop betroffenen Organsiationseinheiten. In der Regel sind das Produktmanagement und Entwicklungsteams. Die Betroffenheit dieser Einheiten ist selbsterklärend, weil sie es sind, deren System beschleunigt werden soll. Zone zwei erfordert die Investition in Zeit und Budget für ein neues technisches System. Das kann immens sein, liegt aber nach wie vor in der Logik des angestrebten Ziels. Zone drei dagegen ist übergriffig. Zone drei funktioniert nur, wenn die gewachsenen Strukturen einer Organisation in Frage gestellt werden. Den Einheiten, die die Transformation angestoßen haben, weil sie ihr technisch-organisatorisches System beschleunigen möchten, stehen die Organisationseinheiten gegenüber, die den E-Commerce bisher als Dienstleister benutzt haben. Warum sollen sie ihre Strukturen und Prozesse ändern? Die Beharrungskräfte, die die Veränderungen der dritten Zone auf den Plan rufen, sind enorm. Aber ohne eine Reorganisation, die Fachlichkeit und Entscheidungskompetenz in die Vertikalenteams verlagert, bleibt das Königsziel der Vertikalisierung ein nicht eingelöstes Versprechen.
4. Strenghtening - Die Organisation wird agil
Die vierte Zone der Vertikalisierung - Strengthening analog der Agile Fluency - betrifft die gesamte Organisation. Der Gedanke ist einfach. Während die dritte Zone ein Team in ein kleines Unternehmen verwandelt, wird auf der vierten Zone das Gesamtunternehmen als Struktur gestärkt. Teams wären nicht mehr nur auf ihre Ziele, ihre Vertikale fokussiert, sondern das Ganze des Unternehmens fließt in ihre Entscheidungen mit ein. Wenn ein anderes Team Engpässe hat und die Wichtigkeit übergeordneter Ziele transparent ist, kann es passieren, dass ein Team seine Ziele hintenan stellt und hilft. Da es wenig Erfahrung mit dieser Zone gibt und sie auch im Kontext Agile Fluency eher spekulativ verhandelt wird, sparen wir uns ihre Betrachtung.
Schlussfolgerung - Sei klar über dein Ziel und den Preis, den du dafür zahlst
Was bringt es, über Vertical Fluency nachzudenken? Was nützt es, die Brücke zur Agile Fluency zu schlagen und ihre Konzepte zu beleihen? Es bringt Klarheit. Aus einem diffusen 'schneller werden' und einer damit verbundenen Frustration am Ergebnis wird eine verhandelbare Planung. Wenn ich ein Vertikalisierungsprojekt auf den Weg bringe, muss ich mir klar werden, welches Ziel ich verfolge. Will ich nur die Transparenz erhöhen, reicht die Zone eins und ich kann mir die Investition der Zone zwei sparen. Will ich schnelle und skalierbare technische Systeme, bin ich gezwungen, die Ressourcen für die Zone zwei zur Verfügung zu stellen. Will ich wirklich schnell werden, will ich mit Start-Ups und potentiellen Disruptoren konkurrieren, dann muss ich den Schritt gehen und meine Organisation in cross-funktionale, fachlich, technisch entscheidungsfähige Einheiten zerlegen, die eigenständig agieren können. Für den Preis der Zone zwei bekomme ich keine Rennboote und Ferraris. Ohne die Reorganisation der Zone drei wird ihre Reichweite beschränkt sein.
So einfach ist das.
