Das Gesetz von Conway besagt:
„Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.“
Was genau hat dieses Gesetz jetzt mit agilen Transformationen zu tun?
Nach diesem Gesetz hat jede Organisation, die ein System designed hat genau das System, dass zur Organisationsstruktur passt. Das Gesetz funktioniert in beide Richtungen. Entwirft man ein System (bspw. Software Architektur) und parallel eine Organisation aufbaut, wird sich der Systementwurf genauso in der Organisation wiederfinden.
Die Auswirkungen erläutere ich anhand eines Beispiels. Eine Organisation betreibt seit einigen Jahren eine Platform zum Verkauf von Tickets zu diversen Veranstaltungen (Theater, Konzerte, Musicals, …). Zur Betreibung der Plattform kommen folgende Komponenten zum Einsatz
Die Pflege und Weiterentwicklung dieser Komponenten liegen bei jeweils einer Organisationseinheit (Abteilung, Team o.ä.). Daneben kommen noch die übergreifenden Teams UX und Datenbank zum Einsatz.
Conway’s Law zufolge gab es entweder einen Beschluss auf Organisationsebene mit diesen Organisationseinheiten ein entsprechendes Ticketsystem zu bauen oder es gab einen Systementwurf und die Organisation hat sich dem Entwurf entsprechend darum gebildet.
In der aktuellen Konstellation ist es für die einzelnen Teams nahezu unmöglich unabhängig voneinander Kundennutzen zu generieren. Bei jeder Funktionalität sind mindestens zwei, eher sogar drei bis vier Teams involviert. Um diese Abhängigkeiten untereinander aufzulösen besteht die Möglichkeit cross-funktionale Teams aufzustellen. Diese cross-funktionalen Teams werden aus den Spezialisten der verschiedenen Fachteams besetzt. Die cross-funktionale Besetzung erlaubt es relativ unabhängig voneinander neue Funktionalitäten für die Kunden zu entwickeln.
Zwei Möglichkeiten für solch Cross-funktionale Teams sind ein Kanal- oder ein Funktionsorientierter Schnitt der Teams. Kanalorientiert bedeutet, dass der neue Organisationsschnitt sich an den zu beliefernden Kanälen ausrichtet. Bei diesem Schnitt wird die komplette Wertschöpfung aus Sicht des Nutzers eines bestimmten Kanals betrieben (also z.B. aus Sicht des Webseiten ODER des Android App Nutzers). Bei der funktionsorientierten Organisation werden entlang der spezifischen Funktionen Teams geschnitten. Diese Teams entwickeln alles, was mit einer spezifischen Funktion zu tun hat (Teams für die Funktionalitäten Bezahlungssystem, Kundeninformationen usw.) Von der Webseite / App bis zu den entsprechenden Backend-Systemen und internen Mitarbeiter Frontends.
Beim kanalorientierten Schnitt hat sich Team Web aus folgenden Spezialisten gebildet
Sehr ähnlich wären Team iOS und Team Android aufgestellt. Prinzipiell sind die Teams so aufgestellt, dass sie unabhängig in der Lage sind Wert für den Kunden zu schaffen. Was sich in der Theorie gut anhört und auf der grünen Wiese auch super funktioniert. Bei dem vorhandenen System entsteht aber folgende Konsequenz. So unabhängig voneinander wie ursprünglich gedacht sind die Teams nicht. Die Abhängigkeit wurde aktuell nur an eine andere Stelle im System geschoben. Durch die Neuorganisation gibt es weiterhin Abhängigkeiten zwischen den Teams auf Seiten der Backend-Systeme. Diese Systeme orientieren sich weiterhin an der bisherigen Organisationsstruktur. Es wurde nur eine neue Komplexität eingeführt, mit der man umgehen muss.
Die Entwickler der Backend-Systeme haben erhöhten Koordinations- und Kommunikationsaufwand. Möglicherweise arbeiten sie enger mit ihren Fach-Kollegen aus den anderen Teams zusammen. Gefühlt hat sich also für die betroffenen Kollegen im Zuge der Transformation nur eine neue Komplexität und erhöhter Aufwand ergeben. Sie müssen sich nicht nur mit Ihren neuen Teams eng abstimmen sondern auch mit ihren alten. Es ergeben sich Schattengesellschaften und informelle Teams. Die Mitarbeiter wissen nicht so richtig wohin sie gehören und die neuen Teams kommen nicht richtig ans Laufen. Die betroffenen Kollegen werden schlimmstenfalls, bewusst oder unbewusst, gegen die Transformation arbeiten, da sich für sie nur eine Verschlimmbesserung eingestellt hat. Die agile Transformation endet also bevor sie richtig begonnen hat.
Konsequenter ist es im Zuge des Neuschnitts der Organisation / der Teams auch die Systemarchitektur mit einzubeziehen und entsprechend der Teams neu zu entwerfen. Bei diesem Neuentwurf sollte darauf geachtet werden, dass die Abhängigkeiten der Entwickler untereinander so gering wie möglich werden. Dies wird durch konsequente Modularisierung, Zerschlagung in Microservices und ggf. sogar Duplizieren von Funktionalität erreicht. Eventuell muss man sogar den kompletten Aufbau der Systemlandschaft überdenken und sie sukzessive von den Teams neu gestalten lassen. So steht den Teams eine Systemlandschaft zur Verfügung haben, in der sie performant und effizient neuen Nutzen für die Kunden des Unternehmens generieren können. Durch die Arbeit an der Systemarchitektur arbeiten die Teams aktiv während ihrer täglichen Arbeit an der Transformation mit. Sie gestalten sie aktiv und bekommen den Nutzen direkt zu spüren.
Werden im Zuge von agilen Transformationen Teams und Organisationseinheiten neu geschnitten werden, hat diese Umorganisation nicht nur Einfluss auf die Menschen. Die Neuorganisation hat ebenfalls Einfluss auf die zugrunde liegende Systemlandschaft. Die Umbaumaßnahmen an der Systemarchitektur muss als Teil der Transformation eingeplant werden. Ignoriert man die Umbaumaßnahmen wird das im schlimmsten Fall die Transformation scheitern lassen, da Organisation und Systemarchitektur nicht mehr zusammenpassen.
Mach Dein nächstes Projekt zum vollen Erfolg
Über 70 % aller großen IT-Projekte scheitern, weil die Fehler an der falschen Stelle gesucht werden. Lerne die wahren Erfolgstreiber für Leuchtturm-Projekte kennen.
Im E-Book "Endlich erfolgreiche Projekte" decken wir die 3 Hauptgründe für das Scheitern von Projekten auf!
KOSTENFREIES E-BOOK
Sichere Dir jetzt unser Gratis E-Book "Endlich erfolgreiche Projekte"
