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