Command & Control, SAFe, Domain-driven Design und Release-Trains

Inhaltsverzeichnis

Große komplexe Projekte sind schwer zu handhaben. Software-Release-Trains sind eine Lösung zur Koordination. Aber der Ansatz läuft Selbstorganisation und modernen Management-Konzepten zuwider.

Ein Release Train dient zur Koordination mehrerer abhängiger Projekte. Im Rahmen dessen entwickeln alle Projekte aufeinander abgestimmte Versionen, die Phasen wie Beta-Testing, Release oder Updates gemeinsam durchlaufen. Die Idee hat sich in vielen großen Projekte wie Eclipse, Ubuntu, dem Spring Framework oder LibreOffice bewährt.

Das Scaled Agile Framework (SAFe) schlägt einen Agile Release Train vor, um die Arbeit mehrerer agiler Teams zu koordinieren. Sie haben einen festen Zeitpunkt, zu dem sie liefern, und bieten alle zwei Wochen ein neues Systeminkrement mit einer System-Demo. Der Agile Release Train koordiniert die Entwicklung der Software und dann das Release, nach dem Nutzer die neuen Features verwenden können. Also geht es darum, die Entwicklung eines oder mehrerer größeren Features über mehrere Teams zu koordinieren. Das Ziel ist es, dass nicht nur die einzelnen Teams, sondern auch das gesamte System regelmäßig neue Features ausrollt. So sollen mögliche Probleme bei den größeren Features offenbar werden. Natürlich gibt es für einen Agile Release Train diverse Rollen für eine zentrale Koordination.

Koordination ist für eine Zusammenarbeit immer notwendig, aber es erzeugt auch einen Overhead. Eine zentrale Koordination steht in einem Widerspruch dazu, möglichst viel Verantwortung zu delegieren. Moderne Organisationen sollten möglichst wenig Hierarchien haben und die Teams sollten selbstorganisiert arbeiten, statt auf die zentrale Koordination und ein Command & Control angewiesen zu sein. Ohne eine zentrale Kontrolle skaliert die Organisation außerdem besser.

Architektur statt Koordination!

Übermäßige Koordination ist zwar ein organisatorisches Problem, aber die Ursache kann ein Architektur-Problem sein: Wenn Änderungen, die für einen Kunden einen Wert darstellen, die Koordination mehrerer Teams und Komponenten erfordern, kann ein besserer fachlicher Schnitt die Anzahl der beteiligten Komponenten und damit der Teams reduzieren. Domain-driven Design schlägt dafür einige Maßnahmen vor. Wenn die Koordination in einem Agile Release Train sehr kompliziert ist, dann lohnt es sich auf jeden Fall, einen Blick auf die Architektur zu werfen und zu schauen, ob dort Optimierungspotenziale vorliegen.

Aber auch wenn die Softwarearchitektur perfekt ist, können für ein Feature natürlich Änderungen notwendig sein, die mehrere Teams betreffen. Schließlich arbeiten die Teams gemeinsam an einem System, und Features können daher immer auf mehrere Teams verteilt sein. Dafür schlägt Domain-driven Design auch verschiedene Pattern vor. Bei dem Pattern "Customer/Supplier" (Kunde/Lieferant) kann das Customer-Team bei dem Supplier-Team die Implementierung von Features anfordern. Die Alternative ist "Conformist": Dann muss das Team nehmen, was es bekommt, und kann keine Implementierung von Features anfordern.

Also kann ein DDD-Team auch dann ein Feature implementieren, wenn es dazu auf Zulieferungen angewiesen ist. Dazu müssen lediglich die "Spielregeln" zwischen Teams wie Customer/Supplier festgelegt sein. Natürlich kann es gegebenenfalls notwendig sein, noch eine Eskalationsinstanz für Streitigkeiten zu definieren, aber unter normalen Umständen können die Teams so ohne zentrale Koordination arbeiten und sich untereinander dezentral koordinieren.

Partnerschaft: eine zu enge Bindung?

Die kollaborative Entwicklung von Features ähnlich wie bei einem Agile Release Train gibt es bei DDD auch. DDD beschreibt es als "Partnership". Nun ist eine Partnerschaft eigentlich positiv besetzt. Die englische Ausgabe der DDD-Referenz nutzt zur Illustration von Partnership ein Drei-Bein-Rennen, also ein Rennen, bei dem die Teilnehmer an einem Bein zusammengefesselt sind. Eine solche Partnerschaft und die damit verbundene enge Koordination führen eher zu einem Problem, so wie es bei einem Agile Release Train auch zu erwarten ist.

Fazit

Eine enge zentralen Koordination, wie sie Agile Release Trains umsetzen, sollte bei einer guten Softwarearchitektur nicht unbedingt notwendig sein und kann mit anderen Mitteln umgangen werden. Vielleicht ist die wahrgenommene Sicherheit ein Grund dafür, dass Ansätze wie SAFe erfolgreich sind. Durch die Koordination wird eine Kontrolle des Fortschritts auf der Ebene des Gesamtprojekts möglich und notwendig. Das kann eine höhere Sicherheit vermitteln. Zuständigkeiten wirklich an Teams zu delegieren erfordert hingegen ein hohes Maß an Vertrauen.

tl;dr

Release Trains koordinieren die Zusammenarbeit verschiedener Teams. Ansätze aus dem Domain-driven Design hingegen delegieren noch mehr Zuständigkeit in die Teams und benötigen daher weniger Koordination

Vielen Dank an meine Kolleginnen und Kollegen Anja Kammer, Martin Kühl, Torsten Mandry, Sebastian Schwaiger und Benjamin Wolf für die Kommentare zu einer früheren Version des Artikels. ()