Team Topologies III - Optimizing Flow

Team Topologies - Recap Teil II

Um die Effizienzreserven bei der Softwarentwicklung zu heben, ist die Abgrenzung sinnvoller streams of change notwendig. Und um geeignete Schnittmuster zu entwickeln, stehen - wie im zweiten Beitrag dieser Serie beschrieben - verschiedene Bruchlinien zur Verfügung. Im E-Commerce orientieren sich diese Schnitte am gestifteten Wert für die Endkund:innen. Damit wird die verbesserte Auswertung validierter Geschäftsmodelle möglich und die wichtigste externe Referenz für die Weiterentwicklung der Produkte - die Botschaften des Marktes - für das Team zugänglich gemacht. Die Teams erfüllen damit nicht nur ihre Aufgabe der Lieferung, sondern erhalten die Option zunächst die eigene Arbeit zu optimieren und später auch in der gesamten Organisation zu wirken.

Kommunikation von Vertikalen

In unserer Domäne des E-Commerce werden Schnitte entlang der Kund:innenwert-stiftenden Abschnitte der - umfassend verstandenen - Customer Journey bzw. des Customer Life Cycles gelegt. Wie bei jedem Entwicklungsmodell, das den Anspruch auf Implementierbarkeit erhebt, ist auch bei der Team Topologie eine Frage, in welchem Umfang hier das Expert:innenwissen bzw. der Einsatz von Expert:innen erforderlich ist.

Grundsätzlich geht das Konzept vom team first approach aus. Der Shopfloor, das Team, wird als zentraler Ort der Effizienzsteigerung angesehen. Es kommt daher mehr darauf an, diese Potenziale bewusst zu machen, als detaillierte Arbeitsanweisungen zu erteilen. Üblicherweise werden die ersten groben fachlichen Schnitte noch initial top down vorgeschlagen. Aber schon hier sollten eher Ziele vorgegeben werden, für deren Erreichung die Teams angepasste Lösungen entwickeln können.

Damit die Teams zu Lösungen kommen, können best practises, Do's and Dont's, als Beratung und Coachings angeboten werden. Insofern scheint das Handwerkszeug der Team Topologie das erste (und vermutlich das einzige), was den Teams zur Optimierung des eigenen Flows beigegeben werden könnte. In den Vertikalisierungsprojekten wird diese Beratung bisher durch erfahrene Entwickler:innen in die Teams getragen. Ein explizite Reorganisation nach Begriffen der Team Topologie findet in unseren Arbeitsbeziehungen bisher nur in Ausnahmefällen statt. In den durch Vertikalen geprägten E-Commerce-Ökosystemen, werden teamübergreifende Fragen und Impulse zu Architektur, technischen Guidelines, Monitorings, Tests, Sicherheit u.a.m. über die sogenannten Gilden thematisiert und verhandelt. Die Gilden bieten die Gelegenheit und Prinzipien zum Alignment on-demand - quasi als eigenes Produkt und nicht als vorgegebenes "Regelbündel mit Anschlusszwang". Eine zweite Säule des Enablings und des Alignments sind die "Expert:innen und Evangelist:innen". Diese senioren Kolleg:innen wandern mit ihren Themen durch die Teams und bieten auf Zeit Beispiel und Practise.
Die Kommunikation ist überwiegend personal sowie persönlich und zeitigt die entsprechenden Aufwände.

Diese Non-Struktur ist an Personen orientiert und wird durch sie getragen. Sie nutzt damit vorhandene Qualifikationen optimal und flexibel aus - sie macht durch Push- und Pull das beste aus den vorhandenen Erfahrungen.

Die Vertikalen können so lernen, wie sie ihr Handwerkszeug optimieren, sie können die kognitive Belastung durch Informationen aus dem Bereich intrinsic reduzieren - sie optimieren dauernd ihr handwerkliches Können. Der Wissensaufbau im Team steht im Vordergrund.

Es bilden sich über die Zeit und je nach Bedarf auch formalisierte und kodifizierte Strukturen. Wir beobachten Best practises, handouts und fertige Lösungen z. B. zu Security-Themen, wir finden vielfach Pattern-Libs für das Frontend als as-a-service Angebote. Wir finden Wikis mit How-tos und in Jobs gegossene Deploymentprozesse. In alle diese übergreifenden und teamspezifischen Orte und Artefakte kann jedes Team nach vereinbarten Regeln hineinarbeiten. Diese Strukturen können von zwei Seiten betrachtet werden: Positiv formuliert entstehen sie zur richtigen Zeit, im richtigen Umfang, für die, für sie richtigen Themen. Sie sind taylormade für die jeweiligen Aufgaben und die jeweiligen Wissensstände der Teams. Negativ formuliert sind sie unvollständig sowie zufällig und müssen im jeweiligen Bedarfsfall immer erst neu entwickelt werden.

Diese Kommunikation der Vertikalen mit ihrem Außen erscheint z.T. unscharf. Während mit anderen Vertikalen aufgrund der fest definierten Kund:innenorientierung klar und abgegrenzt kommuniziert werden kann (Datenbestände können z.B. als Snapshots getauscht werden, die Frage, welche Entität, wo angelegt wird, lässt sich mit Blick auf den zu stiftenden Kund:innenwert rasch aushandeln), sind Plattformthemen, Enabling Prozesse und komplizierte gekapselte Systeme alle gleich: Sie kommen von außen. Vielfach versucht das Vertikalenteam sie als Überbringer:innen von Informationen zu verstehen, die mit ins Vertikalenwissen überführt werden müssen.

Damit wird, bezogen auf die kognitive Last der Teams, die Stärke des "zu eigen machens" zu einem Risiko: Wenn jede Aufgabe dem Team entweder als intrinsic (Handwerkszeug) oder als germaine (Kund:innendomäne) zugewiesen wird und die Teams keine von außen verursachte kognitive Last (extraneous) kennen, kann die kognitive Kapazität nicht gezielt bewirtschaftet werden.

Besonders deutlich wird das bei den Themen Plattform und DevOps, sowie gegebenen und gekapselten Systemen. Hier besteht u.E. beim Vertikalenkonzept die Gefahr die kognitive Kapazität des Teams in zu starkem Umfang durch extragenous Themen zu beanspruchen. Team Topologie adressiert hier einen blinden Fleck im Konzept der E-Commerce-Vertikalen.

Kommunikation von stream aligned teams

Team Topologie stellt die Effizienz des Gesamtsystems bei der Änderung und Anpassung der Features in den Vordergrund. Träger des Flows sind die stream aligned teams, die sich selbstentwickelnd optimieren. Neben der lokalen Optimierung braucht das eine selektive Kommunikation mit anderen Teams im gleichen Businesskontext; erst das Zusammenspiel macht die Teams zu zentralen Akteur:innen und Treiber:innen der Optimierung der Auswertung des eigenen Geschäftsmodells.

Alle Teams wissen um ihre jeweiligen Zwecke. Das gilt nicht nur für die stream aligned teams, sondern auch für die platform teams die enabling teams und complicated subsystem teams. Das Ökosystem und die in ihren agierenden Akteur:innen sind klar beschreibbar. Die Teams bekommen damit Subjektcharakter. Rolle und Aufgabe werden auf die Ebene der Teams gehoben und dort verhandelbar. Wir werden weiter unten kurz diskutieren, was das bedeutet.

Herausforderungen und Guidelines der Selbstentwicklung

Wir betonen in unserer E-Commerce Adaption der Team Topologies die Bedeutung der Selbstentwicklung der Teams, die sich - immer mit Blick auf die eigene Vertikale und die Botschaften des Marktes hierzu - entlang der zu lösenden Aufgabe organisieren.

Topologie als Ordnungskriterium

Ausgehend von Topologien kann die Vertikalenstruktur optimiert werden. Wie immer gehen die Vertikalen vom Kerngeschäft, d.h. der Softwareentwicklung mit dem Ziel der Maximierung des zu stiftenden Kund:innenwerts aus. Ausgehend davon, bewähren sich Fragenkataloge, die die Aufgabe und den Ist-Zustand des Teams in Beziehung setzen. Dabei werden Innen- und Außensicht integriert.

• Wie definiert sich der stream of change oder die Vertikale, der oder die dem Team zur Bearbeitung anvertraut wird? Welcher konkrete Kund:innenwert wird gestiftet?

• Welche Ziele sollen aus Sicht der Stakeholder in der Vertikale erreicht werden? Welche Metrik liefert Aussagen über den erreichten Effekt?

• Passen die Schnitte der Streams und der Teams auch in der absehbaren Zukunft? Wie werden Botschaften des Marktes aufgenommen und verarbeitet?

• Welche technischen und organisatorischen Blaupausen gibt es für Technik und Prozesse?

• Welche technische Expertise ist im Team vorhanden, welche fehlt im Team? Wie wird fehlende Expertise aufgebaut? Reicht Selbstlernen, erfordert es konzentrierten externen Input, braucht es Seniorität auf Zeit? Müssen Enabling Teams im Team wirken?

• Welche Plattformlösung entlastet das Team von wiederkehrenden Aufgaben? Wie zielgenau trifft die bereitgestellte Plattform die Bedürfnisse des Teams? Wer ist Ansprechpartner:in für Pflege und Entwicklung des Produkts Plattform?

• Mit welchen komplizierten Subsystemen müssen wir kommunizieren? Sind diese Systeme wirklich nötig?

Dieser Diskurs muss immer wieder im Team geführt werden und ggf. zu Anpassungen führen. Innerhalb des Teams bewährt sich eine Kadenz, die mit der Häufigkeit von Änderungen im Featureset des Teams harmoniert. Im Bereich des Marketings mag es häufiger nötig sein, die eigene Mission zu überprüfen, als im Umgang mit Bestellungen oder der Logistik.

Nicht zuletzt sind personelle Veränderungen im Team oder regelmäßige unternehmensweite Strategiediskussionen weitere Triggerpunkte für diese Vergewisserung.

Kommunikation innerhalb der Teams

Jedes Team - gleichgültig, ob es via externer Dienstleister:innen oder als Team aus der auftraggebenden Organisation am Kund:innennutzen arbeitet - kann für sich mit Hilfe der Flow-optimierenden Werkzeuge Pfade der Selbstentwicklung formulieren.

Mit Hilfe der Antwort auf die Fragen: "Welche Art von Team sind wir?" und "In welchem stream of change arbeiten wir?" wird der Teamfokus beschreib- und kommunizierbar. Er ermöglicht dem Team die eigene Arbeit optimal auszurichten. Zentral ist nicht der Herkunftsort des Teams oder der in ihm arbeitenden Mitglieder, sondern die gestellte Aufgabe, z.B. liefert ein stream aligned team Features für den Flow in der eigenen Vertikale - und das stetig, verlässlich und in hoher Qualität.

Dazu muss es

• die eigene technische Expertise immer auf dem hinreichenden Stand halten.
• externalisieren, was nicht auf den Flow einzahlt und sich dazu bereitstehender Plattformen und geeigneter Subsysteme bedienen.
• die eigenen Fähigkeiten auf die fachliche Domäne der Kund:innen zuspitzen und dazu Expertise aufbauen.

Zwei Fragen müssen beantwortet werden, um als Team die richtige Topologie zu finden:

Wie entwickeln wir unser Team?

Was wird in die intrinsische Sphäre übernommen, welche Fertigkeiten werden als Basisqualifikation Bestandteil der Toolbox des Teams? Was müssen wir selber bauen, weil die Aufgabe individuelle Lösungen (oder die Kombination vorkonfektionierter Lösungsbestandteile) erfordert? Welche Professionen (z. B. über die Integration neuer Teamkolleg:innen) brauchen wir, um die Aufgabe bestmöglich zu bearbeiten? Welche Prozesse und Artefakte helfen uns, die eigene Aufgabe optimal zu erfüllen?

Welche Exzellenz brauchen wir wo?

Wo brauchen wir Enabling? In welcher Form kann neues Wissen ins Team gelangen? Können wir auf Zeit mitarbeitende Spezialist:innen im Team begrüßen, die uns in kollaborativen Arbeitsformen auf dem Weg zur Exzellenz unterstützen? Oder sind externe Schulungen notwendig? Hilft Slacktime, der Austausch in Gilden oder Interessengruppen, um individuelles Wissen aufzubauen und so neue Expertise ins Team zu holen? Wo ist Exzellenz als Meisterschaft im Beherrschen des Bekannten und wo als Innovation gefordert?

Organisationales Sensing

Team Topologies geht davon aus, dass die Organisationsentwicklung untrennbar mit der Optimierung des Flows verbunden ist. Überall dort, wo dem Shopfloor dazu die Kompetenz abgesprochen und die klassische bifokale IT weiter verfolgt wird, kann Team Topologie als irritierendes Moment von den Teams eingesetzt und wirksam werden, z.B. wenn von internen oder externen Teams eine nicht angemessene kognitive Last zum Thema gemacht wird.

Auf der fachlichen Ebene kann es sein, dass die Anforderungen des streams of change in der vorhandenen Organisation nicht adressiert werden können - hier sind oft die Productowner teamseitig Treiber und Owner der Diskussion, welche Anpassung auf welcher Seite erfolgen soll.

Teams als Subjekte

Jedes Team kann und soll Aufgaben externalisieren, muss diese Fragen aber mit Blick auf die eigene Aufgabe und den Gesamtflow stellen. Der erste Ort hierfür ist das Team, die Kommunikation findet zwischen den Teammitgliedern statt.

Das "Team" entwickelt einen Subjektcharakter. Gerade länger bestehende Teams integrieren z.B. neue Mitglieder, ohne die eigene Struktur wesentlich zu verändern. Das A-Team ist als A-Team erkennbar, auch wenn alle ursprünglichen Teamkolleg:innen inzwischen in anderen Zusammenhängen arbeiten. Die Evolution wird durch die neuen Kolleg:innen mit getrieben, ohne Zweifel, aber der entscheidende Impuls bleibt die Aufgabe des Teams und die dafür entwickelten Kommunikationsmittel und -kulturen.

Diese Stabilität optimiert verschiedene teaminterne, mit Aufwand versehene Aufgaben: Recruiting, Boarding, Produktdefinition, Prozesse und Verabredungen werden leichter beschreibbar. Die Wirkung entsteht durch Fokussierung auf die gestellte und selbst ausdefinierte Aufgabe. Das Team optimiert sich selbst - mehr muss nicht sein.

Dass diese Fragen völlig unabhängig von der Frage der Unternehmensgrenze beantwortet werden können, ist zentral. Das Team optimiert die eigenen Fertigkeiten mit Blick auf die Aufgabe (Features auszuliefern, andere zu enablen, eine Plattform oder ein kompliziertes Subsystem zu entwickeln und zu betreiben). Es wirbt dafür Ressourcen ein, liefert Software aus und kann - im Rahmen der jeweiligen Topologie auch inhaltlich, technisch und thematisch pivoten. Es ist - im Rahmen der gestellten flow- und effizienzorientierten Aufgaben und im vorhandenen Ökosystem - zur Selbstentwicklung befähigt und autorisiert.

In gewisser Weise wird das Team zum eigenständigen Produkt. Es optimiert sich selbst und handelt als auf Dauer gestellte Organisation. Es fordert die Verantwortung für Teile des Geschäftsmodells und kann so ressourcen- und kostenoptimierender sein als auf Zeit und kurze Frist zusammengestellten Single-Purpose-Projektteams, denn diese die notwendigen Rüstkosten immer wieder neu ermitteln, aushandeln und darstellen. Entscheidende Bedingung bleibt, dass die Teamlandschaft insgesamt in ihrer Topologie auch bei einer Änderung des Teamziels "Produkt xy statt mn" dem Grunde nach stabil im Zweck bleibt oder anders gesagt, ein marktfähiges Angebot für die Lösung der Kund:innenprobleme anbieten kann.

Das seiner eigenen Aufgabe bewusste Team verfügt hier über mächtige und allgemein anerkannte Verhandlungsargumente: "Wir sollen xyz leisten, damit unser Geschäftsmodell funktioniert. Damit wir xyz leisten können, brauchen wir 123." Dabei ist gleichgültig, ob das Team die Selbstentwicklung mit dem eigenen Management oder dem des Auftraggebenden diskutiert, denn die Referenz ("unsere Aufgabe") bleibt jeweils die gleiche.

Exkurs: Was liefern Dienstleister:innen?

Teams können - mindestens dem Grunde nach - auch aus Kolleg:innen unterschiedlicher Unternehmen bestehen, denn die Referenz ist der Teamerfolg, nicht das eigene oder das fremde Unternehmen.

Dieser "agnostischen Perspektive" stehen in der Praxis Vorgaben der beteiligten Unternehmen entgegen, die sich als rechtliche, haftungstechnische, wirtschaftliche, abrechnungstechnische, buchhalterische oder sonstwie bezeichnete Themen präsentieren. Hier greifen auch für die möglichen Teamstrukturen die Beschränkungen von Conways Law. Es können nur die Strukturen gebildet werden, über die die beteiligten Organisationen kommunizieren können.

In der Realität werden daher eher unternehmensscharfe Auftraggeber:innen- und Dienstleister:innenteams gebildet, die zwar mit einzelnen jeweils externen Kolleg:innen aufgefüllt werden, aber fix in einer der beiden Organisationen beheimatet bleiben. So muss im einzelnen Team nicht zwischen zwei Kulturen und Wertesystemen balanciert werden.

Es ist eine spannende Frage, welche Erträge Produktteams schöpfen könnten, die ohne Rücksicht auf Unternehmensgrenzen (also in einem Netzwerk) zusammengestellt werden und so eigenständige Kulturen ausbilden könnten. Zur Wahrheit gehört: In unserer Welt ist dies zur Zeit eher eine theoretische Option. Noch sind die Verhältnisse nicht so.

Kommunikation zwischen stream aligned teams

Die in Kapitel 7 des Buchs beschriebenen Team interaction Modes sollen als Innovationstreiber wirken: "Through a combination of well-defined team interaction patterns and clear heuristics for evolving team topologies, organizations can use team interactions as a sensing mechanism for innovation and self-steering toward better customer or user outcomes."

Grundlegendes Kalkül der Team Topologies in der Ausprägung E-Commerce ist es, die kognitive Kapazität der Teams für die Entwicklung der in der Kund:innendomäne maximal wertstiftende Software zu nutzen - in diesem Sinne alles auf die erfolgreiche Transaktion auf dem Markt auszurichten. Alle Maßnahmen, die diesem Ziele dienen, werden positiv eingeschätzt, das gilt auch für die Zusammenarbeit zwischen den Teams. Die Orientierung an einem Kund:innenproblem, die einen stream of change in der Abbildung in einer Vertikalen abbildet, ist ein Muster für die maximale Entkopplung von stream aligened teams.

Teamübergreifende Kommunikation bedeutet immer Aufwand (also Kosten).

• Je geringer die Anzahl zu kommunizierender Gegenstände ist, umso besser.
• Je simpler die zu kommunizierenden Gegenstände sind, umso besser.
• Je generalisierter die Kommunikation zwischen Sender:in und Empfänger:in ist, umso besser.

Teamübergreifende Kommunikation wird nur betrieben, wenn sie unvermeidbar ist.

• nicht notwendige Kommunikation ist besser als Kommunikation.
• einfach-eindeutige Kommunikation ist besser als kompliziert-mehrdeutige Kommunikation.
• wiederholbar-identische Kommunikation ist besser als einmalig-spezifische Kommunikation.

Jede Kommunikation soll die kognitive Kapazität des Teams auf die tiefe Kenntnis der Kund:innendomäne ausrichten

• Kommunikation über handwerkliche Basics braucht es im besten Fall gar nicht.
• Kommunikation über extrinsische, technisch organisatorische Aspekte muss simpel und generalisiert erfolgen.
• Kommunikationen über die Kund:innendomäne sollte durch die Abgrenzung des Auftrags vollständig in das Team verlagert werden.

Auch hier verstehen wir die genannten Punkte eher als Prinzipien, denn als Regeln. Auch die Formen der teamübergreifenden Zusammenarbeit sind ein work in progress.

Kollaboration vs. "X-as-a-Service"

"What must be avoided is the need for all teams to communicate with all other teams in order to achieve their ends". Team Topologies kennzeichnet - wenig verwunderlich - die Kollaboration als aufwändigste Interaktionsform zwischen Teams. Steht diesem Aufwand kein besonderer Ertrag gegenüber, wird die Notwendigkeit, z.B. der komplizierten Aushandlung des immer gleichen, als frustrierend und belastetend empfunden.

Ist ein solcher Ertrag gegeben - z.B. weil man die Kommunikation nicht generalisieren kann (komplexe Zusammenarbeit) oder weil Neues und Besseres erprobt wird (= Innovation) oder weil noch eine Bestandsaufnahme aussteht (komplizierte Kommunikation), wird die Kollaboration wertgeschätzt und als sinnvolle Investition verbucht. Kollaboration ist notwendig, unsicher und offen - damit treibt sie Innovation, verschiebt Grenzen und erlaubt schnelles Testen neuer Antworten.

Generalisierte Interaktion, bei der - ggf. asynchron - ein Team Angebote eines anderen Teams als Service konsumiert, ist weniger aufwändig und kann vor allem beliebig oft wiederholt werden. Sie lebt von der Berechenbarkeit und ist als solche im Kern statisch. Lebt Kollaboration von der Gleichzeitigkeit von Inhalt, Aushandlung und der Vermittlung von Informationen, ist x-as-a-service von der Trennung dieser Dimensionen gekennzeichnet. Ist die Kommunikationschiffre der Kollaboration das "Gespräch", ist der Konsum von Services eher durch die "API" beschrieben.

Vereinfacht könnte man bei stabilen Verhältnissen unterschiedlichster Dimensionen (von stream of change, Vertikalen, Prozessen, Technik oder der Organisation) der API gegenüber dem Gespräch den Vorzug geben. Immer dann, wenn Dynamik und Reibung gefordert oder mindestens unvermeidbar ist (beim Neuaufbau von Teams, bei bewusster Disruption vorhandener Strukturen durch Conway Manöver), sind Formen der Kollaboration besser geeignet.

Ein Beispiel sind die relativ aufwändigen Workshops zur Entwicklung von Domänensprachen, die dann zu vereinfachten und widerspruchsfreien Begriffsapparaten führen.

Wichtig ist, dass die Kollaboration nicht zu jeder Zeit mit allen Teams geführt wird. Pais und Skelton empfehlen, ein Team mit nicht mehr als einem anderen Team kollaborieren zu lassen und präferieren die Transformation dieser Beziehungen in Richtung x-as-a-service.

Facilitating

Während die Kommunikation über APIs und x-as-a-service den Aufwand für die einzelne Interaktion minimieren, verfolgt die Interaktionsform des facilitating ein anderes Ziel. Hier geht es darum, Wissen und Fähigkeiten in einem Team aufzubauen, sodass die entsprechende Aufgabe von da an innerhalb des vorhandenen Teams erfolgreich bearbeitet werden kann. Das kann z.B. die Verwendung oder selektive Anpassung des Produktes "Plattform" betreffen, die Beachtung von Security patterns oder die Verwendung von best practises in der Entwicklung von Backend und Frontend.

In unseren E-Commerce Vertikalen werden z.B. die Verwendung von Microfrontend Konzepten oder der Aufbau von data science Komponenten so verbreitet.

Das Facilitating wird umso eher nötig je neuer und ungewohnter ein Muster für die neuen Teams sind. Viele Themen wandern im Laufe der Zeit aus dem Bereich des enabling in die intrinsic Dimension und werden als allfällig notwendiges Handwerkszeug der Entwickler:innen in den Berich des Selbstlernens und der selbstorganisierten Aus- und Weiterbildung im Team wandern.

Fragenkatalog für teamübergreifende Interaktion

Für die Bestandsaufnahme verwenden wir diese (oder ähnliche) Fragenkataloge, die regelmäßig wieder aufgerufen werden, um die vorhandenen Interaktionen neu zu bewerten und ggf. anzupassen:

• Welche organisatorischen Anknüpfungspunkte ergeben sich für eine maximal von anderen stream aligned Teams entkoppelte Struktur? oder anders gefragt: Wie können wir als Dienstleistungsunternehmen die Aufgabe für unser Team so schneiden, dass es einen eigenen klar definierbaren Wertbeitrag mit Blick auf das Geschäftsmodell des Auftraggebenden erbringt? Welche Kommunikationen sind dann noch unabweisbar notwendig?

• Wie einfach ist es für die Nachbarteams den eigenen Wertbeitrag vom Wertbeitrag unseres Teams abzugrenzen? oder anders gefragt: Wie beschreibt sich das Kerngeschäft jedes Teams in Abgrenzung zum Nachbarteam? Welche Entitäten, welche Prozesse, welche Domänen bedient Team A, welche Team B?

• Wie organisieren wir die notwendige Kommunikation möglichst simpel, generalisiert und wiederholbar? oder wo können wir eine API definieren, die das Nachbarteam in den Stand versetzt, unsere Leistungen ohne weiteren Aufwand unsererseits als Service (=als Ergebnis) zu beziehen.

• Wie reduzieren wir aufwendige Kommunikationsformen, wie die Kollaboration in Zeit und Umfang? oder anders gefragt: Wo ist Kollaboration auf Zeit wichtig, wo zeigt sie die Notwendigkeit neuer Aufgaben- und damit neuer Teamzuschnitte an? Wo und wie kann sie generalisiert und serialisiert werden?

Fazit

Team Topologie bietet mit den drei (vier) Interaktionsformen zwischen Teams und der internen Kommunikation mit Blick auf die Kund:innen und Nutzer:innenreferenz ein robustes Instrumentarium für die Selbstentwicklung.

Das Konzept der stream unterstützenden Teams adressiert unterschiedliche Zwecke und schafft Voraussetzungen für Handlungssicherheit der Teams, die in klassischen Vertikalenkonstrukten nur implizit angesprochen werden.

Das Ziel die Effizienz der Auswertung bereits validierter Geschäftsmodelle zu steigern, bevorzugt gerenalisierte und formalisierte Interaktionsformen (x-as-a-service) gegenüber der innovationsträchtigeren aber auch aufwändigeren Form der intensiven Kollaboration.

Im E-Commerce wird Expertise und neues Wissen durch Seniorität in die Teams eingebracht. Enabling und Facilitating sind eher in Gilden und Kreisen als in eigenen Teams lokalisiert.

Die Frage nach geeigneten Interaktionen zu stellen, ist in regelmäßiger Kadenz die Aufgabe der Teams. Hier KnowHow einzubringen, kann externe Beratung erfordern.

Ausblick

In den folgenden Teilen IV und V werden wir uns mit den Themen "Plattform as a product" und "Enabling-Teams" in unserer E-Commerce-Domäne beschäftigen und deren Beitrag für die Effizienzsteigerung zu bewerten suchen.

Weitere Artikel der Team Topologie-Reihe:

Team Topologies in Auftraggeber-Dienstleister Konstellation

Team Topologies II - Defining streams