Im letzten Blogbeitrag der Blogserie „Wann schaffen wir endlich das PI ab“ haben wir die systemseitige Synchronisierung diskutiert. Dieser Blog widmet sich der Synchronisierung zwischen Teams und/oder ARTs (Agile Release Trains).
Diese Synchronisation ist notwendig. Ohne diese Synchronisation laufen die Dinge auseinander. Worüber ich stolpere: «alle gemeinsam»?! Hier ist ein Prinzip, das einmal im Kleinen sinnvoll bis notwendig war, auf eine Ebene gehoben worden, auf der das Prinzip keinen Sinn mehr macht.
Sehen wir uns dazu Prinzipien einer Architektur an. Ich rede hier nicht von Software oder System Architektur. Grundlegende Architekturprinzipen gelten nicht nur in der IT. Sie gelten auch für Organisationen, Geschäftsprozesse, für Gebäude, im Sportverein. Zwei wesentliche Prinzipien sind
- Seperation of concerns: Zwei orthogonale (also voneinander unabhängige) Aspekte werden unabhängig voneinander formuliert und bewirtschaftet
- High cohesion and loose coupling: Eine qualitativ hochwertige Architektur weist folgende Eigenschaften auf: Elemente die aufgrund eines gemeinsamen Aspekts zusammengehören, bilden ein lokales Netz mit hoher Kopplung und Interaktion der Elemente. Diese lokalen Netze sind untereinander durch die minimal mögliche Anzahl an Abhängigkeiten lose gekoppelt. Die Abhängigkeiten zwischen den Netzen sollten zudem unkritisch sein, im Sinne der Funktionsweise des Gesamtnetzes.
Ok, nun wenden wir das auf eine Organisation an. Werden eine Organisation und ihre darin lebenden Geschäftsprozesse nach einem Domain Driven Ansatz formuliert, so ist schnell zu erkennen, dass die Organisation aus vielen Subdomains besteht.
Domain Driven Ansatz:
Ein Ansatz, eine Wissensdomäne oder eine Fachdomäne, wie zum Beispiel das Retail Online Business in fachliche und technische Bestandteile (Sub Domains) zu zerlegen, die möglichst unabhängig voneinander sind.
So können sich diese Sub Domains recht unabhängig voneinander entwickeln, sowohl aus einer fachlichen, wie auch aus einer technischen Sicht.
Zudem besitzt eine solche Sub Domain typisch auch ihre eigene Begriffswelt und Terminologie. Man denke zum Beispiel an ein Underwriting (Versicherungswesen). Wenn dort die Experten miteinander diskutieren, dann verstehen wir Normalbürger zwar die Worte, aber nicht den Sinn der Worte. Da wir jedoch in einem Unternehmen für die Underwriter auch Software entwickeln wollen, ist es wichtig, ihre “Sprache” zu verstehen. Diese domänenspezifische Sprache wird auch “ubiquites language” bezeichnet.
Diese besitzen Abhängigkeiten zueinander. Die maximal mögliche Anzahl Abhängigkeiten der Subdomains beträgt mathematisch gerechnet n*(n-1)/2, mit n als die Anzahl der Subdomains. Ein nicht wissenschaftlicher Check von mir (das wäre einmal einer Untersuchung wert) der Umgebungen, die ich kenne – aus Transport, Versicherungen und eHealth, – weist eine in Realität erheblich geringere Anzahl an Abhängigkeiten zwischen den fachlichen Subdomains des Unternehmens aus, geschätzt ein Drittel davon.
Wenn nun autonome Teams für die Entwicklung von Subdomains verantwortlich sind, dann müssen sich genau diejenigen Teams synchronisieren, die Abhängigkeiten besitzen. Es ist also möglich, Cluster von Teams mit Abhängigkeiten zu identifizieren. Konsequent zu Ende gedacht: NICHT ALLE TEAMS müssen sich gemeinsam an einem Event synchronisieren. Es genügt, wenn sich ein Cluster von Teams synchronisiert.
Nun steckt in SAFe der Gedanke von ARTs, einschliesslich der Idee, dass ein ART nach dem Gedanken des Domain Driven Ansatzes identifiziert wird und genau somit dem zweiten Architektur Prinzip folgt. Ein ART wäre dann so ein Cluster an Teams. Wenn wir nun in die Realität der ARTs in Unternehmen sehen, wird dem Prinzip (leider) nur geringfügig gefolgt. Was SAFe jedoch anbietet, ist ein Management Konzept im PI Planning, um Abhängigkeiten zu managen. Das ist doppelt schade. Anstatt einen Ansatz zur Verfügung zu stellen, wie Abhängigkeiten vermindert werden können, managen wir Defekte im organisatorischen Ansatz ohne Anreiz zur Optimierung.
Mein Plädoyer: In ein für das Unternehmen geeignetes Domänenmodell investieren (bitte nur ein einziges) und anschliessend den Cluster von Teams (wir können diese ja als ARTs organisieren) maximal mögliche Autonomie geben. Dann das PI für alle kippen und die Cluster ihre spezifischen Abhängigkeiten mit geeigneten Synchronisierungsmechanismen adressieren lassen.
Fazit: Mit einem geeigneten Domain Driven Design Ansatz für die Geschäftsmodelle der Unternehmen ist es möglich die Abhängigkeiten zwischen (Cluster von) Teams zu vermindern und damit Komplexität aus dem System zu nehmen. Die verminderte Komplexität erlaubt es, dem Cluster mehr Autonomie zu geben, mit weniger Notwendigkeit zur Synchronisierung unter Clustern. Der Aufwand für das Management von Abhängigkeiten sinkt, so dass ein gemeinsames PI Planning überflüssig ist.
Mit dem zweiten Blog haben wir nun die Aspekte der systemtechnischen und der organisatorischen Synchronisierung diskutiert und erkannt, dass wir deutlich dezentraler mit mehr Autonomie arbeiten können. Haben wir nun gar keine Gemeinsamkeiten im Unternehmen? Was ist mit einer gemeinsamen Vision? Diesen Aspekt diskutiere ich in dem dritten Blog der Blogserie “Wann schaffen wir das PI ab”.
