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.