Team Setups für Modernisierung

Component-Teams

• Meist ein Team für 1-3 technische Komponenten
• Langlebig - solange die Komponente besteht existiert das Team.
• Oft bei Monolithen, zB Frontend/Backend-Teams
• Manche Komponenten sind im Maintenance-Modus
• Das Team kann zum Engpass für die Komponente werden
• Features basieren meist auf mehreren Komponenten
• Funktioniert auch mit geringer technischer und organisatorische Reife.

Feature-Teams

• long-lived—the team stays together so that they can ‘jell’ for higher performance; they take on new features over time
• cross-functional and cross-component
• co-located
• work on a complete customer-centric feature, across all components and disciplines (analysis, programming, testing, …)
• composed of generalizing specialists
• in Scrum, typically 7 ± 2 people
•  

Im Monolithen

Monolithic Delivery

Build-run-Teams

• Sowohl Feature als auch Component-Teams
• Volle Verantwortung für alle Features von einer Komponente
• Nur auf Basis von Micro/Mini-Service-Architekturen machbar
• Kann weitgehend autark agieren - von GUI zu Deploy
• Mit den anderen Komponenten
  wird über APIs geredet.

Build-run-Teams

Platform Team

• Eigenständiges Team, das sich um Auswahl, Aufbau und Konfiguration des Basissets von Werkzeugen und Praktiken, die von allen Teams genutzt werden, kümmert.
• Selbst ein Built-Run-Team für die Platform.
• Fokus ist sowohl Stabilität der Platform als auch Performance und Arbeitserleichterung für die anderen Teams

Service Delivery

Das Start-Dilemma

• Die Plattform existiert noch nicht
  • es fehlt die neue Infrastruktur
  • es fehlen Services und Beispiele, die sie nutzen
• Die alte Plattform muss auch weiterbetrieben werden
• Die Kollegen kennen die neuen Technologien noch nicht

Core Team

• Das erste Team für die neue Platform
• Drei Deliveries: 
  • die neue Platform
  • Architektur und Beispiele 
  • Bootcamp, Onboarding & Schulung
• HandsOn-Aufbau der neuen Plattform
• Geht später in Platform-Team und BR-Teams auf.

MVP Platform

• Wird vom Core Team gebaut
• Sobald es von anderen nutzbar ist können auch andere Teams darauf aufsetzen
• nach ca 2 Monaten vorhanden
• 20%-40% der finalen Plattformfeatures
• Experimente und PoC gehören dazu.

Zeitlinie

Zeitlinie

Strangle Monolithic Organization

• Man muss nicht nur die Technik, sondern auch die Leute modernisieren
• Dilemma: Nur Legacy machen ist doof, neues Knowhow ohne Anwendung ist doof 
• Also graduelles Onboarding, Team für Team
• Mit einer klaren Roadmap für Technik und Organisation(!)
• Alignment von Technik, Orga und Knowhowaufbau

When it's done: SRE-TEams

• Wenn alles läuft uns sich jeder um seinen Kram kümmert ...
• ... wer kümmert sich um die Verbesserung des ganzen?
• die besten Engineers kommen ins SRE-Team
• 50% Reliability, 50% Verbessserung der internen Prozesse und Dev-Praktiken
• Verantwortlich für Error Budgets & Hilfe durch Automatisierung