…und wie wir sie mit der integralen Perspektive zum Leben erwecken

Einleitung: Alltag in einem IT-Projekt

Montagmorgen, kurz nach neun. Das Online-Daily beginnt – doch die Stimmung ist schwer. Die meisten Kameras bleiben schwarz, nur wenige Gesichter erscheinen auf dem Bildschirm. Der Product Owner seufzt hörbar, bevor er verkündet, dass das geplante Planning erneut verschoben werden muss. Wieder einmal.

Die Entwickler reagieren kaum. Manche starren stumm in die Kamera, andere nutzen die Zeit, um Mails zu beantworten oder schweifen gedanklich ab. Ein Entwickler meldet sich schließlich zu Wort – genervt: „Wir haben zu viele Themen parallel, ständig wechselnde Prioritäten, dauernd neue Meetings und trotzdem zu wenig Klarheit, worauf wir uns wirklich konzentrieren sollen.“ Einige nicken zustimmend, andere lehnen sich zurück, resigniert.

Auf dem Papier ist dieses Team „agil“: Es arbeitet nach Scrum, hat klare Rollen und nutzt moderne Tools. In der Realität aber zeigen sich Erschöpfung, Unmut und stille Rückzüge. Engagement verwandelt sich in Frust, Energie in Passivität.

Der Scrum Master versucht sein Bestes: moderiert, jongliert zwischen Konflikten, vermittelt zwischen Stakeholdern, motiviert, wo er kann. Doch der Druck steigt, und die Symptome wiederholen sich Woche für Woche.

In solchen Momenten zeigt sich: Was hier fehlt, ist kein weiteres Framework, nicht noch ein Tool, das mehr Transparenz verspricht. Was fehlt, ist ein tieferes Verständnis – dafür, was in einem Team wirklich wirkt, warum Menschen so handeln, wie sie handeln, und was in dieser Situation tatsächlich gebraucht wird.

Zwischen unterschiedlichen Welten: Warum Kommunikation, Zusammenarbeit und Struktur oft nicht zusammenpassen

In IT-Projekten treffen oft Menschen mit ganz unterschiedlichen inneren Landkarten aufeinander. Manche denken in klaren Strukturen, setzen auf Ordnung, Verantwortung und Kontrolle. Andere handeln getrieben von Leistung, Zielorientierung und Wettbewerb. Wieder andere wünschen sich Beteiligung, Teamgeist und Mitverantwortung. Diese Unterschiede sind nicht persönliche Schwächen – sie spiegeln unterschiedliche Entwicklungslogiken und Wertesysteme, die in jeder Organisation nebeneinander existieren.

Wir sprechen selten darüber. Aber wir erleben es täglich: Frust, weil ein Kollege sich nicht einbringt. Misstrauen, weil „das Management eh nicht zuhört“. Enttäuschung, weil Teams trotz guter Methoden kaum selbstverantwortlich handeln. 

Ein weiteres Tool oder Framework wird hier nicht weiterhelfen. Entscheidend ist, unsere Wahrnehmung zu schärfen und wirklich zu verstehen, was in den Köpfen der Menschen, im Zusammenspiel der Teams und in den Strukturen der Organisation wirkt – erst dann können wir gezielt handeln.

Was ist eine integrale Perspektive – und warum brauchen wir sie gerade jetzt?

Die integrale Theorie (u.a. Ken Wilber) bietet eine Landkarte, um komplexe Situationen in ihrer Ganzheit zu verstehen und unpassende Lösungsansätze zu vermeiden. Sie unterscheidet vier Perspektiven oder Quadranten, die alle gleichzeitig wirken und berücksichtigt werden sollten:

• Innen – Individuum: Hier geht es um die innere Welt jedes Einzelnen – Gedanken, Überzeugungen, Sorgen, Wünsche, Motivation und persönliche Haltung. Wenn ein Entwickler beispielsweise frustriert ist, weil er den Sinn einer Anforderung nicht versteht, wirkt das auf seine Energie und die Zusammenarbeit.
• Außen – Individuum: Diese Ebene zeigt das, was wir beobachten können: Verhalten, Fähigkeiten, Leistung, konkrete Beiträge. Hier sehen wir z. B., ob jemand pünktlich ins Daily kommt, wie oft er mitarbeitet, welche Aufgaben abgeschlossen werden oder welche Skills er einbringt.
• Innen – Kollektiv: Hier steckt die gemeinsame „unsichtbare“ Seite des Teams – Kultur, unausgesprochene Regeln, wie Entscheidungen fallen, wie Konflikte ausgetragen werden, welche Rituale gepflegt werden. Man merkt diese Ebene, wenn man sich fragt: „Wie fühlt es sich an, Teil dieses Teams zu sein?“
• Außen – Kollektiv: Das ist die sichtbare Organisationswelt – Prozesse, Rollen, Strukturen, KPIs, Tools. Sie bildet den Rahmen, in dem Teams arbeiten. Hier liegt zum Beispiel fest, wie ein Backlog priorisiert wird, welche Meetings vorgeschrieben sind oder wie Erfolg gemessen wird.

(Quellen zum Vertiefen der Integralen Theorie: deutscher Artikel, englischsprachige Web, Alternative)

Ein integraler Lösungsansatz bedeutet, Probleme und Lösungen nicht nur aus einer einzelnen Perspektive zu betrachten – etwa nur über Prozesse oder Technik –, sondern alle vier relevanten Ebenen mitzudenken. Erst wenn wir Motivation und Haltung der Beteiligten, ihr beobachtbares Verhalten, die Kultur und Dynamiken im Team sowie die bestehenden Strukturen und Prozesse im Zusammenspiel verstehen, können wir nachvollziehen, warum ein Team so handelt, wie es handelt – und Lösungsansätze entwickeln, die wirklich tragen und nachhaltig wirken.

Doch damit bleibt eine wichtige Frage offen: Wie unterscheiden sich Menschen innerlich, und welche inneren Antriebe formen ihr Handeln? Hier kommt Spiral Dynamics ins Spiel — ein Modell, das erklärt, wie Werte, Weltbilder und Motive sich über Entwicklungsstufen entfalten. Spiral Dynamics wurde ursprünglich von Clare W. Graves entwickelt und später von Don Beck & Chris Cowan weitergeführt. In Ken Wilbers integraler Theorie fließen diese Stufen als „Levels“ (Entwicklungsebenen) ein — Spiral Dynamics ist also Teil der integralen Landkarte, nicht getrennt davon. 

Aus meiner Erfahrung begegnen uns in Projektumgebungen besonders oft drei dieser Stufen / Werteorientierungen:

Damit zeichnen sich Chancen und Spannungsfelder ab: Je nachdem, welche Orientierungen dominieren, entstehen unterschiedliche Reibungspunkte – etwa, wenn der Wunsch nach Effizienz und Zielerreichung (Orange) auf das Bedürfnis nach Harmonie und Beteiligung (Grün) trifft, oder wenn Regeln und Prozesse (Blau) als zu starr empfunden werden.

Wichtig ist: Diese drei Orientierungen sind nicht die einzigen. Spiral Dynamics beschreibt insgesamt acht Entwicklungslogiken – von „Beige“ (Überleben, Grundbedürfnisse) über „Purpur“ (Stammeszugehörigkeit, Sicherheit), „Rot“ (Macht, Durchsetzungskraft), bis hin zu „Gelb“ und „Türkis“ (systemisches Denken, globale Perspektive). In IT-Projekten begegnen uns diese höheren Ebenen seltener dominant, sie spielen aber eine Rolle bei strategischen Entscheidungen, in Transformationsprozessen und bei Führungskräften, die komplexe Veränderungen steuern.

Die folgende Grafik zeigt die gesamte Entwicklungsspirale und ordnet die verschiedenen Ebenen ein:

Was das für unsere Arbeit bedeutet

• Echte Veränderung beginnt, wenn wir die Landkarte der Beteiligten kennen und sie Schritt für Schritt mitnehmen.
• Wir brauchen Bewusstsein darüber, wie Prozesse, Rollen, Tools und Erwartungen auf unterschiedlichen Stufen der Werteorientierung wirken.
• Wir müssen lernen, für jede Situation das passende Vorgehen zu wählen – nicht dogmatisch, sondern differenziert.

Praxisbeispiel 1: Frustrierte Entwickler im Team

Ein Entwicklerteam fühlt sich ausgebremst: Anforderungen ändern sich ständig, viele Aufgaben landen erst sehr spät im Sprint-Backlog. Die technische Entkopplung ist noch unzureichend, wodurch eine starke Abhängigkeit von anderen Teams entsteht. Gleichzeitig ist die Zusammenarbeit mit diesen Teams schwierig. Das Ergebnis: wachsende Frustration, Rückzug, zynische Kommentare – und mitunter stille Formen von Widerstand.

Möglicher Lösungsansatz für Führungskräfte und Agile Masters:
Statt nur Symptome zu managen, lohnt sich ein systematischer Blick durch die vier Perspektiven der integralen Theorie:

• Mapping der vier Quadranten: Gemeinsam mit dem Team wird sichtbar gemacht, wo die Hauptursachen liegen:
  • Außen – Individuum: Welche Verhaltensweisen oder Skills fehlen, um die Aufgaben zu bewältigen?
  • Außen – Kollektiv: Welche Prozesse oder Schnittstellen erzeugen Reibung?
  • Innen – Individuum: Welche Sorgen oder Motivationslücken lähmen die Beteiligten?
  • Innen – Kollektiv: Welche unausgesprochenen Teamregeln oder Konflikte blockieren Vertrauen?

Dieses Mapping kann z. B. auf einem Whiteboard oder in Miro entstehen und führt zu einer gemeinsamen Diagnose: „Aha, 70 % unserer Probleme liegen in den Prozessen, 20 % in der Kultur, 10 % in fehlenden Skills.“ – so entsteht Klarheit, wo man ansetzen sollte.

• Gezieltes Team-Setting schaffen: Mit den Ergebnissen aus dem Mapping können moderierte Formate folgen: Retrospektiven mit Fokus auf Vertrauen, Feedback-Loops mit benachbarten Teams, klar definierte Pull-Prinzipien für Arbeitspakete. Ziel: echte Kommunikation und Verlässlichkeit wiederherstellen.
  
• Führungskräfte einbinden: Führung wird nicht außen vor gelassen, sondern nutzt die Ergebnisse des Mappings, um Entscheidungen zu beschleunigen, Prioritäten zu klären und den Teams mehr Handlungsspielraum zu geben.

Praxisbeispiel 2: Manager zwischen Druck und Delegation

Ein Bereichsleiter möchte mehr Verantwortung ins Team geben. Gleichzeitig steht er selbst unter starkem Ergebnisdruck, muss viele Stakeholder bedienen und Prioritäten ständig anpassen. Operative Themen gibt er ab – doch aus Sicht des Teams wirkt das wie Rückzug. Das Team sieht nur, was der Bereichsleiter tut (Außen – Individuum), versteht aber nicht, warum er so handelt (Innen – Individuum). Dadurch entsteht Verunsicherung, das Gefühl mangelnder Orientierung und in manchen Momenten sogar der Eindruck, allein gelassen zu sein.

Integraler Lösungsansatz:
Die integrale Perspektive hilft, den Blick zu erweitern und die Innenwelt des Bereichsleiters sichtbar zu machen:

• Innen – Individuum: In vertraulichen Gesprächen werden die Sorgen, Zwänge und Erwartungen, die auf dem Bereichsleiter lasten, bewusst gemacht. Was bräuchte er selbst, um Verantwortung wirklich loslassen zu können?
  
• Außen – Kollektiv: Auf Basis dieser Klarheit werden Entscheidungsräume definiert – z. B. mit Delegation Poker, einer RACI-Matrix oder klaren Working Agreements. So weiß das Team genau, wo es selbstständig agieren darf und wann eine Abstimmung nötig ist.
  
• Innen – Kollektiv: Regelmäßige Feedback-Runden zwischen Führung und Team geben Raum, nicht nur Ergebnisse, sondern auch Erwartungen, Wahrnehmungen und Unsicherheiten anzusprechen – ein wichtiger Schritt zu gegenseitigem Vertrauen.

Der Mehrwert: Das Team versteht nicht nur, was entschieden wird, sondern auch, warum bestimmte Entscheidungen so fallen. Das stärkt Vertrauen, gibt Orientierung und schafft ein Umfeld, in dem Delegation tatsächlich Wirkung entfaltet.

Erste Schritte, die du gehen kannst

• Beobachte in deinem Umfeld: Wo zeigen sich Spannungen, die nicht durch Verhalten erklärbar sind, sondern durch unterschiedliche Logiken?
• Frage dich in Meetings oder Retros: Welche Quadranten sprechen wir gerade an – und welche blenden wir aus?
• Teste bewusst neue Formate, z.B. integrale Check-Ins oder Vier-Quadranten-Reflexionen im Team, um gemeinsam tiefer zu schauen.
• Und vor allem: Sprich mit Kollegen, Vorgesetzten, Partnern – nicht nur über das Was, sondern über das Warum. Das öffnet neue Räume.

Einladung zum Mitdenken und Mitgestalten

Dieser Artikel ist Teil einer kleinen Serie zu integralen Ansätzen für Transformation, Coaching und Teamarbeit. Im nächsten Beitrag möchte ich zeigen, wie man Tools, Methoden und Frameworks integraler auswählt – also nicht pauschal nach Trend, sondern bewusst nach der Logik und Orientierung der Teams und den für sie passenden nächsten Schritt.

Johannes Uske

Agile Master

Johannes ist ein erfahrener Agile Coach. Er bringt umfassende Erfahrungen in Transformationen, Scrum, SAFe und Teamentwicklung in den Bereichen IT, Konsumgüter, Banking und Automobil mit. Sein Fokus liegt auf praxisnahen Trainings, Führungskräfte-Coaching und systemischer Beratung, die nachhaltige Veränderungen und Selbstorganisation fördern. Durch den Einsatz partizipativer Methoden beseitigt er Blockaden und steigert den Teamerfolg. Johannes legt besonderen Wert auf psychologische Sicherheit, Produktqualität, Kundenzufriedenheit, Wertschätzung und kontinuierliche Verbesserung – und stärkt so Teams, um ihre Kollaboration zu optimieren.

j.uske@atra.consulting    

Während Agilität mit dem de-facto Standard Scrum auf Teamebene oftmals relativ leicht umzusetzen ist, stellt Skalierung der agilen Vorgehensweisen Organisationen regelmäßig vor größere Herausforderungen. Viele Frameworks wie etwa SAFe oder LeSS liefern interessante und gute Ansätze hierfür. Jedoch scheitern Organisationen regelmäßig bei der Einführung dieser, aufgrund heterogener Teams, Anforderungen und Produktlandschaften. So ist beispielsweise ein Team, welches den Checkout-Prozess eines Onlineshops verantwortet, ganz anders zu betrachten als das Team, welches die interne Cloudplattform oder einen Data Lake entwickelt. Jedes dieser Teams hat unterschiedliche Anforderungen an eine teamübergreifende Planung und Zusammenarbeit. Aufgrund der abweichenden Herausforderungen benötigt es ein anpassbares Vorgehensmodell. 

Die Strukturierung und Interaktion von Teams ist eine der größten Herausforderungen in agilen Organisationen. Besonders in der IT müssen Teams häufig komplexe Aufgaben bewältigen und dabei flexibel bleiben. Matthew Skelton und Manuel Pais bieten mit ihrem Buch „Team Topologies“ eine klare Methode, wie Teams organisiert und ihre Schnittstellen gestaltet werden können, um Effizienz, Zusammenarbeit und Anpassungsfähigkeit zu maximieren.

Die Grundidee hinter Team Topologies

• Klare Verantwortlichkeiten: Jede Teamkategorie hat definierte Ziele und Aufgaben, was den Fokus und die Effizienz erhöht. 
• Verbesserte Zusammenarbeit: Gut durchdachte Kommunikationswege und Schnittstellen reduzieren Missverständnisse. 
• Schnelle Anpassung: Enabling-Teams helfen anderen Teams, neue Technologien oder Methoden schneller einzuführen. 
• Optimierte Ressourcennutzung: Plattform-Teams schaffen gemeinsame Infrastruktur, damit sich andere Teams auf ihre Kernaufgaben konzentrieren können.

Auf diese Weise soll der Ansatz der Teamkategorien eine praxisnahe und flexible Methode bieten, um skaliertes Agilitätsmanagement in komplexen Organisationsstrukturen zu implementieren und nachhaltig zu verankern.

In kurzen Worten: Team Topologies soll die Entwicklung von Organisationen im Laufe der Zeit unterstützen, wann immer sich die Bedingungen ändern. 
Moderne Organisationsprinzipien werden gefördert und Softwareanpassungen können schneller umgesetzt werden. In der Realität bleibt es bei der immer gleichen Herausforderung, den Teams dafür entsprechend Zeit zum Testen & Lernen einzuräumen.

Schauen wir uns das Konzept in der notwendigen Tiefe an, um zu erfahren, wie diese Konzepte auch in den eigenen Teams angewendet werden könnten: 

Inhalt:

1. Conway’s Law
2. Team First
3. Vier grundlegende Topologien
4. Team-Interaktionsmodi
5. Organisatorisches Gespür
6. Topologieentwicklung
7. Team-API

1. Conway’s Law

Conway’s Law besagt:

»Jede Organisation, die ein System entwirft, wird zwangsläufig einen Entwurf erstellen, der eine Kopie ihrer Kommunikationsstruktur ist.« 

Anders formuliert: Die Organisationsstruktur und die Kommunikationswege zwischen den Teams spiegeln sich direkt in der Systemarchitektur wider. Ein einfaches Beispiel dazu zeigt die folgende Grafik.

Während Conway’s Law oft als reine Beobachtung beschrieben wird, geht der Ansatz von Team Topologies einen Schritt weiter: Es wird als aktives Gestaltungsprinzip verstanden. Anstatt zu akzeptieren, dass die Architektur die bestehenden Teamstrukturen widerspiegelt, lassen sich Teams gezielt so gestalten, dass sie eine gewünschte Architektur aktiv fördern.

Möchte man beispielsweise eine modulare, lose gekoppelte Architektur, sollten die Teams entsprechend strukturiert werden. Dies gelingt durch den Aufbau autonomer, funktionsübergreifender Teams sowie durch die Etablierung klarer Schnittstellen und definierter Verantwortlichkeiten. Dieses Prinzip wird als Inverses Conway’s Law bezeichnet. In unserem Projektalltag begegnen wir diesem Phänomen immer wieder.

Ein Beispiel aus der Praxis: Selbst sehr erfahrene Entwickler entwerfen zum Teil monolithische, fehleranfällige Strukturen – nicht aufgrund mangelnden Könnens, sondern weil:

• Architekturbausteine mit zu viel Funktionalität überladen werden, da Entwickler in diesen Bereichen besonders vertraut sind.
• Hoher Lieferdruck führt dazu, dass eigentlich isolierte Funktionalitäten schnell in bestehende Strukturen integriert werden, statt sauber gekapselt zu werden.

Ob traditionelles oder inverses Conway’s Law: Das „Störgefühl“, wenn die Softwarearchitektur nicht mehr zur Teamstruktur passt, kennt fast jeder. Sich dieses Zusammenhangs bewusst zu sein, ist der erste Schritt, um sowohl die Architektur als auch die Organisation gezielt weiterzuentwickeln.

(Mehr dazu hier: Conway´s Law – EN  / Conway´s Law DE)

2. Team First

Bei Team Topologies wird ein Team als eine stabile Gruppe von Menschen betrachtet, die am gleichen Ziel arbeiten. Verantwortlichkeiten werden keinen Einzelpersonen zugewiesen, sondern Teams.

Die Anzahl der Teammitglieder ist entscheidend, um Vertrauen zu bilden. Ein effektives Team umfasst laut Team Topologies 7 bis 9 Personen. 

Bis eine einigermaßen geschlossene Einheit entsteht, dauert es bis zu drei Monate. Es ist kaum sinnvoll, Teams nach Abschluss eines Projekts, an dem sie ein halbes Jahr gearbeitet haben, neu zu strukturieren. Die emotionale Anpassung an die Arbeitsgewohnheiten und Sichtweisen neuer Kollegen hat einen gravierenden Einfluss auf die Leistung. Nur wenn das Vertrauen in eine Organisation hoch ist, ist ein Teamwechsel einmal im Jahr ohne negative Auswirkungen möglich.

Die Autoren betonen, dass es wichtig ist, die kognitiven Fähigkeiten des Teams zu maximieren, durch die Verbesserung der Arbeitsumgebung, des Führungsstils und die Minimierung von Ablenkungen.

Diese Ansicht wird bereits in vielen bekannten Team-Konstellationen angewandt, wie beispielsweise in Projektteams, Enabling oder Transformationsteams. Die Vorteile von Teams mit klarem Fokus ohne Ablenkungen von “außen” sind nicht von der Hand zu weisen. 

John Sweller bezeichnet Kognitive Belastung mit: „Die Gesamtmenge an geistiger Anstrengung, die im Arbeitsgedächtnis aufgewendet wird.“

Drei Arten der kognitiven Belastung werden benannt:

• Intrinsische kognitive Belastung – bezieht sich auf die Faktoren, die für die Lösung der Aufgabe bedeutend sind. Beispiel: Wie kreieren wir eine neue Methode?
• Externe kognitive Belastung – bezieht sich auf die Voraussetzungen, in der die Aufgabe ausgeführt wird. Beispiel: Wie konfigurieren wir diesen Service?
• Lernbezogene kognitive Belastung – bezieht sich auf Inhalte, die erlernt werden müssen, um die Aufgabe zu lösen. Beispiel: Wie funktionieren Bank Transfers?

Mehr dazu hier: Cognitive Load Theory – DE.

Team Topologies spricht davon, die Verantwortlichkeit des Teams so zu beschränken, dass es die maximale kognitive Belastung des Teams nicht überschreitet.

Aus unserer Sicht wird es entscheidend sein, wie viel Zeit den Teams eingeräumt wird, um zu lernen, wie alltägliche Herausforderungen gemeistert werden, ohne die maximale kognitive Belastung zu überschreiten. Der Lieferdruck auf Teams und das Problem, dauerhaft an zu vielen Aufgaben parallel zu arbeiten, macht evident, wie wichtig es ist, in den Teams zu lernen, die Verantwortlichkeiten klar zu definieren und zu beschränken.

 Das Lernen im Tagesgeschäft  “nein” zu sagen, erweist sich unter hohem Lieferdruck, meist als nicht überwindbares Unterfangen und wird selten vom Management in Drucksituationen akzeptiert. Die Akzeptanz auf Managementebenen ist aber maßgeblich, um die Theorie auch in der Praxis umsetzen zu können. Hier zeigt sich für uns klar, dass die gesamte Organisation “lernen” muss.   

Eine Möglichkeit könnte der Team-First-Ansatz sein. Durch den Team-First-Ansatz soll Mitarbeitern die Möglichkeit gegeben werden, in einer Organisation erfolgreich zu sein. Anstatt ein dickes Fell oder Belastbarkeit zu benötigen, um in einer Organisation zu überleben, haben Mitarbeiter in einer Team-First-Organisation den Raum und die Unterstützung, ihre Fähigkeiten und Praktiken zu entwickeln.

3. Die vier grundlegenden Teamtopologien

Es gibt sehr viele Teamtypen in Organisationen. Der Einfachheit wegen werden diese auf vier Haupttypen reduziert. Diese betrachten das Verhalten und die Fähigkeiten der Teams und lauten wie folgt:

Stream-aligned Team: Das Team, das auf die Geschäftsveränderung ausgerichtet ist, mit einem funktionsübergreifenden Kompetenzmix und der Fähigkeit, signifikante Inkremente zu liefern, ohne auf ein anderes Team warten zu müssen.

Enabling-Team: Das Team, das andere Teams bei der Einführung und Änderung von Software im Rahmen einer Übergangs- oder Lernphase unterstützt.

Complicated-subsystem Team: Das Team mit einer besonderen Aufgabe für ein Subsystem, das zu kompliziert ist, als dass es von einem normalen Stream-ausgerichteten Team oder Plattformteam bearbeitet werden könnte. Optional und nur dann verwendet, wenn es wirklich notwendig ist.

Plattform Team: Das Team, das an der zugrunde liegenden Plattform arbeitet und Stream-ausgerichtete Teams bei der Bereitstellung unterstützt. Die Plattform vereinfacht komplexe Technologie und reduziert die kognitive Belastung für Teams.

Nehmen wir hier nochmal als Beispiel ein klassisches Unternehmen aus dem e-Commerce Bereich:

• Ein Stream-aligned Team könnte den gesamten Checkout-Prozess des Onlineshops verantworten, einschließlich der Integration neuer Payment-Dienstleister und der UX-Optimierung.
• Das Unternehmen möchte verstärkt die Vorteile der Cloud-native Entwicklung nutzen. Ein Enabling Team könnte hierbei bei der Einführung der Technologie und notwendigen Architekturmuster helfen, beispielsweise durch Schulungen, Bereitstellung von Prototypen oder Definition von Architekturpattern.

• Als complicated-subsystem-Team entwickelt eine Gruppe von Spezialisten einen hochspezialisierten Empfehlungsalgorithmus, welcher Kundinnen und Kunden passgenaue Produktempfehlungen zur Verfügung stellt.
• Unser fiktives Unternehmen hat direkt zwei Plattform-Teams, welche zum einen die interne Developer-Cloudplattform und zum anderen einen Unternehmensweiten Data-Lake zur Verfügung stellen.

4. Team-Interaktionsmodi 

Ineffektivität wird in vielen Organisationen durch schlecht definierte Interaktionen verursacht. Laut TeamTopologies läuft die Beziehung zwischen den Teams auf zwei Dinge hinaus: Wird durch die Zusammenarbeit mit einem anderen Team ein Ziel erreicht oder bietet es dem Team einen Service an. Auf diese Weise werde drei Möglichkeiten festgelegt, wie Teams interagieren können:

Zusammenarbeit enge Zusammenarbeit mit anderen Teams. Dies ist besonders nützlich, wenn Teams neue Technologien oder Techniken erforschen. Die Zusammenarbeit ermöglicht die schnelle Entdeckung neuer Dinge, da kostspielige Übergaben vermieden werden. Am besten verwendet, wenn ein hohes Maß an Anpassungsfähigkeit zwischen zwei Teams erforderlich ist.

X-as-a-Service etwas mit minimaler Zusammenarbeit nutzen oder bereitstellen.
Dieser Interaktionsmodus kann die Liefergeschwindigkeit erhöhen. Team A braucht etwas, um seinen Wert zu liefern, Team B hat eine Dienstleistung ohne großen Aufwand bereitgestellt. Es sind keine langwierigen Gespräche, Besprechungen oder Vorbereitungen erforderlich.

Unterstützen: Einem anderen Team helfen und umgekehrt, Hindernisse zu beseitigen. Der unterstützende Interaktionsmodus eignet sich am besten in Situationen, in denen ein Team die Hilfe eines anderen benötigt. Das Enabling Team versetzt zum Beispiel ein anderes Team in die Lage, effektiver zu sein, schneller zu lernen, eine neue Technologie besser zu verstehen oder Hindernisse zu entdecken und zu beseitigen.  Domain-Driven Design kann hier ein gutes Hilfsmittel sein.

5. Organisatorisches Gespür

Mit “Organisatorisches Gespür” ist gemeint: die Situation zu erkennen und anzupassen. Unternehmen müssen flexibel sein, um sich an Veränderungen anzupassen. Dazu gehört die Anpassung der Struktur und Abläufe. Eine Organisation sollte in der Lage sein, die richtigen Teamstrukturen und Interaktionsmodi anzuwenden.

Woran erkennt man also, dass eine Organisation sich weiterentwickeln muss?

1. Die Software wird für ein Team zu komplex. Während am Anfang jeder ein umfassendes Verständnis davon hat, was vor sich geht, wird das immer schwieriger. Dadurch verlagert sich der Fokus von echten Prioritäten auf den Versuch, Leute zu finden, die kompetent genug sind, um ein bestimmtes Problem zu lösen.
2. Die Lieferfrequenz verlangsamt sich. Die Teammitglieder sehen, dass eine Lieferung mehr Zeit und mehr Schritte erfordert. Um dies zu vermeiden, müssen Teams autonom sein und dürfen nicht darauf warten, dass andere Teams eine neue Infrastruktur erstellen.
3. Mehrere Geschäftsdienste basieren auf einer großen Anzahl zugrunde liegender Dienste. In einigen Sektoren wie Finanzen, Versicherungen, Regierung usw. können hochrangige Dienste auf Dienste auf niedrigerem Niveau angewiesen sein. Die Lösung könnte darin bestehen, die Dienste auf niedrigerer Ebene zu “plattformisieren” und für jeden Dienst auf hoher Ebene Stream-ausgerichtete Teams einzusetzen.

Hier spricht man von der Kompetenz der OrganisationswahrnehmungDies ist die Fähigkeit, die Organisationsituation so zu erfassen oder zu spüren, dass das Überleben der Organisation sichergestellt wird. Einige der Dinge, die eine Organisation „spüren“ muss, sind:

• Müssen die Teaminteraktionsmodi geändert werden?
• Was behindert den Arbeitsfluss für ein bestimmtes Team?
• Sollen wir ein bestimmtes Tool bauen oder können wir es von einem Anbieter bekommen?

Es gibt nicht wenige Systeme, die über viele Jahre hinweg entstanden sind. Diese Systeme haben Abhängigkeiten, die nicht außer Acht gelassen werden können. Die Teaminteraktionsmodi passen sich an das System an und nicht umgekehrt. Die Frage, die sich stellt, ist: Was kann oder muss ich tun, um die Komplexität des Systems zu verringern, damit die Vorteile der Teaminteraktionsmodi zum Tragen kommen, und ist dies aufgrund der Größe des Systems überhaupt möglich?

6. Topologieentwicklung

Sobald eine Organisation auf neue Herausforderungen reagiert, ist davon auszugehen, dass Teams untereinander anders als zuvor interagieren werden.

Dies kann bedeuten, dass Teams neu strukturiert oder neu zusammengesetzt werden, um spezifische Probleme anzugehen oder neue Technologien zu implementieren. Gleichzeitig können sich die Arbeitsabläufe und Prozesse ändern, um die Zusammenarbeit zwischen den Teams zu verbessern. Das übergeordnete Ziel besteht darin, sicherzustellen, dass die Teams flexibel genug sind, um sich an veränderte Anforderungen anzupassen, und dass ihre Interaktionen effektiv sind, um die Ziele der Organisation zu erreichen. Dies erfordert eine kontinuierliche Bewertung und Anpassung der Teamstrukturen und -interaktionen im Einklang mit den sich ändernden Anforderungen und Zielen der Organisation.

7. Team-API 

Eine Beschreibung der Interaktionen mit dem jeweiligen Team: Code, Versionierung, Wiki und Dokumentation, Praktiken und Prinzipien, Kommunikation, Arbeitsinformationen und einiges mehr. Ziel ist es, anderen Teams transparent und in einem einfachen Überblick zu zeigen, an was, wie, mit wem, das Team arbeitet. Ein gutes Beispiel für eine Team API hat Team Topologies selbst auf Github.com veröffentlicht.

Zusammenfassung

Die sieben Grundideen von Team Topologies bieten Vorteile, die die Effektivität der Teamarbeit in Unternehmen steigern können. 

Die Fähigkeit zur Flexibilität und Anpassungsfähigkeit, denn durch die Strukturierung von Teams können Unternehmen schnell auf Veränderungen reagieren und neue Anforderungen integrieren. 

Das Übertragen von Verantwortlichkeiten an eigenständige Teams fördert die Autonomie und Eigenverantwortung, beschleunigt die Entscheidungsfindung und fördert agile Reaktionen auf Herausforderungen (siehe 3. Grundidee), wenn das Management mit einbezogen wird und Verantwortung an die Teams weitergibt.
Ferner ermöglicht Team Topologies die Bildung hochspezialisierter Teams, die sich auf bestimmte Aufgaben oder Technologien konzentrieren können, die Entwicklung von Expertise fördert und die Effizienz steigert. 

Teams dieser Art gibt es bereits zuhauf in Organisationen. Die große Herausforderung sind die Abhängigkeiten der Teams, des Produkts und nicht zuletzt, wie viel Zeit den Teams eingeräumt wird, um zu wachsen und die Fähigkeiten zu entwickeln, die es benötigt. 

Wenn spezialisierte Teams in ihren eigenen Bereichen isoliert arbeiten und den Informationsaustausch behindern, können Kommunikationsbarrieren entstehen. Das Entstehen von Silos innerhalb des Unternehmens, wenn einzelne Teams isoliert arbeiten und der Gesamtüberblick über Projekte verloren geht, steigt.
Dies kann die Synergien zwischen den Teams behindern und die Effizienz beeinträchtigen. Zudem kommt die zunehmende Komplexität und der Koordinationsaufwand, wenn eine Vielzahl spezialisierter Teams gleichzeitig agiert. Eine klare Fokussierung auf gemeinsame Ziele kann dieses Problem mindern. Hierbei könnten sich die Vorgehensweisen von Team Topologies als klarer Vorteil erweisen. Zwar sind nicht alle Ideen von Team Topologies neu, jedoch ermöglicht die globale Sicht auf die Teams eine einheitliche strategische Ausrichtung und ein gemeinsames Vokabular für IT-Projekte. 

Zusammenfassend hier eine Kurzübersichtskarte: QRC Team Topologies

Herausforderungen bei der Umsetzung

Die Theorie von Team Topologies ist vielversprechend, aber wie bei jedem Ansatz gibt es auch Herausforderungen:

• Management-Unterstützung: Ohne ein Management, das die Prinzipien von Autonomie und psychologischer Sicherheit versteht und fördert, wird es schwer, die Teams nachhaltig zu etablieren. Ein Führungsstil der Haltung “Servant Leadership” ist eine Grundvorraussetzung für den Erfolg und die Produktivität der Teams.
• Silos und Abhängigkeiten: Oft arbeiten Teams isoliert voneinander. Hier braucht es gezielte Interaktionsmodi, um Synergien zu fördern.
• Zeit und Ressourcen: Teams benötigen Raum und Zeit, um ihre Arbeitsweisen zu entwickeln und zu verbessern. Teams müssen mit entsprechenden Personen besetzt und “ausgebildet” werden. Dies wird häufig unterschätzt.

Schlussfolgerung und Einladung zur Diskussion zur Verbesserung ihrer Teams Team Topologies bietet eine mächtige Grundlage, um Teams effektiver, autonomer und besser miteinander vernetzt zu gestalten. Die Implementierung erfordert jedoch eine bewusste Anpassung an die jeweilige Organisation und ein Management, das diese Ansätze aktiv unterstützt.  

Diskussionsfragen an den Leser: 

• Wie sieht es bei Euch im Unternehmen aus? Welche Erfahrungen haben Sie mit der Strukturierung von Teams gemacht, und welche Ansätze haben bei Ihnen besonders gut funktioniert?
• Wie können Organisationen sicherstellen, dass ihre Teamstrukturen nicht nur effizient, sondern auch anpassungsfähig sind?
• Welche Herausforderungen sehen Sie bei der Implementierung der vier Teamarten in Ihrem eigenen Umfeld?

Kaschef Yawar

Geschäftsbereichsleitung »Handel« Prokurist

Kaschef Yawar ist ein erfahrener agiler Coach und Berater mit über 15 Jahren Erfahrung in der IT-Branche. In seinen Rollen als Scrum Master, Agiler Coach und Trainer hat er erfolgreich agile Methoden in verschiedenen Unternehmen und auf unterschiedlichen Ebenen eingeführt und begleitet. Sein Fokus liegt dabei hauptsächlich auf Scrum und Kanban, sowie der Arbeit in skalierbaren Frameworks wie SAFe, LeSS und Nexus. Besonders wichtig ist ihm die wertgetriebene Entwicklung, bei der er stets darauf achtet, dass die entwickelten Produkte und Dienstleistungen einen echten Mehrwert für die Kunden schaffen.

k.yawar@atra.consulting    

• LinkedIn

In unseren Projekten stehen wir immer wieder vor der Fragestellung, wann man denn nun eigentlich welche Methode einsetzen soll, also wann eher agil / Scrum und wann eher klassisch / Wasserfall zum Einsatz kommt. Wir möchten uns an dieser Stelle bewusst nicht an der leider meist ideologisch geführten Debatte um das vermeintlich bessere Vorgehensmodell beteiligen. Wie an anderer Stelle bereits festgestellt, braucht es manchmal »einen Hammer und manchmal einen Schraubendreher«. Und genauso, wie man sich für ein Werkzeug anhand gewisser Eigenschaften der Problemstellung (»Schraube oder Nagel in die Wand«) entscheidet, sollte man auch die Entscheidung für die einzusetzende Methode anhand der Eigenschaften des Umsetzungsvorhabens treffen.

Klingt logisch, aber so ein Entwicklungsprojekt weist ja nun eine Menge Eigenschaften auf. Es hat einen Anfang und ein Ende, es gibt vielleicht schon eine Zielarchitektur oder zumindest eine Vorstellung davon, evtl. stehen die Mitarbeiter oder der Entwicklungspartner schon fest und aufgrund dessen häufig auch schon die Technologie, etc. An welcher Eigenschaft entscheidet sich nun die Methode?

Unserer Erfahrung nach ist die Art des Problems, für dessen Lösung die Software erstellt werden soll, das definierende Kriterium für die entsprechende Entwicklungsmethodik: handelt es sich um ein kompliziertes Problem, so empfiehlt sich eher ein klassisches Vorgehen, bei komplexen Problemstellungen hingegen die agile Herangehensweise.

Sagt sich leicht, aber wir haben zugegebenermaßen einige Zeit und Diskussionen gebraucht, um zu einer entsprechenden Semantik der beiden häufig, aber vermutlich seltener trennscharf verwendeten Wörter »komplex« und »kompliziert« zu kommen.

Komplex ist ein Problem, wenn es viele und insb. unbekannte Größen aufweist. Je näher man an den Kunden kommt, desto komplexer wird es in der Regel. Wir finden dann häufig nicht oder nur schwer berechenbare Situationen vor: wer weiß schon, wie der Kunde sich Morgen verhält? Die Aufgabe einer Stewardess an Bord eines Airbus ist bspw. eine komplexe Aufgabe, da sich nicht vorhersagen lässt, wie sich welcher Passagier in der Luft an Bord verhalten wird und was er dann bspw. trinken möchte. Das »Problem« wird in diesem Fall durch hingehen, fragen und verstehen gelöst, also grundsätzlich eher explorativ.

Eine komplizierte Problemstellung weist viele Variablen auf, die aber (weitestgehend) bekannt bzw. zu ermitteln und somit berechenbar sind. Hier befinden wir uns häufig in Situationen mit vielen Abhängigkeiten, Systemen und Schnittstellen. Hierbei sollte dann aber auch eher analytisch an die Aufgabenstellung gegangen und sich die Berechenbarkeit zunutze gemacht werden: ein Airbus wird dann doch (glücklicherweise!?) eher mit klassischen Vorgehensweisen gebaut.

Weitere interessante Ansätze zur Definition von komplex und kompliziert finden sich bspw. im KULTURMANAGEMENT BLOG.

Zurück zur Softwareentwicklung, am Beispiel E-Commerce: Je näher wir mit unserem Vorhaben also »an« den Kunden, bspw. in Richtung Frontend kommen, desto mehr spricht in der Regel für eine agile Entwicklungsmethode, da wir hier oft auch eine unklare Anforderungssituation vorfinden. Bewegen wir uns mit der zu lösenden Problemstellung eher in Richtung Backend und haben es mit vielen (bekannten) Schnittstellen und Systemen zu tun, dann kann eine klassische Vorgehensweise angebrachter sein.