Team Topologies II - Defining Streams

Team Topologies - Recap: Teil I

Team Topologies bietet eine Heuristik um Flow in Streams of change zu optimieren.

Der team first approach soll den cognitive load der Entwicklungsteams auf die Themenbereiche konzentrieren, die über den ausgelieferten Wert entscheiden. Tiefe Kenntnis der Kund:innendomäne und technische Exzellenz in der Breite sind zentral. Während für diese Bereiche Enabling und das Facilitating das Wissen in das Team tragen können, wird die Entlastung von organisatorischen und basistechnischen Aufgaben durch ein von einem Platform Team bereitgestelltes Produkt aus Sicht der Stream Aligned Teams via API Kommunikation in wichtigen Teilen externalisiert. Die Teams optimieren sich selbst, in dem sie die eigene Expertise mit der gestellten Aufgabe in Deckung bringen und die jeweils angemessene Kommunikationstiefe und -art wählen, die die Zusammenarbeit zwischen Teams maximal reibungsarm hält. Dabei reden wir über ein "work in progress". Team Topologien sollen sich dynamisch entwickeln.

TT II: Management-Buy-in und differenzierte IT

Team Topologies lebt bottom up, ist (so mag man die Zwischentöne im Buch interpretieren) nach Sicht der Autor:innen Pais und Skelton allerdings auf Impulse von Entscheider:innen und Expert:innen angewiesen. Ohne Unterstützung aus dem C-Level, das die Aufgabe "Optimierung im etablierten Geschäftsprozess" als Ziel ausgibt oder mindestens Rückendeckung dafür gibt, kann der Eingriff des neuen Konzepts in die Silostruktur klassischer Unternehmensorganisation nicht erfolgreich sein. U-Boot-Konzepte, die etwa bei der Einführung von Scrum-Prozessen erfolgreich verlaufen, sind nicht die Sache von Pais und Skelton. Sie propagieren ihr Konzept mit breiter Brust für die gesamte IT großer Unternehmen und die mit Ihnen auf Auftrageber:innen und Nutzer:innen zusammenarbeitenden fachlichen Professionen. Team Topologie ist keine Veranstaltung für Startups.

Das Konzept der Team Topologie spiegelt die Geschichte der Autor:innen, haben sie es doch als erfahrene IT-Kollegen aus der DevOps-Praxis entwickelt. Als Verantwortliche für große zentrale IT-Systeme haben Skelton und Pais unmittelbar erfahren, dass die klassische Arbeitsteilung zwischen feature-liefernden Teams und Business as Usual Teams einerseits und codenden Entwickler:innen und Architekt:innen andererseits in hoch effizienten Produktionssystemen keine sinnvollen Antworten auf die sich schnell verändernde Umwelt dieser IT-Systeme liefern konnte. Sie haben ihre Erfahrungen systematisiert und die entscheidenden Elemente aus Technik, Prozess und fachlicher Organisation für die Effizienzsteigerung zusammengetragen. Sie zielen dabei auf größere Unternehmen mit differenzierter IT und etablierten Geschäftsmodellen.

Der Fokus auf erfolgreiche Unternehmen und den produktiven Kern der sich weiter ausdifferenzierenden IT-Industrie scheint vielversprechend: Ähnlich (nicht: gleich!), wie in der Welt der materiellen Produktion das Mindset und die daraus entstandenen organisatorischen Innovationen der Lean Production bei Toyota, die hergebrachten, starren, pufferorientierten Produktionsschemata der US-amerikanischen und europäischen Automobilindustrie durch eine Effizienzrevolution zur Anpassung zwangen, könnte die Team Topologie für einen vergleichbaren Schub in der Softwareentwicklung stehen. Wenn in der materiellen Produktion der Verzicht auf Verschwendung und Puffer der "klassischen Produktion" diametral entgegenstand, werden in der immateriellen Produktion von Software u.a. mit dem Topos "Redundanz ist ok" die bisherigen Logiken der Softwareentwicklung ähnlich frontal herausgefordert.

Ähnlich wie dort, lassen sich hier organisatorische Fragen und technische Hearausforderungen zusammen denken und zu Neuem wenden. Ob die These einer Industrialisierung der IT hier hilfreich ist oder eher von einer Differenzierung durch Automatisierung gesprochen werden muss, können wir hier nicht klären. Auf welche Entwicklung Team Topologie aktuell und in Zukunft einzahlt, müssen wir auf spätere Beiträge vertagen, auf die unvermutet große Reichweite dieses technischen Optimierungsansatzs wollen wir gleichwohl verweisen.

Horizonte und Team Topologie

Team Topologies optimiert flow und speed bei der Softwareentwicklung, d.h. die Menge und Qualität der pro Zeiteinheit ausgelieferten Software. Dieses Ziel domiert typischerweise in bereits etablierten Unternehmen. Es ist kein Konzept für Miniunternehmen oder Unternehmen in der Startphase, denen es auch bei der eingesetzten Software zuvorderst um das Erzielen von Effekten gehen muss. Vielmehr sollte mindestens die Expansionsphase im Unternehmen erreicht sein, in welcher die Optimierung von Inputs, also das Erreichen von Effizienz beim Auswerten der wirtschaftlichen Gelegenheiten im Vordergrund steht. Auch Geschäftsmodelle in der Reifephase, bei denen die Optimierung in allen Wertschöpfungsbereichen betrieben werden muss, bietet sich die auf Effizienz im Flow ausgerichtete Team Topologie an.

Verkürzend stellen wir fest: Die Wirkkraft der Team Topologien ist vermutlich dort am Stärksten, wo Software in größeren IT-Strukturen für bereits validierte Geschäftsmodelle optimiert wird.

Wir werden das im Teil III Optimizing Flow erläutern. Zunächst geht es darum, die je unterschiedlichen Aspekte der Unternehmensentwicklung zu unterscheiden. Einen Effekt zu erzielen ist etwas andereres, als Aufwand zu optimieren und in diesem Effizienz anzustreben. Neue Geschäftsfelder zu erkunden ist etwas anderes, als bereits etablierte zu sichern. Um nicht missverstanden zu werden: Jeder Aspekt ist für sich valide. Und für jeden gibt es mehr oder weniger geeignete Tools, die den Handelnden helfen, ihre jeweiligen Ziele zu definieren und zu errreichen.

Eine inzwischen verbreitete Chiffre für die unterschiedlichen Bühnen unternehmerischen Handelns mit je eigenen Erzählungen ist McKinseys 3-Horizontemodell. Wir verzichten auf eine vertiefte Beschreibung und verkürzen: Team Topologogies optimiert als effizienzorientiertes Framework den Horizont 1 "Exploitation" und nicht die Horizonte 2 "Validation" und 3 "Exploration".

Wie nicht anders zu vermuten, hat - hier verweisen wir auf folgende Artikel zum Verhältnis der Team Topologies zur Innovation - auch die Effizienzsteigerung ihren Preis, wenn wir Invention und Innovation von Geschäftsmodellen und in der Produktentwicklung betrachten.

Wenn man von einem begrenzten "Budget" an Zeit und Aufmerksamkeit ausgeht, kann der Fokus auf Team Topologie bedeuten, die Verbesserung des aktuellen Geschäfts und den Horizont 1, in den Mittelpunkt zu stellen. Die Aufgaben in den Horizonten 2 und 3 stehen notwendigerweise in der Konkurrenz mit dem Brotgeschäft aus Horizont 1 - das ist weder gut noch schlecht, man sollte es nur berücksichtigen, wenn man Ressourcen und Aufmerksamkeit verteilt. Grundsätzlich gilt: Eine Silver Bullit, die alle Probleme eines Unternehmens und seiner Entwicklung löst, gibt es nicht. Es muss jedem Fall bewusst abgetauscht werden.

Team Topologie entwickelt ihre Stärken eben nicht dort, wo sich die Unternehmen mit der Neuentwicklung und Invention, sowie der ersten wirtschaftlichen Validierung von Produkten und Leistungen in den Horizonten 3 und 2 beschäftigen. Hier sind Konzepte geeigneter, die explorative und ergebnisoffene Kollaboration zwischen Teams, Meinungen, Professionen und Individuen als Investition verstehen.

Wir verkürzen erneut: Damit Team Topologies echte Wirkungen entfaltet, ist neben dem Vorhandensein eines validierten Geschäftsmodells die Grundsatzentscheidung für dessen Optimierung im anwendenden Unternehmen zwingend.

Team Topologie im E-Commerce: Schnittmuster

Resümieren wir:

• Team Topologie verortet die Innovation und Effizienzsteigerung im Horizont 1 auf dem Shop floor, also dort, wo die Umsetzung passiert. Die Autor:innen drücken diesen Aspekt insbesondere mit dem Begriff team first appoach aus.

• Team Topologie verlangt die Konzentration auf die Kernaufgabe und den Aufbau der dafür notwendigen Qualifikationen. Hierfür stehen die Fokussierung der kognitiven Kapazität des Teams auf die Fachdomäne der Kund:innen und die Entlastung via Plattform as a product, x as a Service und gezieltes enabling.

• Der Shopfloor braucht das unmittelbare Feedback aus dem Verwendungskontext der eigenen Arbeit, weswegen in der Team Topologie bestehende und neue Software (im gesunden Maße) jeweils vom gleichen Team verantwortet werden sollen (you build, run, fix it ..).

• Die vorhandenen Organisationstrukturen, ihre dadurch konstituierte Fähigkeit Wirklichkeit zu konstruieren werden durch das unmittelbare Feedback, die Reflektion oder die externe Referenz relativiert. Wenn die Organisation keine Antworten mehr auf die Wirklichkeit draußen findet, steigt der Druck zur Anpassung und inverse conway strategien lassen sich leichter durchsetzen.

Teams, die sich in diesem Sinn ihrer selbst bewusst sind, helfen bei der Validierung der Grenzen des streams of change, also dem fachlichen Schnitt, für und in dem das Team Software entwickeln soll und von dem aus es selektiv und gezielt mit den anderen Teams kommuniziert.

Die Frage, wo diese Schnitte grundsätzlich richtig gesetzt werden, steht nicht im Vordergrund der Überlegungen der Team Topologie - sie sind eher externe Randbedingung als Gestaltungsfrage an die Teams. Das passt zur Verortung im Horizont 3, denn hier sind fachliche Neusortierungen im Rahmen des Geschäftsmodells eher unüblich und schwer durchsetzbar (vgl. en.wikipedia.org/wiki/The_Innovator%27s_Dilemma).

Gleichwohl wollen wir über diese Schnitte als Voraussetzung für die sinnvolle Abgrenzung von stream aligned teams ermöglichen, kurz nachdenken.

Im Buch finden sich dazu eher Beiträge mit dem Fokus auf die Restrukturierung vorhandener Softwareentwicklungsorganisationen und der Aufspaltung der von ihnen verantworteten monolithischen und verkoppelten Systeme. Unter der Überschrift des Kapitels 6 "Choose Team-First Boundaries" werden verschiedene Aspekte des Problems beleuchtet. Hier "... we define and explore ways of finding suitable boundaries within and across software systems that enable teams to own and evolve their part of the system effectively and sustainably in ways that encourage flow."

Dabei werden verschiedene Aspekte diskutiert und über "natürliche Schnitt- und Bruchlinien" fracture planes dieser Systeme nachgedacht. Pais und Skelton bieten im Kapitel 6 verschiedene sinnvolle Bruchlinien an:

• Business Domain Context als generalisierte und widerspruchsfreie technische Abbildung eines Aspekts des Geschäftsmodells.
• Regulatory Compliance als extern (rechtlich) vorgegebene Grenzziehung zwischen Softwaresystemen.
• Change Cadence als den Rhythmus, in dem Änderungen in einem System notwendig werden.
• Team Location als Abbildung der Kohärenz räumlich konzentrierter Teams (in Post-Corona-Zeiten sicher auch durch reine remote Teams abzubilden).
• Risk als Reaktion auf unterschiedliche Risikoniveaus, die sich mit einzelnen Systemen verbinden.
• Performance Isolation als unterschiedliche Anforderungen an die Performance der Systeme.
• Technology als Grundlage technologisch sortenreiner Teamschnitte.
• User Personas als Operationalisierung einzelner Nutzer:innen oder Kund:innentypen, deren unterschiedliche Problemstellungen durch unterschiedliche Lösungsansätze beantwortet werden sollen.

Welche Schnittlinie die richtige sei, hänge vom Einzelfall ab. Der richtige Schnitt begründet sich durch den Erfolg. Immer dann, wenn die kognitive Kapazität der Teams für die Lösung der gestellten Aufgabe ausreiche, seien die richtigen Grenzen gezogen worden.

Schnitte entlang zu stiftender Kundenwerte

An dieser Stelle sollten wir präzisieren: Skelton und Pais ergänzen zwar die gut genutzte kognitive Kapazität der Teams durch den später hinzukommenden Aspekt des Kund:innen-und Nutzer:innenfeedbacks. Nach unserer Einschätzung sind beide aber gleichrangig zu betrachten. Wir behaupten - mindestens für unsere Domäne der Softwareentwicklung für den E-Commerce: Nur ein fachlicher Schnitt, der die Dimension der Wertstiftung für den:die Endkund:innen der Software neben der Reduktion der kognitiven Last für das Team gleichrangig einbezieht und beides wahrnehmbar macht, ist hinreichend gut.

Damit ist im Kern die "Kund:innen- und Nutzer:innenorientierung" als zentrales Abgrenzungskriterium für die domain bounded contexts identifiziert. Der Kund:innennutzen ist für die Softwareentwicklung im E-Commerce die entscheidende externe Referenz, um den gestifteten Wert zu beurteilen und die erzielte Effizienz zu bewerten. Die übrigen Merkmale beschreiben die Teams genauer und definieren die Anforderungen an die Entkopplung in technischer, organisatorischer und prozessualer Hinsicht. Sie begründen den Teamschnitt u.E. aber nicht.

Wir verkürzen erneut und fassen zusammen: In der Domäne E-Commerce definieren sich die fachlichen Schnitte über die zu lösenden Kund:innen- oder Nutzer:innenprobleme oder vielmehr die für die Kund:innen und Nutzer:innen zu stiftenden Werte. Ausgehend von dieser Heuristik werden die Fragen gestellt, die durch geeignete Softwaresysteme von autonomen Teams beantwortet werden können. Wir sind (schon seit vielen Jahren) gewöhnt, diese als Vertikalen entlang der umfassenden Customer Journey und des Customer Life Cycle zu bezeichnen.

Adressiert Software neue Nutzer:innen mit eigenen Problemen, können wir damit eigenständige fachliche Domänen abgrenzen.

Um die Probleme der jeweiligen Nutzer:innengruppen zu lösen, sind eine oder mehrere spezifische Funktionen erforderlich. Jedes Stück Software erfüllt in diesem Zusammenhang eine Aufgabe, einen zu erledigenden Job. Manche verwenden hier den Begriff des Job to be done, Ursprungskonzept von Prof. Clayton Christensen .

Wichtig ist: In unserem Kontext sind die fachlichen Anprechpartner:innen die Kund:innen der Entwicklungsteams. Sie treten aber nur als Agent:innen der Endkund:innen auf. In dieser Funktion vermitteln sie den Teams die externe Kund:innenreferenz oder treten als Nutzer:innen auf, die die bereitgestellte Software mit Blick auf den damit erzielbaren Nutzen für die Endkund:innen verwenden.

Das klingt nicht nur mühsam. Es ist es auch.

Die Abgrenzung der streams of change müssen wir von unseren Auftraggeber:innen explizit einfordern und gemeinsam detaillieren, z.B. in dem wir eine gemeinsame Domänensprache entwickeln. Unser zentraler Zugang ist dabei die Definition der Endkund:innen oder der Nutzer:innen, sowie der durch sie zu lösenden Probleme.

Im E-Commerce fällt es trotzdem leicht in diesem Sinne vom Ende (also von Kund:innen her) zu denken und die Vertikalen zu definieren:

• E-Commercekund:innen suchen in [Produktlisten, Projekten, Ratgebern], um Kandidat:innen zu finden, die ihren Wunsch erfüllbar machen,

• sie informieren sich über die Auswahl an Optionen, um sich für die situativ richtige zu entscheiden,

• sie [kaufen, mieten, leasen, leihen] das Produkt, um sich die Verfügungsrechte über das Produkt zu sichern,

• sie [bezahlen, tauschen] Geld oder andere Äquivalente,

• sie bekommen das Produkt [geliefert, bereitgestellt, gebaut, ], um es zu nutzen,

• sie nutzen das Produkt (im Rahmen der erworbenene Rechte), um Nutznießer der Leistung zu werden.

• sie nutzen dazu einen Shop ...

Die Schnitte können in Tiefe und Fläche differenziert werden. In der Tiefe kann etwa Miete, Ratenzahlung, Tausch oder der Erwerb eines Teileigentums eigene streams of change begründen. Und auch in der Fläche entstehen neue Vertikalen: So wurde vielfach bereits die bisher beim Kauf abgeschlossene Customer Journey auf die Nutzung (Beratung, Verbrauchsmaterial, in-Use-Käufe, predictive Maintenance) erweitert. Und mit den Anforderungen der Kreislaufwirtschaft entstehen neue Steps.

Genauso wichtig ist: Jede Kund:innendefinition ergibt neue Schnitte. Dabei gilt: Nutzer:innen sind in diesem Sinne (manchmal) Kund:innen und Kund:innen sind immer Nutzer:innen. Skelton und Pais verwenden hier die persona als Begriff. Ein Beispiel:

• Marktplatzanbieter:innen brauchen Produktdaten, um ihre Angebotspalette zu gewährleisten,

• sie brauchen Preis- und Mengenangaben, um die verfügbaren Angebote zu managen und die eigenen Erlöse zu optimieren,

• sie brauchen Produktdaten, um die Produkte verkaufsfähig zu machen,

• sie müssen einen akzeptablen Bestellweg für Endkund:innen anbieten,

• sie brauchen Verteilmethoden, um den Marktplatzteilnehmer:innen die Auftragsabwicklung zu ermöglichen,

• sie müssen die eigenen Provisionen berechnen und einziehen

• sie brauchen ein Customer Frontend

• sie brauchen eine Administrationsanwendung

• sie brauchen Interfaces für Marktplatzteilnehmer:innen

Wir halten fest: Die konsistente Formulierung der streams of change oder der Vertikalen muss mindestens im E-Commerce immer die jeweiligen Endkund:innen im Blick haben. Interne Teams, die ihrerseits die Leistungen des liefernden Teams weiter verwenden, um damit ihre End-Kund:innen zu bedienen und dabei auf die Produkte des benachbarten Teams dauernd Einfluss nehmen müssen, sind Hinweise auf unvollständige Schnittmuster. Hier muss entkoppelt werden. Hierzu können - abhängig vom zu stiftenden Wert - die redundanten Daten und angepassten Kopien von Entitäten genau die richtige Lösung sein.

Die Reaktion auf die Botschaften (zumeist des Marktes) ist ein work in progress. Auch Skelton und Pais formulieren: "However, it is not sufficient to simply choose a team boundary a single time and expect no further changes; instead, organizatioons must anticipate the need for evolution of team patterns to meet busness, organizational, market, technological, and personnel needs."

Der Verzicht auf eine sorgfältige Definition von Kund:innen und Nutzer:innen und der für sie zu stiftenden Werte führt leicht zu suboptimalen oder gar toxischen Schnitten. Falsch definierte streams of change kosten Effizienz und gefährden den Unternehmenserfolg. Wir werden die Pitfalls anhand der complicated subsystems im entsprechenden Beitrag erläutern.

Schnitte entlang von Technologien

Die Bereitstellung von Software in einem anderen Device ist auch bei spezifischer Technologie (z.B. einer App) für sich allein keine gute Begründung für getrennte Teams, wenn diese die gleichen Endkund:innen bedienen. Gerade in diesem Zusammenhang führen Diskussionen um den "headless E-Commerce" in die Irre und begründen oft wenig effiziente Teamstrukturen. Im Gegenteil: Die enge Kopplung der App-Entwicklung an vorhandene Vertikalen zwingt zu dauernden Handoffs und ergibt so eine neue Form eines distributed monoliths. Headless E-Commerce stünde danach im Verdacht ein Antipattern zur Effizienzsteigerung zu sein.

Eine sinnvolle Entkopplung ist entlang technischer Bruchlinien möglich: Die native App Entwicklung wäre dann durch ein eigenes Team für die Usecases zu realisieren, für die von Kund:innen erwartete Features und neue Userstories optimal bedient werden können - aber nur dort. Für die Funktionen, die bei E-Commerce-Kund:innen deviceneutral bereitgestellt werden können, werden web views und responsives design als Teil der streams of change von den bisherigen Vertikalen geliefert und möglichst spät intergriert. Headless E-Commerce und APIs richtet in dieser Systematik an Nutzer:innen aus der Welt des IoT oder IoE - kurz an autonom agierende Programme und Maschinen.

Bild alles bleibt wie es ist und darauf werden Streams gelegt

Es wäre zu prüfen, ob eine Unterscheidung nach Kund:innentypen, nach Customer Journeys oder - daraus entwickelt - nach Kund:innenpersonas hier sinnvoll differeenzieren und systematisieren hilft. Ein:e Bestandskund:in oder ein:e Erstkund:in sind vielleicht unterschiedlich zu behandeln und begründen so einzelne Vertikalen. Leichter nachvollziehbar sind solch Überlegungen, wenn man als Endkund:in oder Transaktionspartner:in an die in dem IoT / IoE eigenständig bestellende Software z.B. in Hausgeräten denkt.

Schnitte entlang von Abteilungsgrenzen

Eine Abteilung oder eine organisatorische Einheit ist - nur weil sie existiert - dadurch noch kein eigenständiger Nutzender. Vielmehr sind die Nutzer:innen und die für diese gelösten Probleme aus der Kund:innenperspektive zu betrachten. Eine Stabstelle, die bisher exklusiv Daten gesammelt und für die BI aufbereitet hat, ist u.U. obsolet, wenn die entsprechenden Informationen bereits in den inzwischen autonom agierenden Vertikalen Teams viel einfacher und besser bereitgestellt werden können. Hier könnte man von einem reverse convay Manöver sprechen, in dem die vorhandenen technischen Strukturen so gute Angebote machen, dass die früher notwendig scheinende Zwischenschicht überflüssig wird.

Schnitte entlang "alt" vs. "neu"?

Aus Gründen noch eine Bemerkung zum Schnitt entlang der Linie: neuer Shop / alter Shop. Viele Kund:innen und nicht wenige Teams bvorzugen (aus unterschiedlichen und nachvollziehbaren Motiven) diese Schnittmuster. Sie liegen falsch. Bestehende Systeme sind eine wichtige Informationsquelle für den Erfolg des Teams. Auch Business as Usual gehört in die Verantwortung der Vertikalen. Dies wird umso sinnvoller, wenn man Softwareentwickung nicht nur als einmalige Bereitstellung einer Problemlösung ("fire an forget") sondern als die dauernde Kommunikation mit Kund:innen und Nutzer:innen über zu stiftende Werte betrachtet. Hier steht die Poblemlösung im Vodergrund und ein permanentes Feedback zum Produkt in das Entwicklungsteam ist gewährleistet. Ob die Lösung noch mit den Problemen matcht und insofern Werte gestiftet werden, bestimmt quasi naturwüchsig Teamaufgabe und Teamgrenzen.

Da die Verantwortung für den zu stiftenden Kund:innennutzen den Vertikalenschnitt bestimmt und das Team die Verantwortung für den verwendeten Softwarestack trägt, muss das Team diese Informationen verarbeiten können.

Fringe Benefit: Richtige Schnitte produzieren reife Teams

Wenn die streams of change konsistent entlang des gestifteten Kund:innenwerts definiert sind und der teamzentrierte Ansatz verfolgt wird, vereinen die stream aligned teams technische Expertise, verstehen die Botschaften des Marktes und nehmen die organisationalen Veränderungsimpulse aktiv auf. Sie haben ihre Stärken in der schnellen, stetigen und verlässlichen Auslieferung qualitativ hochwertiger Software. Sie betreiben Softwarenetwicklung als dauernden Dialog mit den Kund:innen und Nutzer:innen. Das gilt dann auch für Auftragnehmer:innen, die in diesem Kontext arbeiten.

Ein Modell, das die Sicht auf die Fähigkeiten der Teams zur Informationsverarbeitung und zur Kommunikation mit den Kund:innen, Nutzer:innen und der übrigen Organisation in den Vordergrund stellt ist die "agile fluency".

Hiernach werden Teams in immer weiteren Kreisen wirksam, sobald sie die eigenen Fähigkeiten auf die wesentlichen Aufgaben konzentrieren. Teams, die in bewusst geschnittenen Ökosystemen mit geeigneten Topologien und Interaktionsformen arbeiten, sind mindestens in der solche Teams in der Zone "delivering" zu verorten.

Optimieren die stream aligned teams nicht nur nach innen sondern auch (fordernd) nach außen, bewegen sie sich in die "optimizing Zone" der agile fluency, sie liefern nicht mehr nur angepasst an die organisatorischen Strukturen, sondern triggern die Veränderungen, die sie brauchen, um die vom Markt empfangenen Signale nicht nur intern zu verarbeiten. Sie wirken an der Entdeckung und Definition neuer streams of change mit und stärken letztlich so die Gesamtorganisation bzw. fordern sie zumindest heraus.

Fazit

Man könnte zusammenfassen: Orientiert sich ein:e Auftraggeber:in an einem Endkund:innen-orientierten Organsationsmodell, definiert entsprechende vertikale Schnitte in der Architektur und nutzt die Muster und Praktiken der Team Topologien, entsteht dadurch ein hoch produktives, zielgenaues und featurelieferndes System, in dem verschiedene Teams über Unternehmensgrenzen hinweg und ohne besondere Abstimmungsaufwände zusammenarbeiten.

Die Teams werden durch die Orientierung auf den zu stiftenden Wert für die Endkund:innen via Kund:innen- bzw. Nutzer:innenfeedback mit den Botschaften des Marktes versorgt und können diese technisch und fachlich beantworten. Sie sind zudem prozessautonom und haben damit alle Vorausetzungen im Horizont 3 business agile zu handeln.

Im demnächst folgenden dritten Teil der Serie werden wir die Topologien der stream aligned teams und die Kooperationsformen untereinander genauer mit Blick auf die Agenda des aktuellen E-Commerce beleuchten.