Problemstellung
Meistens laufen Projekte nicht so ab, wie gewünscht. Die Projektlaufzeit wird stetig verlängert. Änderungen werden komplizierter bis nahezu unmöglich. Der Chaos Report zeigt, dass nicht einmal 20% aller Projekte erfolgreich abgeschlossen werden. Mehr als die Hälfte werden nur teilweise erfolgreich abgeschlossen. Das bedeutet, dass es zu Kosten- und/oder Zeitüberschreitungen kam. Über 30% der Projekte werden abgebrochen oder niemals eingesetzt.
Die Gründe dafür sind vielfältig. Ein Grund dafür ist, dass Änderungen an der Software mit laufender Projektzeit immer komplizierter werden. Die Gründe, warum die Änderungen an der Software so kompliziert werden, sind ebenfalls vielfältig. So kann die Architektur es schwierig machen Änderungen vorzunehmen. Oder eine Änderung erfordert die Kommunikation zwischen vielen verschiedenen Software-Entwicklern. Oder es gibt nur wenige Software-Entwickler, welche überhaupt in der Lage sind, eine Änderung vorzunehmen. Oder es gibt komplizierte Abhängigkeiten zwischen Teamgrenzen hinweg. All die genannten Probleme sind Symptome eines übergeordneten Problems: einer unklaren Teamorganisation.
Eine unklare Teamorganisation bedeutet, dass keine klaren Teamgrenzen definiert sind und es keine klaren Kommunikationswege gibt. Aufgrund von Conway’s Law hat dies zur Folge, dass auch die Softwarekomponenten der einzelnen Teams keine klaren Grenzen besitzen und auch keine klaren Kommunikationsschnittstellen. Denn Conway’s Law besagt, dass sich die Architektur der Software der Kommunikationsstruktur der Teams annähern wird, welche die Software schreiben. Die Folge ist ein sogenannter verteilter Monolith.
Für eine Änderung an einem verteilten Monolithen müssen sich oftmals Teams miteinander koordinieren, weil einzelne Komponenten nicht klar genug voneinander abgegrenzt sind und das nötige Wissen über die Komponenten über viele Teams verteilt ist. Mit steigender Lines of Code wird es schwieriger die gesamte Codebase zu verstehen. Das bedeutet, dass sich Software-Entwickler zwangsläufig nur mit bestimmten Teilen der Software gut auskennen können. Wenn nun aber keine klaren Verantwortlichkeiten definiert sind, dann ist die Verteilung von Wissen über die Software nicht koordiniert. Das hat zur Folge, dass einige Änderungen nur durch manche Software-Entwickler umgesetzt werden können.
Team Topologies
Team Topologies soll dieses Problem lösen. Es ist ein Team-First Approach zur Organisation von Teams. Es nimmt an, dass das Team das atomare Element der Wertschöpfung ist. Der Ansatz steht im Gegensatz zu anderen Projektmanagement-Modellen, welche annehmen, dass das Individuum das atomare Element der Wertschöpfung ist. Team Topologies nimmt an, dass die Arbeit eines Teams nicht die Summe der Arbeit der Teammitglieder ist. Während klassisch davon ausgegangen wird, dass die Produktivität eines Teams von der Produktivität der einzelnen Teammitglieder abhängt, nimmt Team Topologies an, dass ein Team eine eigene Produktivität besitzt, welche nicht primär anhand der Produktivität der einzelnen Teammitglieder bestimmt wird.
Begründet wird diese Annahme mit der Tatsache, dass die Teamdynamik, die Intra-Team Kommunikation und die Inter-Team-Kommunikation große Einflussfaktoren auf die Produktivität des Teams sind. Weiterhin werden biologische Faktoren herangezogen, um diese Annahme zu begründen. So wird Cognitive Load als eine natürliche, biologische Grenze für Teamgrößen und Verantwortlichkeiten genannt. Es ist für eine einzelne Person unmöglich eine Codebase mit einer Million Zeilen vollständig zu verstehen. Also gibt es eine maximale Größe einer Codebase, welche ein einzelner Software-Entwickler verstehen kann. Das bedeutet, dass auch ein Team eine maximale Größe einer Codebase besitzt, welche das Team verstehen kann. Laut Team Topologies müssen Teamverantwortlichkeiten und Teamgrenzen primär anhand dieser Grenze geschnitten werden, sodass die Cognitive Load des Teams nicht zu hoch wird. Denn dies ist laut Team Topologies der Grund für eine abnehmende Produktivität von Teams. Um dies zu erreichen, definiert Team Topologies vier verschiedene Arten von Teams. Eine Art von Team ist dabei für die eigentliche Wertschöpfung verantwortlich, das Stream-Aligned Team. Die weiteren Teamarten haben lediglich die Aufgabe, die Cognitive Load aller Stream-Aligned Teams zu reduzieren, und damit dessen Produktivität sicherzustellen. Auf die vier verschiedenen Teamarten wird später weiter eingegangen.
Team Topologies argumentiert weiterhin, dass für eine gute Teamaufteilung Conway’s Law und Dunbar’s Number herangezogen werden müssen. Es wurde bereits erläutert, dass Conway‘s Law besagt, dass sich die Architektur von einem Produkt zwangsläufig analog zu den Kommunikationswegen der Software-Entwickler entwickelt. Dementsprechend ist es für Software-Entwickler spürbar, wenn eine Architektur vorgegeben ist, an welche sich die Software-Entwickler halten müssen, aber nicht an die Teamstruktur angepasst ist. Conway’s Law entstammt aus dem Paper „How Commitees Invent“ von Melvin Conway (Conway, 1968). Eine Studie aus dem Jahr 2011 unterstützt die These von Melvin Conway (Alan MacCormack, 2011). Der Begriff von Dunbar’s Number wurde von dem Anthropologen Robin Dunbar geprägt. Der Begriff besagt, dass eine Person nur mit einer begrenzten Anzahl von Personen eine enge und auf Vertrauen basierte Beziehung pflegen kann (Dunbar, 1992). Das bedeutet, dass das Vertrauen innerhalb eines Teams abnimmt, wenn das Team eine gewisse Größe übersteigt. Das ist der Grund dafür, dass Scrum eine Teamgröße von fünf bis elf Personen definiert. Auch Jeff Bezos berücksichtigt die Teamgröße dahingehend. Er fordert, dass ein Team bei Amazon eine Größe haben muss, sodass das Team mit zwei Pizzen verpflegt werden kann.
Belegt wird die Annahme, dass Teams eine Produktivität besitzen, welche nicht primär die Summe der Produktivität der Teammitglieder ist, mit einer Studie von Google. Diese kam zu dem Ergebnis, dass sich die Produktivität der Teams bei Google stärker von der Organisation der Teams und von den Rahmenbedingungen des Teams abhing als von den Fähigkeiten der einzelnen Software-Entwickler (Google, 2023). Die Studie kam zu dem Ergebnis, dass es stattdessen wichtig ist, dass Teammitglieder das Gefühl haben Risiken eingehen zu können, dass sich Teammitglieder aufeinander verlassen können, dass Ziele, Rollen und Arbeitsabläufe klar sind, und dass die Arbeit in den Augen der Mitarbeiter als etwas Wichtiges angesehen wird.
Die vier verschiedenen Teamformen von Team Topologies
In Team Topologies gibt es vier verschiedene Arten von Teams. Stream-Aligned Teams, Platform Teams, Complicated-Subsystem Teams und Enabling Teams. Stream-Aligned Teams ist die hauptsächliche Teamform. Sie ist cross-funktional aufgestellt und setzt Anforderungen um. Von der Idee bis zu dem Deployment. Cross-Funktional bedeutet, dass für jeden Schritt in der Wertschöpfungskette der Softwareentwicklung Teammitglieder vorhanden sind. Es gibt also für jede Rolle in der Wertschöpfungskette mindestens ein Teammitglied. Die Rollen sollten zumindest Requirements Engineering, Software-Entwickler, Tester und DevOps umfassen. Das macht es dem Team erst möglich die Anforderungen von Anfang bis Ende umzusetzen. Es kann mehrere Stream-Aligned Teams geben, und die meisten Teams sollten auch Stream-Aligned Teams sein. Jedes dieser Teams hat dabei die Verantwortung über einen Teil der Software.
Platform-Teams bilden eine Grundlage für Stream-Aligned Teams, um ihre Arbeit zu verrichten. Sie machen es den Stream-Aligned Teams einfacher die Anforderungen umzusetzen, indem es dessen Cognitive Load reduziert. Nehmen wir an es soll ein ERP-System entwickelt werden. Dazu wird eine GUI benötigt, welche auf den Kunden zugeschnitten werden soll. Die Oberfläche der Software verwendet GUI-Komponenten, welche spezifisch für die Software sind. Aufgabe des Platform Teams ist es dann die GUI-Komponenten zu entwickeln und über eine Library bereitzustellen, sodass die Stream-Aligned Teams diese nur noch benutzen müssen. Das sorgt dafür, dass die Stream-Aligned Teams sich auf die Wertschöpfung konzentrieren können, ohne sich mit den Details der Implementierung von speziellen Komponenten zu beschäftigen. Ein weiteres Beispiel ist ein Self-Service für das Deployment der Software. Damit sich das Stream-Aligned Team nicht mit den Details von Deployments befassen muss, kann ein Platform-Team alle Details des Deployments in einer Software umsetzen und den Stream-Aligned Teams eine Benutzeroberfläche liefern, über welche das Deployment mit dem Betätigen eines Buttons durchgeführt werden kann. So wird die Anzahl der Bereiche reduziert, in dem sich jeder Software-Entwickler in einem Stream-Aligned Team im Detail auskennen muss, was wiederum für eine niedrigere Cognitive Load sorgt. Das wiederum erlaubt es den Software-Entwicklern effizienter zu arbeiten.
Die Größe der Platform sollte dabei so klein sein, wie möglich. Sie sollte es den Entwicklern einfach machen wertschöpfende Arbeit zu leisten, aber keine Features umfassen, die darüber hinaus gehen. Die Platform selbst sollte als ein intern gemanagtes Produkt betrachtet werden. Kunde dieses Produktes sind die Stream-Aligned Teams. Die Entwicklung der Platform selbst kann wiederum anhand von Team Topologies organisiert werden. Das bedeutet, wenn eine Platform eine Größe erreicht, die mehrere Teams erfordert, dann sollten wieder mehrere Stream-Aligned Teams eingesetzt werden. Außerdem kann die Platform wiederum auf eine tiefer liegende Platform zurückgreifen. Das Prinzip der Platform als Produkt lässt sich rekursiv weiterführen. Wenn nun die Platform als Produkt betrachtet wird, dann bedeutet dies, dass die User Experience der Kunden eine wichtige Rolle spielt. Diese sollen zufrieden gestellt werden. Da der Kunde Stream-Aligned Teams sind, wird hier von Developer Experience (DevEx) gesprochen. Um eine hohe DevEx zu gewährleisten, ist es zwingend notwendig für Platform Teams, eine saubere Dokumentation der Platform zu erstellen, sowie How-to-Guides. Auch ein Feedback-Kanal muss aufgesetzt werden, sowie eine Service-Hotline. Darüber hinaus sollte die Platform typische Qualitätskriterien für Softwareprodukte erfüllen. Es müssen Betriebszeiten definiert werden.
Wenn ein Teil der Software ein spezielles Expertenwissen benötigt, um entwickelt zu werden, dann wird für diesen Teil der Software ein Complicated-Subsystem Team eingesetzt. Dadurch wird die Cognitive Load der Stream-Aligned Teams reduziert. Denn diese müssen sich nicht das spezielle Expertenwissen aneignen, und können sich auf die Verwendung des Subsystems konzentrieren. Das Complicated-Subsystem Team hat ebenfalls keine zu hohe Cognitive Load, weil dieses das spezielle Expertenwissen bereits besitzt und sich einzig und allein um das Subsystem kümmert, und nicht zusätzlich um andere Teile der Software. Dadurch werden Kontextwechsel verhindert, welche die Teammitglieder zusätzlich kognitiv belasten.
Aufgabe von Enabling Teams ist es sich kontinuierlich mit neuen Technologien auseinanderzusetzen, sodass sie die Stream-Aligned Teams coachen und unterstützen können. Denn für die Stream-Aligned Teams ist es absolut notwendig sich kontinuierlich weiterzubilden und sich zu verbessern. Da das Stream-Aligned Team aber damit beschäftigt ist dem Kunden einen Mehrwert zu bieten, bleibt keine Zeit sich intensiv mit neuen Technologien auseinanderzusetzen. Das Enabling Team bringt dem Stream-Aligned Team die nötigen Technologien und Methoden bei, sodass das Stream-Aligned Team seine Aufgaben besser erledigen kann. Es hilft dem Stream-Aligned Team außerdem dabei dessen Arbeitsweisen zu verbessern. Dazu kommuniziert es insbesondere über Teamgrenzen hinweg und löst Konflikte und Ungereimtheiten auf, welche zwischen Teams herrschen.
Die Inter- und Intra-Team-Kommunikation
Die Kommunikation zwischen Teams kann laut Team Topologies drei verschiedene Formen annehmen. Die X-as-a-Service Form, die Kollaborations-Form und die Förderungs-Form. X-as-a-Service bedeutet, dass das Team, welches den Service nutzt, im Grunde der Kunde des Teams ist, welches den Service anbietet. Das bedeutet, dass das Team, welches den Service bereitstellt, eine API für den Kunden, also das andere Team, bereitstellt. Diese API muss dokumentiert werden. Änderungen müssen mithilfe eines Changelogs dokumentiert werden. Auch How-to-Guides müssen durch das anbietende Team bereitgestellt werden. Die DevEx der API muss gut sein. Ein Beispiel für diese Form der Kommunikation wurde bereits genannt. So kann ein Platform Team einen Service anbieten und Stream-Aligned Teams können diesen Service nutzen. Die entsprechende Kommunikationsform ist X-as-a-Service. Doch auch unter Stream-Aligned Teams ist es möglich X-as-a-Service als Kommunikationsform zu verwenden. Wenn es Abhängigkeiten zwischen Stream-Aligned Teams gibt, dann sollte diese Form von Kommunikation verwendet werden, um eine lose Kopplung zu gewährleisten.
Die Kommunikationsform der Kollaboration bedeutet, dass zwei Teams nicht nur über eine API kommunizieren, welche von einem Team definiert wird, und von dem anderen Team verwendet wird. Es bedeutet, dass zwei Teams eng miteinander zusammenarbeiten. Eine enge Kollaboration sorgt dafür, dass der Code der beiden Teams stärker gekoppelt wird. Der Vorteil einer Kollaboration ist, dass sie es den beiden kollaborierenden Teams ermöglicht, mithilfe des gemeinsamen Wissens, neue Lösungsansätze zu entdecken und Innovationen zu schaffen. Wenn eine API zwischen zwei Teams geschaffen werden soll, dann kann es in der Anfangsphase sinnvoll sein, die Teams zunächst kollaborieren zu lassen. Das macht dem Team, welches die API bereitstellt, einfacher die Probleme des Teams zu verstehen, welches die API verwenden soll. Eine enge Abstimmung sorgt dafür, dass die API besser auf das Team zugeschnitten wird, welches die API verwenden soll. Die Kollaboration sollte aber zeitlich begrenzt sein, sodass der Code der beiden Teams nicht zu stark gekoppelt wird. Nachdem eine Schnittstelle definiert wurde, welche für die beiden Teams gut funktioniert, sollte sich aus der Kollaboration eine X-as-a-Service Kommunikationsform entwickeln. Wenn die Schnittstelle definiert wurde, sollte eine weitere enge Kollaboration zwischen den Teams nicht weiter notwendig sein.
Die Kommunikationsform der Förderung ist insbesondere für Enabling Teams wichtig. Bei dieser Kommunikationsform greift das fördernde Team nicht direkt in die Arbeit des zu fördernden Teams ein. Es bietet lediglich Expertenwissen für das zu fördernde Team an. Es bietet Hilfe zur Selbsthilfe. Es gibt dem zu fördernden Team jedes Wissen mit, welches dem Team dabei hilft, besser zu arbeiten. Diese Kommunikationsform differenziert sich von den anderen beiden Kommunikationsformen, indem mehr als nur zwei Teams an dieser Kommunikationsform beteiligt sein können. Die X-as-a-Service Kommunikation sollte immer nur zwischen zwei Teams bestehen und nicht zwischen drei Teams gleichzeitig. Das bedeutet nicht, dass ein Team nicht die gleiche API für mehrere Teams anbieten darf. Aber die beiden Teams, welche die API verwenden, sollten nicht über den gleichen Kommunikationsweg miteinander kommunizieren. Stattdessen kann zwischen den beiden Teams wiederum ein X-as-a-Service Kommunikationsweg bestehen, wobei ein Team die API bereitstellt und ein Team die API verwendet. Oder die beiden Teams können kollaborieren. Auch eine Kollaboration darf nicht zwischen mehr als zwei Parteien stattfinden. Bei der Kommunikationsform der Förderung ist dies hingegen explizit gewünscht. Das bedeutet, dass das Team, welches andere Teams fördern soll, über Teamgrenzen hinweg kommunizieren soll. Es soll mehreren Teams gleichzeitig bei der Auflösung von Problemen helfen. Dazu soll es nicht zuletzt teamübergreifende Probleme lösen. Es soll als Mediator zwischen Teams fungieren, sodass die Teams, welche Abhängigkeiten untereinander besitzen, besser aufeinander abgestimmt sind. Da das Enabling Team keinen direkten Einfluss auf den Code haben darf, also den Teams auch nicht einfach nur sagen darf, was sie zu tun haben, besteht hier keine Gefahr, dass durch diese Interaktion der Code zwischen den Teams stärker gekoppelt wird. Das Enabling Team hilft also bei der Auflösung von teamübergreifenden Problemen, ohne dabei für einen stärker gekoppelten Code zu sorgen.
Die Aufteilung der Software auf die Teams
Die Aufteilung von Teams richtet sich laut Team Topologies aufgrund von Conway’s Law an der gewünschten Architektur der Software. Es wird insbesondere das Reversed Conway Maneuver als Verfahren genannt, um die gewünschte Architektur der Software zu etablieren. Das Reversed Conway Maneuver ist ein Verfahren, bei welchem Teams so organisiert werden, dass die Kommunikationswege die Architektur hervorrufen, welche von den Architekten erwünscht ist. Das bedeutet auch, dass die Teamaufteilung durch Architekten vorgenommen werden sollte, und nicht durch einen Manager. Denn Architekten haben das nötige Wissen, um eine passende Architektur für die Software vorzusehen, und die Architektur der Software richtet sich nach den Kommunikationswegen in und zwischen Teams. Das bedeutet wiederum, dass es notwendig für Architekten ist, die Skills eines Managers zu besitzen, und darüber hinaus auch die Befugnisse, den Ruf und die Beziehungen.
Team Topologies sieht vor, die Software anhand von Fracture Planes aufzuteilen. Fracture Planes werden definiert als die natürlichen Nahtstellen innerhalb von Software-Systemen. Also Stellen, an denen die Software mit wenig Aufwand in zwei Teile gespalten werden kann. Weiterhin werden verschiedene Formen von Fracture Planes beschrieben, um diese abstrakte Definition weiter zu konkretisieren. So können Business Domain Bounded Contexts ein Fracture Plane sein, ebenso wie rechtliche Rahmenbedingungen, Änderungsfrequenz, Teamverteilung, Risiko, Performance-Isolierung, Technologien und User Personas.
Ein Business Domain Bounded Context ist definiert als eine kohärente, also in sich schlüssige, Teildomäne einer übergreifenden Domäne (Evans, 2004). Wenn die übergreifende Domäne beispielsweise das Gesundheitssystem ist, welches mit einer Software abgebildet werden soll, dann ist ein Krankenhaus eine Teildomäne hiervon. Denn das Krankenhaus ist eine in sich schlüssige Einheit innerhalb des Gesundheitssystems. Es interagiert über klar definierte Schnittstellen mit dem Rest des Gesundheitssystems. So wird das Krankenhaus durch Krankkassen bezahlt und es behandelt Patienten. Das Krankenhaus hat ebenfalls klare Zuständigkeiten innerhalb des Gesundheitssystems.
Wichtig ist es zu beachten, dass für das korrekte Aufteilen von Software anhand von Business Domain Bounded Contexts ein tiefes Fachwissen über die Domäne notwendig ist. Weiterhin sollte das grundlegende Prinzip von Team Topologies nicht vernachlässigt werden, welches Teams anhand der Wertschöpfung aufteilt. Die Notwendigkeit von Teams miteinander zu kommunizieren sollte minimiert werden, um eine lose Koppelung der Software zu gewährleisten. Das bedeutet, dass ein Team zur Umsetzung von Features, also für die Wertschöpfung, so wenig wie möglich auf andere Teams angewiesen sein sollte. Insbesondere die Kommunikation zwischen Stream-Aligned Teams sollte minimal sein.
Wenn es im Rahmen der Software rechtliche Rahmenbedingungen gibt, welche eingehalten werden müssen, dann kann es sinnvoll sein die Software an dieser Stelle zu trennen. So ist es denkbar, dass in einem stark regulierten Markt hohe Datenschutzbestimmungen herrschen und Zugriffe auf Ressourcen protokolliert werden müssen. Es kann in diesem Fall sinnvoll sein Code, in welchem Zugriffe auf Ressourcen protokolliert werden müssen, von anderem Code zu trennen, in welchem eine solche Protokollierung nicht notwendig ist.
Auch die Änderungsfrequenz zwischen verschiedenen Codestellen kann eine Rolle spielen. Wenn es in der Software eine abgrenzbare Domäne gibt, welche sich regelmäßig ändert, dann kann es sinnvoll sein diese in einer eigenen Komponente abzugrenzen und lose gekoppelt neben den Rest des Codes zu legen. Damit nun andere Komponenten nicht ebenfalls angepasst werden müssen, wenn sich diese Komponente ändert, sollte es so wenig Abhängigkeiten auf, die sich schnell ändernde Komponente geben, wie möglich. Sollte es Abhängigkeiten geben, dann ist es sinnvoll das Dependency Inversion Principle zu verwenden, damit Komponenten, welche sich öfter ändern, abhängig von Komponenten sind, welche sich selten ändern, und nicht umgekehrt (Martin, 2017).
Wenn es im Projekt Mitarbeiter gibt, welche remote arbeiten, dann kann dies ein zu berücksichtigender Faktor bei der Teamaufteilung sein. Team Topologies empfiehlt grundsätzlich entweder alle Mitarbeiter ins Büro zu holen oder einen remote-first Ansatz zu verfolgen. Remote-first bedeutet, dass grundsätzlich alle Mitarbeiter remote arbeiten sollen. Sollte sich die Organisation dennoch für einen hybriden Ansatz entscheiden, dann kann es sinnvoll sein, dementsprechend die Teams zu organisieren. Ob Mitarbeiter zusammen in einem Büro arbeiten oder remote, hat einen Einfluss auf dessen Kommunikationswege und auf die Frequenz, mit welcher die Mitarbeiter untereinander kommunizieren. Aufgrund von Conway’s Law hat dies wiederum einen Einfluss auf die Architektur der Software, sodass eine bewusste Einteilung der Teams anhand der Teamverteilung sinnvoll sein kann. Das soll verhindern, dass die eingeschränkten Kommunikationswege es schwieriger machen, die Software entsprechend der gewünschten Architektur umzusetzen. Eine Möglichkeit, um Mitarbeiter die remote arbeiten näher zusammenzubringen könnte Software, wie Work Adventure sein.
Auch unterschiedliche Risikoprofile von Anforderungen können gute Kandidaten für Fracture Planes sein. Angenommen es gibt eine App mit einem Freemium Geschäftsmodell. Das bedeutet, dass die App kostenlos nutzbar ist, aber bestimmte Funktionen erst mit einem Premium Abonnement freischaltet. Nun sei angenommen, dass die meisten Nutzer die kostenlose Version der App verwenden und nur wenige ein Premium Abonnement abgeschlossen haben. Jeder Nutzer der kostenlosen Version ist ein potenzieller neuer Kunde für das Premium Abonnement. Das bedeutet, dass ein Fehler in der Software, welcher die kostenlosen Features der App betrifft, schwerwiegender ist als ein Fehler, welcher in einem Premium Feature auftritt. Denn der Fehler in dem kostenlosen Feature betrifft nicht nur weitaus mehr Nutzer der App, sondern könnte insbesondere die potenziellen neuen zahlenden Kunden verärgern. Das könnte wiederum schlechter für das Geschäft sein als ein Fehler in einem Premium Feature. Aufgrund dessen kann es sinnvoll sein anhand dieser Risikoprofile die Software zu trennen und nur lose zu koppeln, sodass Fehler in dem Code mit niedrigem Risikoprofil keine Auswirkungen auf Code mit hohem Risikoprofil haben.
Die weiteren Fracture Planes werden an dieser Stelle ausgelassen, um den Rahmen des Artikels nicht zu sprengen.
Literaturverzeichnis
Alan MacCormack, C. B. (2011). Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis. Research Policy.
Conway, M. E. (1968). How Committees Invent. Datamation magazine, 28-31.
Dunbar, R. (1992). Neocortex size as a constraint on group size in primates. Journal of Human Evolution.
Evans, E. (2004). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional.
Google. (17. 09 2023). re:Work - The five keys to a successful Google team. Von re:Work - The five keys to a successful Google team: https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team abgerufen
Martin, R. C. (2017). Clean Architecture. Harlow, England: Prentice Hall.
Matthew Skelton, M. P. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. Portland: IT Revolution.
The Standish Group. (17. 09 2023). The CHAOS Report (1994). Von The CHAOS Report (1994): https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf abgerufen