Team Topologies: Product Ownership in den vier Team-Typen

Team Topologies ist in aller Munde. Aber was bedeutet Product Ownership in den vier Team-Typen, die Team Topologies kennt? Das möchte ich heute beleuchten.

Am Ende des Artikels kennt ihr die vier Team-Typen und deren Interaktionsmuster aus Team Topologies und wisst, was das für Product Ownership bedeutet bzw. diese zum Einsatz kommt.

Team Topologies 

Team Topologies ist ein Ansatz zur Organisation von Geschäfts- und Technologie-Teams für schnelle Arbeitsabläufe und bietet ein praktisches, schrittweises und anpassungsfähiges Modell für Organisationsdesign und Teaminteraktion. Dabei nimmt es einen Delivery-Blickwinkel ein und betrachtet agile Skalierung aus einem horizontalen Blickwinkel.

Durch die vier Team-Typen und die drei Interaktionsmuster ergibt sich eine Vielzahl an organisatorischen Ausgestaltungen.

Dabei fokussiert sich Team Topologies stark auf die Bedürfnisse von Teams („Team First Approach“) und stellt dabei folgende Ansichten in den Mittelpunkt:

• Vertrauen & Gruppengrößen: Kleine Gruppen vertrauen sich stärker. Mehr Vertrauen steigert das Verantwortlichkeitsgefühl, verbessert die Kommunikation und letztlich das Ergebnis. Zudem sollen Teams stabil bleiben und die Teamgröße so gewählt werden, dass die Interaktion erleichtert wird. (Dies wird u. a. anhand von Dunbars Numbers hergeleitet – dazu aber in einem späteren Artikel mehr.)
• Team API: Um schnell und transparent anderen Teams zu zeigen, was man macht und wie, wird die Team API genutzt. Hier gehts zum Template.  
• Cognitive Load: Cognitive Load ist “the total amount of mental effort being used in the working memory.” Die Aufgaben des Teams werden an die kognitive Belastung angepasst, die das Team bewältigen kann.
  Dabei werden drei Arten von cognitive load (intrinsic, extrinsic & germane) berücksichtigt.   
• Conways Law & Kommunikation: Hierarchien sind künstlich und haben nichts mit dem realen Kommunikationsbedarf zu tun. Die Teamstrukturen müssen mit der erforderlichen Softwarearchitektur übereinstimmen, sonst besteht die Gefahr, dass Architektur zufällig entsteht.

Product Ownership & Team Topologies

Über Product Ownership verliert Team Topologies kein Wort. Nicht schlimm, denn das mache ich jetzt!

First things first: Team Topologies verliert übrigens ebenfalls kein Wort darüber, wie Teams arbeiten: egal ob Scrum, Kanban, XP, RUP oder ein wilder Mix aus allem. Nichts …

Damit verliert sich gerade die Logik meines Artikels, stimmt’s? Product Ownership ist ein Konzept aus Scrum – also wie soll das jetzt noch gehen!? Ganz einfach, ich setze den Kontext, weil man selbstverständlich innerhalb der Teams mit Scrum arbeiten kann.

Product Ownership im Stream-Aligned Team

Das stream-aligned Team ist der Rockstar, dem alle anderen Team-Typen zu Füßen liegen. Denn in diesem Team-Typ geht es um crossfunktionale Feature-Teams, welche einen Geschäftswert liefern.

Das stream-aligned Team bemüht sich also um einen einzigen, kontinuierlichen und wertvollen Arbeitsfluss, der auf eine Geschäftsdomäne ausgerichtet ist. Geschäftsdomäne kann ein einzelnes Produkt oder eine Dienstleistung, ein einziges Feature, eine User Journey oder eine einzelne Persona sein. Dieser Team-Typ sollte also der am häufigsten Vertretene innerhalb der Organisation sein.

DevOps-Ansätze/Kenntnisse sind auch in diesem Team vertreten, denn es wird davon ausgegangen, dass eine echte End-to-end-Verantwortung, samt Monitoring/Observability möglich ist. Dies unterstützt somit auch Korrekturen auf der Grundlage des Feedbacks von Kunden (oder Stakeholdern) und den experimentellen Ansatz in der Produktentwicklung. In diesen Teams kann Scrum angewendet werden. Wenn ihr hier Product Owner seid, kennt ihr den Job. Ois wie immer also!

Zweck der anderen Teamtypen ist es, die cognitive load für die stream-aligned Teams zu verringern. Wie sich das gestaltet, folgt nun.

Product Ownership im Platform Team

Das Platform Team stellt eine digitale Plattform (als internes Produkt) zur Verfügung, mithilfe dessen die Entwickler der stream-aligned Teams ihre Arbeit bewältigen können. Der Zweck des Platfom Teams ist die Ermöglichung einer weitgehend autonomen Arbeitsweise der stream-aligned Teams. Die Vereinfachung der Verwendung gemeinsamer Grundlagen, die die Implementierung von Produkten beschleunigen, hilft bei der Verringerung der cognitive load. 

Beim Platform Team richtet sich der Blickwinkel der Produktentwicklung nach innen; unsere Kunden sind interne Kunden, also die Entwickler. Das ist für Product Owner eine Herausforderung.

• Welche technischen Praktiken werden verwendet?
• Wie kann ich eine schnelle Adoption der Services erlangen? 
• Was benötigen unsere Entwickler wirklich, um schnell loszulegen?
• Wie kann ich das messen?
• Wie können wir das Feedback einholen? 

Viele Fragen die man sich im Produktmanagement stellt, kann man auf diesen Sachverhalt übertragen. Die Methoden können also transferiert werden. Jedoch ist die inhaltliche Auseinandersetzungdie Herausforderung. 

Hier hat man die Chance, eine Menge technisches Know-how aufzubauen und in einem sehr heißen Thema – nämlich Developer Experience – Erfahrung zu sammeln. Das Thema Product-as-a-Platform finde ich so spannend, dass ich diesem Thema einen separaten Artikel widmen werde.

In diesem Teamtyp kann man einen Product Owner hinzufügen, der für die Ausgestaltung der Plattform zuständig ist.

Product Ownership im Enabling Team

Die Aufgabe der Enabling Teams besteht darin, den stream-aligned Teams zu helfen, fehlende Fähigkeiten zu erwerben. 

Ein Enabling Team besteht folglich aus Spezialisten, die helfen, Kompetenzlücken zu überbrücken. Idealzustand ist, dass sie die Autonomie der Teams erhöhen, indem sie deren Fähigkeiten ausbauen. Damit vermeiden sie, zu Wissens-Silos zu werden.

Ein wichtiges Umdenken ist hierbei erforderlich: Die Mitarbeiter dürfen nicht als Ressource gesehen werden, die ausgelastet werden soll, sondern als Inhouse Consultant („Hilfe zur Selbsthilfe“). Enabling Teams sind also zur Verbreitung bewährter Verfahren und Steigerung des Know-hows der stream-aligned Teams vorgesehen. Dies geschieht mittels Beratung, Coaching, Mentoring und Training. Enabling Teams sind nicht dafür da, die Probleme zu beheben, die durch schlechte Praktiken, schlechte Priorisierungsentscheidungen oder schlechte Code-Qualität der stream-aligned Teams entstehen. Es ist kein „Clean-up-Team“.

Da es sich hierbei um eine Sammlung von Experten handelt, ist kein Product Owner für sie erforderlich. Product Owner, die eine hohe Vielfalt an Wissen und Erfahrung mitbringen, können Teil dieser Gruppe sein und zur Befähigung der anderen Product Owner dienen (Product Mangement Consultants oder Agile Product Coaches). 

Das Enabling Team kann Teil von CoPs, Gilden o. ä. sein und komplementiert diese. 

Product Ownership im Complicated Subsystem Team

Das Complicated Subsystem Team besteht aus Experten, die in der Lage sind, das Subsystem (kompliziertes Teilsystem) zu verstehen, zu erweitern und zu maintainen. Diese Teams werden nur erstellt, wenn ein Teilsystem überwiegend Spezialwissen benötigt.

Es werden also Fähigkeiten und Spezialisierungen gebündelt, um jene zur Verfügung zu stellen. Ziel dieses Teams ist es, die cognitive load des stream-aligned Teams zu reduzieren. Es wird angenommen, dass die Liefergeschwindigkeit und die Qualität durch das Complicated Subsystem Team deutlich höher ist, als wenn stream-aligned Teams diese (mit-)entwickeln. Es wird damit gerechnet, dass es nur wenige Complicated Subsystem Team benötigt werden.

Diese Subsysteme können bspw. mathematische Modelle, Face-recognition engines oder spezifische Reportingsysteme sein. Ob diese einen Product Owner haben, kommt stark auf das jeweilige Subsystem an. Am ehesten ist diese Arbeit mit dem des Platform Team vergleichbar. Die Priorisierung und Lieferung anstehender Arbeit berücksichtigt die Bedürfnisse der stream-aligned Teams, die das komplizierte Subsystem nutzen. Das hat den Vorteil, dass es tatsächlich noch von einem realen Kundennutzen getrieben wird und ein lokales over-engineering vermeidet.

Drei Interaktionsmuster 

Die Interaktion zwischen den Teams ist eine Einflussvariable dafür, wie schnell und wie einfach Teams ihren Kunden einen Mehrwert bieten können. Unzureichend definierte Teaminteraktionen und Verantwortlichkeiten sind Ursache von Reibereien, Spannungen und Ineffektivität. Deshalb bietet Team Topologies drei Arten der Interaktion zwischen Teams an, nämlich Collaboration, X-as-a-Service und Facilitation.

• Collaboration: Enge Zusammenarbeit für einen bestimmten Zeitraum, um neue Dinge zu entdecken (APIs, Praktiken, Technologien, usw.) Es eignet sich auch zur Bewältigung einzigartiger Situationen und unsicherer Kontexte. Eine hohe Interaktion, ist aufgrund des hohen Lerntempos wertvoll.
• X-as-a-Service: Ein Modus, der die Entkopplung und Standardisierung begünstigt. Ein Team stellt sein Produkt über standardisierte Schnittstellen zur Verfügung. Hierbei ist eher wenig Interaktion gefordert.
• Facilitation: Eine vorübergehende Beziehung zwischen zwei Teams, mit dem Ziel, Fähigkeiten auf nachhaltige Weise von einem zum anderen zu übertragen. Ein Team hilft einem anderen Team und steht ihm als Mentor zur Seite. Hierbei ist wenig bis mittlere Interaktion gefordert.

Um ein Gefühl zu bekommen: Die Interaktionsmuster und die Team-Typen die üblicherweise auftreten, lassen sich so aufschlüsseln.

Das ist nicht in Stein gemeißelt, weil es Trigger gibt, die mehr oder weniger Interaktion erfordern.

Besonders hervorzuheben ist die erfrischende ehrliche Sichtweise, dass das Awkwardness-Level der Kollaboration aufzeigt, ob man gerade im richtigen Interaktionsmodus unterwegs ist. Es ist somit ein Hinweis auf eine Learning-Opportunity und sollte Inspect & Adapt auslösen; anstatt es zu ignorieren.

Team Topologies

Die Kombination aus Team-Typen und Interaktionsmustern

Im nachfolgenden Schaubild, könnt ihr nun einmal nachvollziehen wie Team Topolgies in freier Wildbahn aussehen kann.

Das stream-aligned Team wird vom Enabling Team mittels Facilitation unterstützt. Das Complicated Subsystem Team und das Platform Team stellen ihre Dienst als X-as-a-Service bereit.

Zu guter Letzt …

Zum Abschluss habe ich noch einen kleinen Lerntest für euch: Wer nicht lachen kann, der hat es nicht verstanden ;)