Teamstrukturen für SOftwaremodernisierung

Legacy-Monolith-Team

Core Team

SRE-Team

Platform Team

Service 1 Team

Legacy-Monolith-Team

Core Team

SRE-Team

Platform Team

Service 1 Team

Chief Tailwind Officer • Founder

Agile Coach • Scrum Master • Product Owner

15 Jahre Projektmanagementerfahrung und seit 2015 als Agile Coach in Projekten tätig. Seine Leidenschaft ist es, Menschen & Teams zu inspirieren und für ihre Aufgabe zu begeistern, damit sie fokussierter und motivierter wertschöpfende Produkte erzeugen können.
Programmiert seit 1984 und verdient seit 1992 sein Geld mit Software. Ein Hacker gone Management mit viel Erfahrung als CTO, Founder, Advisor und Investor, mit Spaß an Architektur, Leadership, Agile, DevOps und natürlich Security.

Warum überhaupt
Modernisieren?

Abhängigkeiten

Externe Faktoren

Google ... Chrome Apps
... AngularJS
... Fabric
... Plus

Compliance & Security

Externe Faktoren

Geänderte Aufgabenstellungen

Externe Faktoren

Software Aging

Innere Faktoren

Wartbarkeit &
Erlernbarkeit

Innere Faktoren

Bugs und Features
Dauern lange

Innere Faktoren

Fluktuation &
Brain Drain

Innere Faktoren

Also: Modernisieren!

Schlechtes Timing:
Modernisierungen
vs Cloud Native

Refactoring

statt

REENGINEERING

Gescheiterte Modernisierungsansätze

Featurefreeze & Zeitbudget für Modernisierung

Gescheiterte Modernisierungsansätze

Alles NEU!

Ein neues Team erstellt eine neue Software.
Während das alte Team neue Features in die alte baut.

Gescheiterte Modernisierungsansätze

74% of organisations have started a modernisation program but failed to complete it.

2020 Mainframe Modernisation Business Barometer

 

 

Success Rate for Replacements:  26%"

2020 Standish Group Endless Modernisation

Gescheiterte Modernisierungsansätze

Projekt "Phönix 7"

Gescheiterte Modernisierungsansätze

Wir kennen alle Features,
Wir können Greenfield mit
neuen Technoligien Anfangen und Scheitern trotzdeM??

Wie wird Software

mit teams entwickelt?

Cross-functional First Try

DevbizUXsecops

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"

Inverse/Reverse Conway Maneuvre

Micorservices/You build it, you run it!

Mental Load bei Microservices

Intrinsisch

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

Wie viele Dinge muss ich berücksichtigen?

Wie interagieren die Dinge miteinander?

EXTRINSISCH

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

Lernbezogen

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

SUM(INTRINSISCH
        +EXTRINSISCH
        +LERNBEZOGEN)
<= CONST

Team-archetypen nach Team topologies

Complicated-subsystem team

Enabling team

Stream-aligned team

Platform team

Stream aligned Teams

Platform Teams

Enabling Teams (technical Consulting)

COMPLICATED SUBSYSTEMS

Team Interaction Modes

(Kommunikationsmuster)

Collaboration

Enge zusammenarbeit zwischen zwei Teams

X-as-a-Service

Klare Verantwortungen mit vorhersagbarer Delivery und gutem Product Management

Facilitating

Erkennen und Reduzieren von fehlenden Fähigkeiten

Lern Loops

Warum Modernisierungen noch schlimmer sind

Die gealterte Software
IST BEREITS zu KOMPLEX

 Extrinsische und intrinisische
Kognitive Last / Technisch

HÖHERE QUALITÄT BRAUCHT
METHODE - CrafterShip

lernbezogene Kognitive Last / Methodisch

Empirisch gesehen produziert das existierende Setup genau die Art von Software, die man jetzt ablösen will.

DIE NEUE PLATFORM MUSS
ERST ERLERNT WERDEN

lernbezogene kognitive Last / Technisch

NEVER TRUST YOUR FIRST TRY.

 lernbezogene Kognitive Last / Technisch

Shu Ha Ri gilt auch bei neuen Plattformen

Neuen Plattformen brauchen
Anderes Knowhow
von AWS zu KUBECTL

Kognitive Last / Technisch

Cloud-Native Arbeitsweisen brauchen Observability -
und ARCHITEKTURKNOWHOW

Kognitive Last / Technisch

Built-Run-Teams braucht
neue Arbeitsweisen

Von On-Call-Duty über Incident Management bis Post Mortem-Kultur

lernbezogene kognitive Last / Methodisch

Neue Rollen, Ansprechpartner und Kooperationen

Kognitive Last/ Organisation und Kooperation

Genau deshalb kommen die Team Topologies als explizites Werkzeug aus der DevOps-Bewegung.

Storming, Norming &
Politik

Kognitive Last/ Organisation und Kooperation

einer WELT mit ÜBERLAST lade ich noch deutlich mehr auf.

74%

Ansätze zum Umgang
DAMIT

Fokus:
Dämpfung von
Mentaler LAST

Alte Software

Neue Platform

Methoden & Struktur

MAX

  • Software

  • Teamstruktur

  • Knowhowaufbau

gemeinsam behandeln

  • Self-Service

  • Reproduzierbare (DEv-) Environments

Stream Aligned Team

X-AS-A-Service

Blue prints
Referenzarchitekturen
Golden Paths
Bootcamps

Stream Aligned Team

X-AS-A-Service

lernbezogene kognitive Last / Technisch

Developer Portals

https://backstage.spotify.com/

Developer Experience wird ZUR Organisationsaufgabe

  • Die Pioniere für die neue Plattform
  • erste Version der 
    • neuen Platform
    • eines neuen Service
    • des neuen Toolings
    • des Onboardings
  • Experimente, PoCs

https://www.cnpatterns.org/organization-culture/core-team

Core team

Core-Team

MVP Platform

  • Sobald es von anderen nutzbar ist können auch andere Teams darauf aufsetzen
  • nach ca 2 Monaten vorhanden
  • 20%-40% der finalen Plattformfeatures

    Basis-Infrastruktur für die ersten Siedler

https://www.cnpatterns.org/organization-culture/mvp-platform

Graduelles Onboarding

https://www.cnpatterns.org/organization-culture/gradual-onboarding

  • Team für Team wird in Kollaboration
    auf die neue Plattform gehoben
     
  • Knowhowaufbau beginnt
    vor tatsächlichem Einsatz
     
  • das Core-Team supported und
    trainiert aktiv

Graduelles Onboarding

https://www.cnpatterns.org/organization-culture/gradual-onboarding

Legacy-Monolith-Team

Core Team

Enabling
Core-Team

Service 2 Team

Service 1 Team

Die ALT-Software
ist ein Complicated Subsystem

Legacy-Monolith-Team

Core Team

Enabling
Core-Team

Service 2 Team

Service 1 Team


Extraktion/Integration
VON APIs

Legacy-Monolith-Team

Service 2 Team

API-Definition & Integration: Kollaboration

Legacy-Monolith-Team

Service 2 Team

Nach Fertigstellung: NIL / X-As-A-Service


Divide & Conquer

Legacy-Monolith-Team

Extraction-Team

Service-Extraktion: Kollaboration

Legacy-Monolith-Team

Extracted-Service-Team

Nach Extraktion: NIL / X-As-A-Service

Enabling
Core-Team

Temporäre
Kollaboration
für Komplexe
Aufgabenstellungen

Legacy-Monolith-Team

Extracted-Service-Team

EnablingCore-Team

Beratung,
Event storming oder Wardley Maps

Service 1 Team

Service 2 Team

Enabling
Core-Team

Legacy-Monolith-Team

Facilitating

PLATFORM-Team

https://www.cnpatterns.org/organization-culture/platform-team

  • Übernimmt die Platform vom
    Core-Team
     
  • Ist selbst ein Product-Team
     
  • die Stream-aligned Teams
    sind der Kunde

Strangler-Fig-
Pattern

https://cmfirstgroup.com/modernize-with-the-strangler-application-pattern-and-microservices/

Strangle Monolithic Organization

https://www.cnpatterns.org/organization-culture/strangle-monolithic-organization

SRE ERSETZT Core-Team

https://www.cnpatterns.org/organization-culture/sre-team

Stream-Aligned Team 1

SRE-Team

Platform Team

Stream-Aligned Team 2

SRE-
Team

Platform Team as a Service

EVOLUTION über
Learning-Loops & SENSING

https://teamtopologies.com/book

Spotify? LESS?
Safe 5.1: Evolution != Design

https://teamtopologies.com/book

Ziel:
Evolutionäre Organisation mit evolutionärer Architektur

3 Phasen:

  1. Bootstrap: Core, Platform-MVP

  2. Modernisierung: onboarding & Strangling

  3. evolution

Woran wir schon scheiterten

Zu wenig zeit, zu wenig Leute:

Mehr Mental Load bedeutet
mehr Aufwand und mehr Kalenderzeit

Balance zwischen
Cost of Delay
Und Zeit zum
Lernen

Organisations- und
Personalkarussel ist zusätzliche Mental Load 

Politik und intransparenz verhindert lernen und adaption.

Empfehlungen

Cloud Native Transformation Patterns

Tools for creating effective Cloud Native architecture—and remaking the way we work

Team Topologies

Team Topologies

Organizing business and technology teams for fast flow

Viel Glück!😀

… und vielen Dank für eure Aufmerksamkeit🙇🏼

 

Landsberger Straße 314
80687 München

fon(089) 242054 - 11 77
fax(089) 242054 - 29

Copy of Teamstrukturen für Softwaremodernsierung

By Johann-Peter Hartmann

Copy of Teamstrukturen für Softwaremodernsierung

  • 264