Erfolgreich in komplexen Märkten: Mit Team Topologies auf der Überholspur

Jun 23
Die Art und Weise, wie ein Team miteinander kommuniziert, beeinflusst direkt die Struktur und Qualität des Ergebnisses, das es produziert.

Der Zusammenhang, dass die Systeme, die eine Organisation entwickelt, die Kommunikationsstruktur dieser Organisation widerspiegeln, wird als Conways Law bezeichnet.

Conways Law ist eine wichtige Grundlage, um den Ansatz der hinter Team Topologie steht zu verstehen. Doch ohne den Fokus auf die Wertschöpfung kann das Konzept nicht greifen und die Beschäftigung mit Team Topologie wird zum Theater.

Die Methode für "Fast Flow"

Die Grundidee des Team Topologies Ansatzes (Matthew Skelton & Manuel Pais) besteht darin, Teams in einer Organisation so zu strukturieren, dass sie optimal auf die Systeme abgestimmt sind und effektiv zusammenarbeiten können. Indem wir die kognitive Belastung der Teams überschaubar halten, schaffen wir die Voraussetzungen für eine reibungslose, kontinuierliche Bereitstellung von Werten. 

Das Versprechen lautet, dass Unternehmen die Team Topologies einsetzen sich schneller an sich verändernde Anforderungen anpassen können und Dinge effizienter voranzutreiben.
Ziel ist ein "Fast Flow", die schnelle und effiziente Bewegung von Arbeit oder Wert durch ein System oder einen Prozess. Im Sinne der durch Eliyahu M. Goldratt geprägten Theory of Constraints müssen, um "Fast Flow" zu erreichen Engpässe minimiert, Durchlaufzeiten verkürzt und die Reaktionsfähigkeit einer Organisation auf Änderungen verbessert werden.

Man könnte sagen, Team Topologies ergänzt den Aspekt des Fast Flow um die Dimension der wertschöpfenden Teams und setzt diese mit den Herausforderungen der Software- und Datenarchitekt in Beziehung. 

Um zu verstehen, warum auch Sie (wie wir) ein Fan dieses Ansatzes sein sollten, beginnt man am besten bei Conways Law und seiner Bedeutung für Organisationen.

Conways Law

Stellen wir uns vor, wir wollen ein komplexes Gericht zubereiten, das viele verschiedene Zutaten erfordert. Jede Zutat muss in der richtigen Menge und Qualität zur richtigen Zeit verfügbar sein, damit das Gericht perfekt gelingt. Nun gibt es verschiedene Möglichkeiten, wie die Zutaten beschafft werden können: von einem zentralen Markt oder von vielen kleinen lokalen Märkten.

Die Art und Weise, wie die Zutaten beschafft werden, beeinflusst direkt, wie das Gericht am Ende schmeckt. Wenn alle Zutaten von einem einzigen zentralen Markt bezogen werden, mag es effizient sein, aber möglicherweise leiden Qualität und Frische der Zutaten. Einige Zutaten könnten perfekt sein, während andere nicht optimal sind, was das Endergebnis beeinträchtigt.

Auf der anderen Seite, wenn die Zutaten von verschiedenen lokalen Märkten beschafft werden, wo jede Zutat spezifisch für ihren Ursprung und ihre Qualität ausgewählt wird, könnte das Gericht am Ende vielschichtiger und geschmacklich komplexer sein. Allerdings erfordert dies eine bessere Koordination und Planung, da jede Zutat zur richtigen Zeit am richtigen Ort sein muss, um in das Rezept integriert zu werden.

Diese Analogie zeigt, wie wichtig es ist, dass die „Beschaffung“ von Ressourcen in einem Projekt – also die Zusammenarbeit der verschiedenen Teams, Abteilungen und Partner – gut aufeinander abgestimmt ist. Wenn die Organisation zu stark zentralisiert ist, kann es sein, dass einige Teile des Projekts darunter leiden, während andere glänzen. Wenn die Organisation hingegen dezentralisiert ist und jede „Zutat“ sorgfältig ausgewählt und integriert wird, könnte das Projekt als Ganzes erfolgreicher sein, aber es erfordert auch mehr Aufwand in der Abstimmung.

Was ist mit der Wertschöpfung?

Ein häufiges Problem, das in Organisationen auftritt, die versuchen ihre Team- und Systemstrukturen optimieren, aber Conways Law nicht beachten, ist die Tendenz, Teams nach Tätigkeitsbereichen zu organisieren, wie z.B. Frontend, Backend oder Datenbank. Dies führt oft zu Silostrukturen, die die Entwicklung von funktionsübergreifenden Features erschweren. Ebenso führen Aufteilungen entlang des Produkt-Lebenszyklus, wie Analyse, Design, Coding und Testing, zu vielen Übergaben und Kommunikationsbarrieren. 

Wir können uns Conways Law natürlich besser zu Nutze machen. Wenn wir die Teamstrukturen bewusst so zu gestalten, dass sie die Entstehung der gewünschten Softwarearchitektur fördern, führen wir ein so genanntes „Inverse Conway Maneuver“ durch. 

Dabei dürfen wir einen entscheidenden Faktor darf nicht außer Acht lassen: die Wertschöpfung. Wertströme repräsentieren die Pfade, entlang derer Wert innerhalb der Organisation fließt – von der Idee bis hin zur Auslieferung an den Kunden. 
Würden Sie die Wertströme nicht in den Mittelpunkt Ihrer Überlegungen stellen, würden entweder die Teams oder die Systeme die Struktur vorgeben. Doch weder die eine noch die andere Möglichkeit führt zu der Flexibilität, die notwendig ist, um auf Marktveränderungen effektiv zu reagieren. Nur durch die konsequente Ausrichtung deiner Organisation auf die Wertschöpfung kannst du sicherstellen, dass die Struktur deiner Teams und Systeme flexibel genug ist, um sich dynamisch an veränderte Bedingungen, wie sie vom Markt kommen, anzupassen. 

Durch die Ausrichtung der Teams an den Wertströmen wird also sichergestellt, dass die Teams direkt an den entscheidenden Punkten für die Wertschöpfung arbeiten und somit unmittelbaren Einfluss auf das Geschäftsergebnis haben.

Domain Driven Design

Die grundlegende Überlegung ist also: Indem wir (autonome) Business Capability - zentrierte Teams bilden, die eigenständig Kundenwert liefern, muss durch diese Organisationsstruktur auch eine Architektur entstehen, die ebenfalls (autonom und) flexibel ist.

Domain Driven Design (DDD) ist das Hilfsmittel, um eine solche Architektur zu entwickeln. Es ermöglicht komplexe Systeme in klar definierte Domänen zu unterteilen, die den Business Capabilities der Wertströme entsprechen. 

Indem Teams auf diese Domänen ausgerichtet werden, können sie ihre Expertise in spezifischen Bereichen vertiefen und gezielt auf die Bedürfnisse und Herausforderungen ihrer jeweiligen Domäne eingehen. Dies führt zu einer stärkeren Fokussierung, reduziert die kognitive Belastung und fördert eine effizientere Zusammenarbeit. Die entstehende System-Architektur ist maximal flexibel gestaltet, um auf Veränderungen zu reagieren.
Diese Domänen – oder „Bounded Contexts“ – haben jeweils ihre eigene Fachsprache und ihre eigenen Prozesse, die von den Teams in diesen Domänen verstanden und gepflegt werden.

Das bedeutet...

Conways Law zeigt uns, dass die Struktur von Systemen die Kommunikationswege in einer Organisation widerspiegelt. Team Topologies nutzen dieses Prinzip, um Teams entlang der Wertströme zu organisieren, während Domain Driven Design dafür sorgt, dass diese Wertströme klar definiert und strukturiert sind. Durch die Kombination dieser Ansätze kann eine Organisation die Flexibilität und Dynamik entwickeln, die notwendig ist, um in einem sich ständig verändernden Marktumfeld erfolgreich zu sein. 

Sind Sie bereit, diesen holistischen Ansatz zu verfolgen und so Ihre Organisation auf ein neues Level zu heben? Gerne würden wir Sie dabei unterstützen!