Team Topologies
Basics für  Product Owner

EMERGENTES, Reflektiertes  
ORGANISATIONSDESIGN

Wie es offiziell aussieht ...

Wie es offiziell aussieht ...

... und was in Wirklichkeit passiert.

  • Eher zufällig als geplant
  • Manche Funktionen  funktionieren nur deshalb
  • Manche Dinge stören
    • von Machtpolitik zu Grabenkämpfen
    • von Wir-Gefühl zu Tribalismus

Conways LAW

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure"

  • CoreDB und Ops als Monolith
  • DBA & Ops als Engpass
  • DBA & Ops als Diktator
  • Alles ist abzustimmen
  • Alles dauert lange
  • ... ausser man kennt sich gut.
  • CoreDB und Ops als Monolith
  • DBA & Ops als Engpass
  • DBA & Ops als Diktator
  • Alles ist abzustimmen
  • Alles dauert lange
  • ... ausser man kennt sich gut.
  • Besser wäre eine Architektur ohne Abhängigkeiten...
     
  • ... MicroServices! 
  • Besser wäre eine Architektur ohne Abhängigkeiten...
     
  • ... MicroServices! 

Inverse / Reverse Conway Maneuvre

Problem Solved!

Everybody is happy now!

Macht jemand von Euch MicroServices?

Basics for Organisation Design

  • Performance kommt von den 5 in der Mitte
     
  • mit den 15 drumherum können wir vertrauensvoll interagieren
     
  • 50 Leuten können wir gegenseitig vertrauen
     
  • 150 Leute können wir einschätzen
     
  • zu 500-1500 Leuten können wir Beziehungen haben

Aber wie finde ich heraus, welcher 5er, 15er und 50er-Gruppen ich brauche?

Wie teile ich die Accountabilities gut auf?

Möglichst viel Denken für Business Value Nutzen.

Good Boundaries to minimize Cognitive Load

Teams und Software so schneiden, dass die kognitive Belastung minimal ist.

INTRINSISCH
EXTRINSISCH
LERNBEZOGEN

Intrinsisch

Dinge, die ich für meine aktuelle Aufgabe einfach brauche. 

Wie viele Dinge muss ich berücksichtigen?

Wie interagieren die Dinge miteinander?

PO als Dolmetscher & Erklärbär

EXTRINSISCH

Was muss ich dazu noch beachten? Welche äusseren Anforderungen gibt es noch? 

PO als Service.

Lernbezogen

Kognitive Belastung um das benötigte Wissen zu lernen, das ich dann als intrinische oder extrinische kognitive Belastung jonglieren muss.

PO & SM als Service für Knowhowaufbau.

SUM(INTRINSISCH
        +EXTRINSISCH
        +LERNBEZOGEN)
<= CONST

Wie sieht die kognitive Belastung hier aus?

"Un-Product-Ownable Teams."

  • Kleinere Teams
  • mit gemeinsamer Software
  • mit klarem Fokus
  • mit wenigen Abhängikeiten
  • mit wenigen Ansprechpartnern

Auch der PO profitiert hier deutlich vom Fokus.

Reduktion kognitiver Belastung

  • Analyse auf Basis kognitiver Last
  • Passender Teamschnitt
  • Interaktionen zwischen Teams
  • Effizienz in Lernen und Kolaboration

Title Text

Subtitle

Typen von Teams

Title Text

Subtitle

Chaotisch & Unreflektiert :-)

Stream aligned Teams

Stream aligned Teams - Eigenschaften

  • kontinuierliche Feature-Delivery in Produktion
  • schnelle Reaktion auf Daten aus Produktion
  • kontinuierliches Experimentieren
  • wenige Hands-Off zu anderen Teams
  • Kunde der anderen Teams (Subsystem, Enabling, Platform)
  • Autonomy, Mastery & Purpose

PO mit Fokus auf Businessvalue &
Kundennutzen.

Stream aligned Teams - Verantwortung

  • Design and architecture
  • Development and Coding
  • Application Security
  • Commercial and operational viability analysis
  • Infrastructure and operability
  • Metrics and Monitoring
  • Product Management and Ownership
  • Testing and Quality Assurance
  • User Experience 

Stream Aligned Team Trouble

  • Featuredruck vs Innovation
  • Featuredruck vs Entwickeln von Capabilities
  • Teamübergreifendes Lernen
  • Feature Teams brauchen sehr hohe Reife
  • Product Teams brauchen ein Support System
  • Cloud Teams brauchen Infrastruktur

Technical Consulting /
ENABLING Teams

  • Cross-Cutting zu stream aligned teams
  • bandwidth to research
  • develop tools, methodologies etc

Im Normalfall kein PO :-/ - aber andere POs sind Stakeholder.

Enabling Teams

  • sind in kontinuierlichem, regelmäßigem Kontakt zu Teams
  • bei Bedarf auch Teil der Teams
  • sorgen dafür, dass zukünftige Probleme rechtzeitig mit Tooling, Methoden und Ansätzen gelöst werden können 
  • stützen den Technology Lifecycle im Teams
  • erlaubt es, neue und komplexe Technologien zu verstehen und einzusetzen
    • Training, Workshops, HandsOn-Kooperation

SRE Teams

Beispiele für erfolgreiches Enabling

  • 72% schnellere Deployments
  • 7 mal mehr Deploys pro Tag
  • Doppelt so schnelle Analyse / Medium Time to Fix
  • Reduzierung des Aufwandes pro E2E-Test um 50%

Im Normalfall kein PO :-/ - aber andere POs sind Stakeholder.

COMPLICATED SUBSYSTEMS

COMPLICATED SUBSYSTEMS

  • Legacy-Systeme ohne gute Doku?
  • Workflow-Engines
  • das ERP
     
  • Verteilen über mehrere Teams?
  • Als Teilaufgabe in einem Team?
  • Als Feature-Thema in einem Feature-Team?

PO ist selbst Experte für das komplizierte Subsystem.

COMPLICATED SUBSYSTEM Teams

  • Abgetrennte Teams
  • Spezialisten für genau diese Domäne
  • keine anderen Domänen
     
  • Komponententeam, aber mit anderer Motivation
  • Am Anfang viel Interaktion mit anderen Teams
  • Am Ende vor allem Schnittstellen

Title Text

Subtitle

Platform Teams

Stream aligned Overflow

  • streamaligned-Team kümmert sich um  
    • building
    • running
    • fixing
  • das heißt ...
    • monitoring, alerting, reporting, error logging
    • deployment, scaling, failover, redundancy
    • ....

Sollte das nicht Ops machen?

Traditional, Blocking Ops

Platform Teams

  • Dienstleister für die stream-aligned teams
  • verstehen den Bedarf der Teams genau
  • erlauben Self-Service für alle Dinge die häufiger passieren
  • Fokus auf Automatisierung, Usability und Reliability
  • schnelles Prototypen und evaluieren mit den Stream-Aligned Teams
  • Fokus auf Minimierung der kognitiven Last der Teams

PO hat die anderen Teams als Kunde. Servicedesign & Metriken.

Cloud as Platform mit Platform Team

Kooperation zwischen teams

Team Interaction Modes

Collaboration

Enge zusammenarbeit zwischen zwei Teams

Der PO ist voll in der Kollaboration enthalten.

Collaboration

Enge zusammenarbeit zwischen zwei Teams

Vorteile Nachteile
Schnelle Innovation und Entdeckung
Wenige Hand-Offs		 Breite, gemeinsame Verantwortung
Großer Kontext mit vielen Details, hohe kognitive Belastung
Mehr als eine Kooperation parallel ist nicht möglich

X-as-a-Service

Klare Verantwortungen mit vorhersagbarer Delivery und gutem Product Management

Verantwortung für das Servicedesign liegt beim PO.

Vorteile Nachteile
Klare Ownership mit klarer Verantwortung
Reduzierter Kontext nötig
Kleine kognitive Belastung		 Langsamere Innovation über die API
Verlangsamter Fluss bei schlecht gewählter Boundary / API

X-as-a-Service

Klare Verantwortungen mit vorhersagbarer Delivery und gutem Product Management

Facilitating

Erkennen und Reduzieren von fehlenden Fähigkeiten

Facilitating

Erkennen und Reduzieren von fehlenden Fähigkeiten

Im Normalfall kein PO :-/ - aber andere POs sind Stakeholder.

Vorteile Nachteile
Lösen von Blockaden in Stream-Aligned Teams
Erkennen von Lücken und fehlenden Fähigkeiten, Features in Komponenten oder Platform		 Braucht sehr seniorige Leute, die nicht operativ arbeiten
Viele Organisationen sind diess Coaching nicht gewohnt.
 

Facilitating

Erkennen und Reduzieren von fehlenden Fähigkeiten

Gesamtbild

Kollaboration X-AS-A-SERVICE Factiltating
Stream-Aligned Typical Typical Occasional
Enabling Occasional Typical
Complicated Subsystem Occasional Typical
Platform Occasional Typical

Typische
Kooperationsmuster

Und wie komme ich jetzt zu solchen Strukturen?

Reife und Grösse

VOrgehen

  1. Starten mit dem vorhandenen Setup oder mit Minimum Viable Setup

  2. Reverse Conway um Zielarchitektur und Teamstruktur in Einklang zu bringen

  3. Evolution starten :-) 

Evolution: passende Interaktionsmodi erkennen

Evolution: passende Interaktionsmodi erkennen

Von Kooperation aus startend herausfinden wie eine gute API aussehen würde

Evolution: TEmporär in Kooperation gehen

Wenn X-As-A-Service nicht gut funktioniert temporär wieder in Kooperation gehen.

Evolution: X-AS-A-Service für andere nutzbar machen

Organizational Sensing: AWKWARDNESS als Sensor

Wenn man offiziell "as a service" nutzt und im Chat die ganze Zeit fragen stellen muss. 

Wenn man einen neuen Service entwickelt bekommt aber niemals gefragt wird. 

... 

Trigger für Evolution

  • Eine Software ist zu groß für ein Team geworden
  • Lieferfähigkeit wird zunehmend langsamer
  • Hohe Abhängigkeit zu vielen eigenen Services
  • "Zu viele Meetings"

Methoden aus Team Topologies

How to get started

  • Start with the Team
  • Welche Streams brauchen / passen für Veränderung?
  • Was ist der kleinste Ansatzpunkt zum starten?
  • Gaps über Chaoching, Mentoring, Service Management etc feststellen
  • Best Practices sharen & teilen.