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
-
Starten mit dem vorhandenen Setup oder mit Minimum Viable Setup
-
Reverse Conway um Zielarchitektur und Teamstruktur in Einklang zu bringen
-
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.
Team Topologies vs Product Owners
By Johann-Peter Hartmann
Team Topologies vs Product Owners
- 746