Iterative Anpassung für adaptive Organisationen
Organisationen sind keine statischen Systeme, sondern adaptive Netzwerke, die sich kontinuierlich verändern. Die Arbeit im Umfeld soziotechnischer Architekturen muss daher iterativ und kontinuierlich gestaltet werden. Es gibt kein „fertig“ – stattdessen erfordert der Wandel regelmäßige Anpassungen und Feedbackschleifen. Zwei zentrale Prinzipien sind hierbei essenziell:
- Psychologische Sicherheit: Teams müssen in einem Umfeld arbeiten können, in dem sie frei experimentieren, lernen und Fehler machen können, ohne Angst vor negativen Konsequenzen.
- Schneller Arbeitsfluss: In einer Welt, die auf Economies of Speed setzt, ist es entscheidend, Hindernisse im Arbeitsfluss zu erkennen und zu beseitigen.
Team Topologies: Strukturen für Fast Flow
Der Ansatz von Team Topologies, der von Matthew Skelton und Manuel Pais 2019 mit einem gleichnamigen Buch vorgestellt wurde, bietet einen klaren Rahmen, um Teams entlang der Wertschöpfung und Arbeitsflüsse zu organisieren. Team Topologies zielt darauf ab, die kognitive Belastung der Teams zu minimieren und gleichzeitig den Fokus auf den Fluss von Arbeit zu legen. Dies ist besonders relevant für IT-Organisationen, die mit zunehmender Komplexität und Geschwindigkeit konfrontiert sind.
Kernkonzepte von Team Topologies:
Team Topologies kennt vier grundlegende Team-Arten. Diese sind:
- Stream-Aligned Teams, die direkt zur Wertschöpfung bei den Kunden eines Unternehmens beitragen. Alle anderen Team-Arten tragen dazu bei, diese Teams in die Lage zu versetzen, möglichst schnell liefern zu können.
- Enabling Teams, die Stream-Aligned Teams beim Aufbau neuer Fähigkeiten unterstützen und dabei selbst auf ein bestimmtes Fachgebiet spezialisiert sind.
- Complicated Subsystem Teams, die auf hochkomplexe technische Komponenten spezialisiert sind, die Fähigkeiten erfordern, welche am Markt nur schwer zu rekrutieren sind.
- Platform Teams, die Self-Service-fähige Plattformen anbieten, auf denen andere Teams aufsetzen, um den Kunden Dienste und Fähigkeiten mit Mehrwert anzubieten.
Des Weiteren setzt Team Topologies auf drei Modi der Team-Interaktion: Teams arbeiten je nach Bedarf kollaborativ zusammen (Collaboration), bieten Dienste ohne Koordinierungsaufwand an (X-as-a-Service) und unterstützen andere Teams (Facilitating).
Man sollte Team Topologies jedoch nicht auf die vier Team-Arten und drei Modi der Team-Interaktion reduzieren. Im Kern geht es bei dem Ansatz um organisatorische Ideen, um einen schnellen Arbeitsfluss in der Delivery-Organisation zu etablieren. Dabei sollte dieser regelmäßig überprüft und hinterfragt werden, wobei Techniken wie Value Stream Mapping oder Flow Engineering hilfreich sind. Des Weiteren setzt Team Topologies einen Fokus auf die kognitive Belastung der Teams. Nur Teams mit gesunder Belastung werden in der Lage sein, schnell zu liefern.
Team Topologies ist kein starres Modell, sondern ein Ansatzpunkt, der iterativ eingesetzt werden will. Entscheider:innen können dies zusammen mit ihren Teams nutzen, um schneller auf Marktveränderungen zu reagieren und den Arbeitsfluss innerhalb ihrer Organisation zu optimieren.
Domain-Driven Design: Purpose durch klare Domänengrenzen
Domain-Driven Design (DDD) wurde im Jahre 2003 von Eric Evans im Rahmen des gleichnamigen Buchs vorgestellt. Der Ansatz beschreibt eine fachliche, domänengetriebene Modellierung von komplexen Systemlandschaften. Domain-Driven Design hat zwar seine Ursprünge in der Software-Architektur und -Entwicklung, hat sich im Laufe der Jahre deutlich darüber hinaus entwickelt. Es bietet eine Methodik, um die Komplexität moderner Organisationen zu bewältigen, indem sie in klar definierte Domänen ausgehend von fachlichen Herausforderungen schneidet und dann mit Hilfe von daran angelehnten Bounded Contexts löst. Team Topologies empfiehlt beispielsweise explizit, Grenzen von Teams entlang von Bounded Contexts zu schneiden.
Alignment auf Zweck (Purpose)
Ein zentraler Aspekt von DDD ist das Alignment auf den Zweck innerhalb der Bounded Contexts. Diese definieren nicht nur technische Grenzen, sondern auch die Verantwortung und den Fokus der Teams. Dabei lassen sich spannende Parallelen zu den Prinzipien aus Daniel H. Pinks Buch Drive ziehen: DDD schafft die Grundlage, in der Teams Autonomy, Mastery und Purpose erreichen können.
- Autonomy: Klare Grenzen fördern die Eigenverantwortung der Teams.
- Mastery: Innerhalb eines Bounded Contexts können sich Teams auf ein spezifisches Problem oder eine Domäne spezialisieren.
- Purpose: Der Fokus auf die jeweilige Domäne ermöglicht es Teams, ihren Beitrag zur Gesamtstrategie der Organisation klar zu erkennen.
Strategisches Staffing und Procurement: Core, Supporting und Generic Domains
DDD unterscheidet zwischen Core Domains, Supporting Domains und Generic Domains:
- Core Domains: Diese sind geschäftskritisch und bieten den größten Wettbewerbsvorteil. Sie sollten in der Regel mit internem Know-how aufgebaut und langfristig gepflegt werden.
- Supporting Domains: Diese unterstützen die Kernprozesse, sind jedoch weniger kritisch. Hier können Partnerschaften oder externe Unterstützung sinnvoll sein.
- Generic Domains: Standardisierte Bereiche, die keinen Wettbewerbsvorteil bringen. Diese sollten bevorzugt eingekauft werden.
Diese Klassifizierung hilft IT-Entscheider:innen dabei, strategisch kluge Make-or-Buy-Entscheidungen zu treffen. So kann die interne Expertise gezielt auf die Kernbereiche fokussiert werden, während unterstützende und generische Bereiche effizient ausgelagert werden.
Iteration und Individualisierung: Keine Silver Bullet
Alle vorgestellten Methoden liefern wertvolle Werkzeuge, sind jedoch keine universellen Lösungen. Entscheider:innen sollten jede Methode an die spezifischen Anforderungen ihrer Organisation anpassen. Eine iterative Herangehensweise ist dabei essenziell: Organisationen sind dynamisch, und ihre Strukturen müssen kontinuierlich überprüft und optimiert werden.
Die Werte des Agile Manifestos können hierbei als Leitplanken dienen. Werte wie „Reagieren auf Veränderung über das Befolgen eines Plans“ und „Zusammenarbeit über Vertragsverhandlungen“ erinnern daran, dass der Mensch und die Zusammenarbeit im Mittelpunkt jeder Transformation stehen.
Dieser Artikel ist Teil des INNOQ Technology Briefings – unserem Report für Technologieentscheider:innen. Jetzt herunterladen und mehr zum Thema soziotechnische Architekturen erfahren.