Die agile Keimzelle: Agilität anordnen oder einschleichen lassen?
Ein großes Unternehmen soll agil werden. Reicht es, die Arbeitsweise und das agile Mindset im Kleinen vorzuleben und sich ausbreiten zu lassen? Oder muss von ganz oben bestimmt werden, dass jetzt alle bitte mal agil werden? Und was bedeutet das überhaupt?
Ich bin Teil einer sogenannten agilen Keimzelle. Selbstorganisiert und ohne formale Hierarchien betreiben wir agile Softwareentwicklung als Tochterfirma eines klassischen Konzerns. Anhand der Projekte, die gemeinsam mit uns im Mutterkonzern in den letzten Jahren durchgeführt wurden, möchte ich zeigen, wie Agilität immer weiter Einzug hielt, welchen Einfluss die jeweilige Projektstruktur auf die IT-Systeme hatte und wie diese dort den Ausschlag über Erfolg und Misserfolg gaben.
Die Ausgangssituation – ein hocheffizientes Mainframe-System
Wenn man sich im Mutter-Konzern mit der agilen Transformation beschäftigt, wird man unweigerlich auf "den Host" stoßen. Das ist ein Mainframe- oder Großrechner-System, das über Jahre hinweg das führende IT-System des Unternehmens war und teilweise noch ist.
Mainframe-Systeme sind auch heutzutage noch häufiger in Betrieb, als man vielleicht denken mag. Denn sie können sehr effizient sein und beherbergen nicht selten riesige Teile der Businesslogik großer Unternehmen. Dort einzugreifen und Änderungen vorzunehmen ist allerdings oft mit großem Aufwand verbunden. Auch der Versuch, einzelne Teile herauszulösen und zu ersetzen, stellt die Beteiligten nicht selten vor eine große Herausforderung, da Prozesse oft stark ineinandergreifen.
Damit sind wir beim Kernproblem angelangt. Der Host ist Sinnbild für die Gesamtproblematik. Die bestehenden Prozesse sind zwar effizient, aber die Änderungsfähigkeit zu gering, um auf die stark gestiegene Marktdynamik der letzten Jahre schnell reagieren zu können. Es muss sich also etwas ändern. Auf welche Weise, ist dabei noch unbekannt. Je eingespielter und damit auch festgelegter die Strukturen um die bisherigen Prozesse sind, desto größer ist auch der Aufwand, der zur Änderung nötig ist. Wenn die Ungewissheit groß ist, ob eine Maßnahme den gewünschten Erfolg bringt, ist also auch verständlich, dass diese nicht sofort in aller Breite ausgerollt wird, sondern zuerst ausgiebig getestet werden will.
In unserem Fall war diese Entwicklung gut zu beobachten. Es wurden im Laufe der Zeit verschiedene Projekte gestartet und durchgeführt, Beobachtungen gemacht und daraus Erkenntnisse generiert. Oder kurz gesagt: es wurde gelernt. Die Erkenntnisse wurden dann nach und nach in die nächsten Projekte übernommen und dort in einem meist größeren Rahmen erprobt. Um diesen Lerncharakter hervorzuheben, bezeichne ich diese Projekte im Folgenden Experimente. Anhand von vier ausgewählten Experimenten möchte ich die Entwicklung im zeitlichen Verlauf darstellen.
Klassischer Konzern trifft auf agile Softwareentwicklung
Das erste größere Produkt, das mit agiler Softwareentwicklung entstehen sollte, war eine bedienungsfreundliche und leicht zu erlernende Anwendung für die telefonische Bestellerfassung. Bisher mussten alle Agents in den Call-Centern eine langwierige Schulung durchmachen, um die Hostmasken bedienen zu können. Es mussten Befehlskürzel gelernt werden und welche Hostmasken man für welche Änderung braucht und wie man in dieser Umgebung navigiert. Und das immerhin so gekonnt, dass währenddessen ein Telefongespräch mit einer Kundin möglich ist.
Das war bei mehreren hundert Call-Center-Agents und einer gewissen ständigen Fluktuation auf Dauer nicht mehr vertretbar und auch nicht mehr zeitgemäß. Die Lernkurve war zu flach. Daher sollte eine Anwendung gebaut werden, die im Hintergrund den Host bedient, Daten von ihm entgegennimmt, sie verarbeitet, ändert und zurück überträgt und dabei eine moderne und intuitive UI zur Verfügung stellt.
Die agile Arbeitsweise wurde geduldet, teilweise auch kritisch beäugt.
Vorherige Versuche, die Anwendung mit einer klassischen Projektsteuerung nach dem Wasserfallmodell mit einem externen Dienstleister zu entwickeln, waren gescheitert. Der Mutter-Konzern übernahm zu dieser Zeit im Jahr 2014 die agile Entwicklungsabteilung eines anderen Unternehmens und gründete uns als Tochterfirma. Die Hoffnung war, dass das Projekt mit den Methoden der agilen Softwareentwicklung zum Erfolg geführt werden konnte. Doch die grundverschiedenen Herangehensweisen und Kulturen führten zu großen Reibungen. Auf Business-Seite war beispielsweise der Wunsch nach festen Zielterminen für die Auslieferung sehr groß. Das Entwicklungsteam hingegen wollte keine Versprechen zu Zeitpunkt und Funktionsumfang machen, von denen es nicht einschätzen konnten, ob sie halbwegs realistisch waren. Nach einer Weile pendelte sich eine produktive Zusammenarbeit zwischen Umsetzungsteam und Fachbereich ein. Die agile Arbeitsweise wurde insgesamt geduldet, teilweise auch kritisch beäugt. Es war allerdings auch zu sehen, dass sie auf das direkte Umfeld doch stärker abstrahlte. So identifizierten sich die Product Owner, die aus dem Fachbereich im Konzernumfeld gestellt wurden, teilweise sehr mit der Herangehensweise, den Prinzipien und dem darunterliegenden Mindset. Ein erster Erfolg dabei, diese zu etablieren.
Prozessablösung nach agilen Methoden
Um bei der Ablösung von Hostprozessen voranzuschreiten, wurden im nächsten Projekt mehrere agile Teams gebildet, die parallel an verschiedenen Prozessen innerhalb des Kundenservice arbeiteten. Diese Teams erhielten nun auch eine größere Mitsprache bei den Schnittstellen zum Host. Die Idee war, an verschiedenen Stellen Datenhoheit zu erreichen, Businesslogik zu übernehmen und die Prozesse einfacher und anpassungsfähiger zu gestalten.
Dieses Vorhaben gelang nur in Teilen. Gerade die Datenhoheit vom Host zu übernehmen, stellte sich als Mammutaufgabe heraus. An einigen Stellen bissen sich die Entwicklungsteams die Zähne aus und nach Monaten der Arbeit, der aufreibenden Diskussionen, Konflikte und Anstrengungen blieb der gewünschte relevante Fortschritt aus. Der Handlungsdruck des Konzerns wurde gleichzeitig jedoch immer größer. Es war klar, dass sich etwas ändern musste und die Zeit verstrich.
In der Zwischenzeit ergab sich noch ein anderes Ereignis, das im weiteren Verlauf große Relevanz besaß: Die formale Macht, die für das Gestalten agiler Strukturen nötig war, vergrößerte sich, denn der Geschäftsführer der agilen Tochterfirma stieg zum CDO des Mutterkonzerns auf. Aus dieser Position heraus startete er auch das nächste Projekt, das auf agile Entwicklung setzte. Es wurden gezielt weitere agil arbeitende Softwaredienstleister gesucht, die für diese Aufgabe gemeinsam mit unseren Entwickler:innen neue Teams bildeten.
Die Bedeutung agiler Strukturen für IT-Systeme
Dieses Experiment war nicht nur aufgrund seiner Größe richtungsweisend. Im Next Level Commerce (NLC) ging es nun darum, die 55 Onlineshops, die für die 15 verschiedenen Marken in neun europäischen Ländern existierten, neu zu bauen und eine Shop-Plattform in Eigenentwicklung umzusetzen. Die steigenden Ansprüche der Kund:innen am Markt sollten auch langfristig befriedigt, die Shops konkurrenzfähiger und qualitativ hochwertiger umgesetzt werden. Dieses Unterfangen war äußerst erfolgreich, daher lohnt es sich, die Strukturen und Architekturen genauer zu betrachten.
Wenn eine Kundin sich im Shop bewegt, hat sie an jeder Stelle ihrer Customer Journey andere Bedürfnisse. Wenn sie etwas in die Suche eingibt, möchte sie möglichst relevante Ergebnisse erhalten. Kommt sie über eine externe Suche direkt zum Produkt, für das sie sich schon entschieden hat, ist ihr vor allem ein unkomplizierter Kaufprozess wichtig. Kehrt sie am nächsten Tag in den Mein-Konto-Bereich zurück, will sie genau über den Status ihrer Bestellung informiert werden.
Diese unterschiedlichen Kundenprobleme bedeuten auch unterschiedliche Anforderungen an jeder Stelle. Sie können eigenständig betrachtet und gelöst werden. Die Organisationsstruktur des Projekts sollte dieser Sichtweise entsprechen. So wurden Entwicklungsteams entlang der verschiedenen Bereiche der Customer Journey ausgerichtet. Sie können unabhängige Lösungen entwickeln und dann ihre jeweilige Expertise nutzen, um schnell auf die Marktdynamik in ihrem Bereich zu reagieren. In unserem Fall wurde die Customer Journey in die folgenden Bereiche aufgeteilt: "Suchen", "Entdecken", "Auswählen", "Kaufen" und "Begleiten".
So eine Art der Aufteilung wird auch mit dem Begriff Vertikalisierung bezeichnet. Jedes Team ist für alle Bestandteile seiner Anwendung verantwortlich, die Abgrenzung verläuft nicht horizontal entlang der Schichten eines IT-Systems, sondern vertikal anhand der Fachlichkeit. Die so entstehenden, in sich geschlossenen Vertikalen verantworten ihr Subsystem, ihre Anwendungen eigenständig. Unter dem Begriff der Self Contained Systems (SCS) werden diese Subsysteme und ihre Eigenschaften und Prinzipien beschrieben. Sie werden in der gemeinsamen Makroarchitektur verortet. Die Abgrenzung zu den anliegenden Vertikalen hat einen sehr praktischen Nutzen: Je weniger Abhängigkeiten zwischen den Vertikalenteams bestehen, desto autonomer und dadurch schneller können Anpassungen vorgenommen werden.
Freie Wahl der Technologie – was steckt dahinter?
Die Anforderungen an die Systeme der Vertikalen unterscheiden sich teilweise sehr stark: Während für die Vertikale im Bereich "Suchen" Schnelligkeit und die Relevanz der Ergebnisse ausschlaggebend ist, befasst sich "Auswählen" mit der Qualität und Übersichtlichkeit der relevanten Produkt-Informationen und "Begleiten" legt großen Wert auf Datensicherheit und Konsistenz, da sie beispielsweise beim Anzeigen offener Beträge kein Fehler machen darf. Diese haben dafür eine höhere Priorität als die Optimierung auf jede Millisekunde Ladezeit.
Dementsprechend unterscheidet sich auch die Architektur der Vertikalen grundlegend. Eine große, einheitliche Gesamtlösung oder beispielsweise eine festgelegte Entscheidung über die Datenbank-Technologie wäre hier kontraproduktiv. Jedes Team kann selbst am besten einschätzen, welche Technologie ihr Ziel am besten unterstützt. Stellt sich heraus, dass die aktuelle Lösung nicht den Anforderungen entspricht oder ändern sich die Anforderungen des Marktes, also der Kund:innen, muss das Team die Freiheit haben, die eigenen Systeme zu ändern und neue Entscheidungen zu treffen – und das möglichst schnell.
Solche Team-Entscheidungen können sämtliche Ebenen des jeweiligen Softwaresystems betreffen. Von der Wahl der genutzten Programmiersprachen und Entwurfsmuster in jedem verantworteten Service über eine Aufteilung in Microservices oder doch lieber größere Einheiten bis hin zum Frontend-Framework. Ausschlaggebend sind immer die Architekturanforderungen.
Integration verschiedener Technologien
Die große Freiheit bei der Auswahl der Technologien führt zu einer Herausforderung an anderer Stelle: der Integration. Da die Vertikalenteams im Projekt auf Self Contained Systems setzen, die jeweils alle Schichten umfassen, liegt eine große Herausforderung in der Integration des Frontends. Denn hier ist es besonders wichtig, dass die Andersartigkeit sich nicht in einer Ansammlung andersartiger UI-Elemente widerspiegelt, die zusammengewürfelt und unübersichtlich wirkt. Die Übergänge sollen für die Kund:innen nicht sichtbar und spürbar sein, das Design muss einheitlich wirken.
Micro Frontends
Sehr gute Erfahrungen konnten wir hier mit dem Konzept der Micro Frontends machen [1]. Die Vertikalenteams liefern jeweils die Seiten des Webshops aus, die in ihrer Verantwortung liegen. Dabei bringen sie selbst die von ihnen benötigten CSS- und JavaScript-Assets mit. Da eine Seite jedoch fast immer aus einer Zusammensetzung von Elementen verschiedener Vertikalen besteht (die Hauptnavigation liefert "Suchen", das Warenkorb-Icon "Kaufen" usw.), werden Techniken wie Custom Elements, DOM-Events und Server Side Includes verbunden, die es ermöglichen, das DOM ähnlich einer API zu nutzen. Ein gemeinsames, geteiltes Designsystem, die Pattern Library, die Styling und UX-Konzepte in UI-Komponenten kapselt und ausliefert, garantiert dabei die Einheitlichkeit in der User Experience.
Bedenken bezüglich der Performance einer so zusammengesetzten Frontend-Architektur liegen nahe. Jedes Vertikalenteam liefert seine eigenen Assets aus, der Code der verschiedenen Frameworks muss geladen und gerendert werden, die Seiten sind aus vielen Teilen zusammengesetzt. Eine kürzlich durchgeführte Analyse widerlegte dies jedoch. Die neuen Onlineshops gehörten sogar zu den schnellsten im Vergleich [2].
Asynchroner Datenaustausch
Ist zwischen den Vertikalen eine Kommunikation auf Datenebene nötig, drückt sich das Vermeiden von Abhängigkeiten in der Vermeidung synchroner Kommunikation aus. Eine Möglichkeit besteht darin, Feeds und Snapshots zu verwenden. Das produzierende System stellt die Daten bereit, die von den Interessenten nach Belieben konsumiert und weiter verarbeitet werden können. Diese asynchrone Datenübertragung sichert die Entkopplung: es gibt keinen Aufruf einer API, sondern einen asynchronen Konsum eines fortlaufenden Datenstroms.
Bei der Beschreibung der Ansätze, die sich für uns als nützlich erwiesen haben, möchte ich betonen, dass dies keine Blaupause dafür sein soll, wie die Architektur konkret auszusehen hat. Je nach Anwendungsfall kann eine andere Variante besser geeignet sein. Vielmehr geht es darum, genau zu identifizieren, welche Anforderungen an das Gesamtsystem bestehen. Diese ergeben sich nicht nur aus der konkret zu erfüllenden Aufgabe. Dem Einfluss der Marktdynamik und der Organisationsstruktur, die ein Projekt bekommen wird, sollte ebenso große Beachtung geschenkt und damit Conway’s Law berücksichtigt werden. Wo verlaufen die fachlichen Schnitte? Welche übergreifende Kommunikation ist wichtig? Welche Kommunikation sollte durch das Schaffen passender Strukturen gar nicht erst über Schnittstellen hinweg verlaufen? Davon ausgehend können dann Lösungen erarbeitet werden, die sich in der jeweiligen komplexen Konstellation als nützlich erweisen. Und durch neue Erkenntnisse immer wieder angepasst werden.
Auswirkungen auf das Umfeld
Im Projekt arbeiteten mehrere große Teams parallel an unterschiedlichen Kundenproblemen und dadurch mit zahlreichen Bereichen des Business' zusammen. Somit war hier auch ein gewisser Skalierungseffekt bezüglich der Agilität zu betrachten. Die Fachexpert:innen waren an vielen Stellen direkt im Kontakt mit den Umsetzungsteams und wurden in die Abläufe einbezogen. So kam eine Vielzahl an Personen direkt mit der Arbeitsweise in Berührung und konnten dies und die Erfolge, die man damit erzielen kann, beobachten. Diese Erfahrung ist für das Verständnis der Methoden und Prinzipien äußerst wertvoll. Denn anders als in Büchern oder Schulungen war hier ihre konkrete Anwendung in der Praxis direkt erlebbar. Und das an verschiedenen Stellen auf verschiedene Arten.
Umbau des Konzerns
Der große Erfolg des Projektes ebnete den Weg für den nächsten Schritt: Die Neustrukturierung des gesamten Konzerns. Auf oberster Ebene wurde nun die Entscheidung getroffen, tiefgreifende Veränderungen in der Unternehmensstruktur zu machen und Prozesse an allen Stellen zu hinterfragen.
Hier stehen wir noch am Anfang. Die Vision ist kommuniziert, die Umsetzung hat im letzten Jahr begonnen. Es werden tiefgreifend Strukturen verändert, Kompetenzbereiche neu geschnitten und umorganisiert. Ab hier findet jetzt die Transformation erstmals top-down statt. Die Geschäftsleitung hat Leitplanken definiert und eine grobe Konzernstruktur erarbeitet, die nun gemeinsam ausgestaltet wird. Digitale Produkte sollen an vielen Stellen im Unternehmen eingesetzt werden, um die Prozesse beim Erfüllen der Kundenbedürfnisse bestmöglich zu unterstützen. Dies wird voraussichtlich zu einer Vielzahl unterschiedlicher, auf den jeweiligen Anwendungsfall passenden, Produkten führen. Deren Auswahl, die Gestaltung und Änderung von Prozessen sowie das selbständige Lösen neuer Probleme soll zukünftig in die Verantwortung der neu entstehenden Organisationseinheiten wandern. Autonomie und Selbstverantwortung, Lern- und Reaktionsfähigkeit auf die Marktdynamik sollen essentielle Kompetenzen ebendieser werden. Und das zentrale System Host in den wohlverdienten Ruhestand gehen.
Fazit
Hinter dem nicht ganz scharfen und immer wieder leicht anders interpretierten Begriff der "Agilen Transformation" verbirgt sich in diesem Beispiel folgende Bestrebung: Das Unternehmen wird so ausgerichtet, dass seine Struktur die Wertschöpfung maximal darin unterstützt, auf die Dynamik des Marktes zu reagieren. Dieses Ziel steht dem einer rein effizienzgetriebenen Optimierung von Prozessen aus der tayloristisch geprägten Zeit entgegen. Die Strukturen, Befugnisse und die Verortung von Verantwortlichkeiten unterscheiden sich bei beiden Ansätzen grundlegend. Bevor sie in Routineprozesse überführt werden können, muss den komplexen Ereignissen am Markt mit neuen Ideen begegnet und diese durch Experimente überprüft werden.
In klassischen Unternehmen ist nur die Geschäftsleitung in der Lage, solche tiefgreifenden strukturellen Veränderungen zu ermöglichen und zu legitimieren. Den Mut dafür aufzubringen setzt auch auf dieser Ebene einen Lernprozess voraus, der dazu beiträgt, das nötige Vertrauen aufzubauen und die Notwendigkeit der Veränderung wahrzunehmen. In unserem Fall hat die agile Keimzelle maßgeblich dazu beigetragen, dass die Experimente auf dem Weg dahin gewagt und deren Größe und Einflussbereich stetig ausgeweitet wurden. Nur so konnte letztendlich der Glaube an die Neuausrichtung des Unternehmens nach oben wandern. Dort angekommen konnte nun die Führungsebene die Neustrukturierung des gesamten Unternehmens in die Wege leiten.
Zusammengefasst waren die Vorbedingungen für die Neustrukturierung in unserem Fall:
- Menschen, die täglich mit agilen Methoden arbeiten und damit Erfolge erzielen.
- Die Fähigkeit, die Projekte als Experimente zu sehen und auch im Fall des Scheiterns aus ihnen zu lernen.
- Rückhalt von einer in der Hierarchie höher angesiedelten Person, die die Durchführung der Experimente legitimiert und unterstützt.
- Tiefes theoretisches Wissen über die Marktdynamik und ihren Einfluss auf Unternehmen, um ungeeignete Strukturen zu erkennen und geeignete Strukturen erschaffen zu können
In diesem Sinne hat die agile Transformation nun erst so richtig begonnen. Einige Anstrengungen werden auch in der Zukunft erfolgreich sein und andere scheitern. Wichtig ist, diese neuen Experimente mit genügend theoretischem Verständnis zu analysieren, Erkenntnisse zu erlangen und diese kontinuierlich in neue Experimente einfließen zu lassen. Wenn die Organisation diese Fähigkeit erwirbt und durch ihre (flexible) Struktur unterstützt, wird sie mit viel Freude und intrinsischer Motivation auf die neuen Reize des Marktes antworten können.
