Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Nobody is left behind

Nobody is left behind

In jedem Unternehmen übernehmen einige Teams neue Technologien und Prozesse schneller als andere. Einerseits fördern wir die Entwicklung dieser Teams, andererseits unterstützen wir diejenigen, die dieses Tempo nicht halten können, damit sie ebenfalls von diesen Verbesserungen profitieren und nicht zurückbleiben – entgegen dem Two-Speed-IT-Paradigma, damit keine einschränkenden Abhängigkeiten zwischen den entsprechenden Anwendungen für beide Parteien entstehen.

In der Präsentation werden Patterns vorgestellt, um mit diesem Risiko umzugehen. Dazu gehören neben technischen und organisatorischen Maßnahmen auch Knowledge Sharing, um diesen Ansatz unternehmensweit zu implementieren.

Hermes Germany GmbH

June 23, 2022
Tweet

More Decks by Hermes Germany GmbH

Other Decks in Technology

Transcript

  1. Nobody is left behind.
    Stephan Stapel
    Hermes Germany GmbH

    View full-size slide

  2. 01 Intro.
    02 Technische Patterns.
    03 Organisatorische Patterns.
    04 Sharing Knowledge.
    05 Erkenntnisse.
    Inhalt

    View full-size slide

  3. Hermes ist in Deutschland
    die Nr. 2 in der B2C-Paketzustellung
    und der Marktführer im Großstücksegment.
    11.000 Zustellende liefern für Hermes aus.
    Bis zu 2,5 Mio. Zustellungen am Tag.

    View full-size slide

  4. Unser Ansatz.
    DevOps ist unser Betriebssystem.
    Continuous Delivery.
    Unsere Strategie seit 2017.

    View full-size slide

  5. Dies hat uns deutliche
    Verbesserungen ermöglicht.
    Deutliche Geschwindigkeits-Steigerung.
    Höhere Qualität, höhere Sicherheit.
    Hohe Durchdringung mit Cloud-Technologie.

    View full-size slide

  6. Wir haben festgestellt, dass unsere
    Teams in unterschiedlichen
    Geschwindigkeiten arbeiten.

    View full-size slide

  7. Wir glauben, dass
    Two-Speed-IT schädlich
    für eine Tech-Kultur sind.
    Die Organisations-Entwicklung wird komplizierter.
    Wir wollen verhindern, dass es Verlierer in der
    Transformation gibt.
    Es braucht Anstrengung, alle Teams für die
    Transformation zu gewinnen.

    View full-size slide

  8. Ich werde die Begriffe Langsames
    System-Team bzw. Schnelles
    System-Team nutzen.

    View full-size slide

  9. Wir haben zwei
    Hauptgründe für
    Langsamkeit gefunden.

    View full-size slide

  10. #1
    Komplexe Logik.
    Zu viele Domains, die in einer Applikation
    adressiert werden.
    Oder: Zu viele Abhängigkeiten, die
    Aufmerksamkeit erfordern.
    Oder: Der Test-Scope ist zu groß. Test-
    Szenarien sind schwer zu erzeugen.
    #2
    Technische Basis.
    Es wird Technologie eingesetzt, die nicht dazu
    gedacht ist, kontinuierlich zu deployen.
    In unserem Fall: vor allem JEE-Container.
    Oder: Wegwerf-Architekturen, ohne Gedanke an
    dauerhafte Weiterentwicklung.

    View full-size slide

  11. Kein Grund (in unserem Fall):
    Team-Setup.
    Wir haben in unserem Umfeld keine Beispiele, wo Team-Kapazität die Ursache war.
    Wir haben auch keinen Fall, wo Fähigkeiten oder Ausbildung die Ursache war.

    View full-size slide

  12. Keines der gefundenen Gründe
    kann einfach gelöst werden.

    View full-size slide

  13. 02
    Einige technische Patterns helfen uns, um die
    Zusammenarbeit mit Teams mit langsamen
    Systemen zu erleichtern.

    View full-size slide

  14. Pattern #1
    Abhängigkeiten isolieren.
    Schnelles
    System
    Langsames
    System
    Adapter zum
    langsamen
    System
    Häufiges Muster: Abhängigkeiten
    werden explizit gemacht und
    isoliert durch das Implementieren
    eines dedizierten Adapters zum
    langsamen System.
    Dies ermöglicht es zum einen,
    beidseitig den Impact von
    Veränderungen zu reduzieren.

    View full-size slide

  15. Pattern #2
    Kontrakte nutzen, um Implementierungsphasen
    zu entkoppeln.
    Schnelles
    System
    Langsames
    System
    Teams verständigen sich auf
    einen expliziten
    Schnittstellenkontrakt.

    View full-size slide

  16. Pattern #2
    Kontrakte nutzen, um Implementierungsphasen
    zu entkoppeln.
    Nach der Synchronisation für die
    Kontrakterstellung geschieht die
    Implementierung in der
    jeweiligen Geschwindigkeit.
    Der Go-Live ist der zweite
    Synchronisations-Punkt.
    t
    t
    Sync
    Sync
    Go-Live
    Team S
    Team L
    Implementierung

    View full-size slide

  17. Pattern #3
    Gemeinsame Entwicklung.
    Schnelles
    System
    Langsames
    System
    • Kooperation
    • Pull Request

    View full-size slide

  18. 03
    Patterns für die organisatorische Entwicklung.

    View full-size slide

  19. Niemals aufgeben, die
    Teams verbessern zu
    wollen.

    View full-size slide

  20. Langsame System-Teams
    bieten einen großen
    Wert in unserer
    Organisation.
    20
    Sie arbeiten häufig lange in der
    Konstellation zusammen.
    Es handelt sich meist um sehr erfahrene
    Kollegen, anerkannte Experten in ihren
    Business-Domains.

    View full-size slide

  21. Langsame System-Teams
    sind oft Dreh- und
    Angelpunkt.
    21
    Langsamkeit darf nie als Waffe eingesetzt
    werden.
    Es ist wichtig, die eigene Bedeutung für die
    Anwendungslandschaft zu verstehen:
    Innovationen anderer (schnellerer) Teams
    kann behindert werden durch
    Abhängigkeiten zu Langsame System-
    Teams.
    Wir müssen die Atmosphäre zwischen den
    Teams im Blick behalten.

    View full-size slide

  22. Pattern #1
    Dein eigenen Takt finden.
    Die organisatorische Arbeit mit Langsame System-Teams
    sollte nicht abrupt geschehen. Stattdessen braucht es
    eine Schritt-für-Schritt-Entwicklung.
    Beispiel:
    Echte Continuous Delivery ist meist schwer zu erreichen.
    Einmal pro Sprint verlässlich zu deployen, ist meistens
    möglich.
    So fühlt sich jedes Team als Teil der organisatorischen
    Entwicklung.

    View full-size slide

  23. Pattern #2
    Die Spur halten.
    Die Entwicklung aller Teams muss im Blick behalten
    werden, insbesondere auch der Langsame System-
    Teams.
    Es ist einfach, sich in einer großen Organisation zu
    verstecken. Oder sich zu verlieren.
    Sicherstellen, dass das Leadership/ Team-Verhältnis eine
    gute Betreuung ermöglicht.
    Bend-and-wait ist keine Option!

    View full-size slide

  24. Pattern #3
    Nachhaltigkeit.
    Kontinuierliche Arbeit mit dem Team, an den Prozessen
    und an der Technologie sind notwendig. Und möglich.
    Vorteile von Innovationen verdeutlichen. Übersetzen,
    Adaptieren der Innovationen ermöglichen.
    Beispiel:
    Application Monitoring ist eine gute Investition. Selbst
    dann, wenn es in den vergangenen Jahren keine Ausfälle
    gab.

    View full-size slide

  25. 04
    Wissen teilen.

    View full-size slide

  26. Wir experimentieren mit
    verschiedenen Formaten.
    Keine Einbahnstraße.
    Interne IT-Messen, um voneinander zu lernen. Sowohl aus
    einer fachlichen als auch aus einer technologischen
    Perspektive.
    Offene Sprint-Reviews → gut investierte Zeit.
    Communities of Practice, um Wissen zu
    vergemeinschaften, aufzubereiten und zu teilen.

    View full-size slide

  27. 05
    Unsere Erkenntnisse.

    View full-size slide

  28. Gibt es Auswirkungen auf unser
    Geschäft?
    “Früher haben wir unsere Call Center-Agents
    intensiv für jedes Release trainiert. Daher waren wir
    sehr zurückhaltend bei der Idee, dass unsere Kern-
    Applikation alle 3 Wochen live gehen soll.
    Da die Änderungen allerdings so Klein sind, die alle 3
    Wochen in die Applikation einfließen, reicht es, diese
    geeignet zu erklären und Release-Trainings
    komplett zu streichen.”
    – Christine, Trainer, Customer Service

    View full-size slide

  29. Unsere Erkenntnisse.
    Es gibt keinen Universal-Ansatz für eine solche Transformation.
    Teams verändern sich in unterschiedlichen Geschwindigkeiten.
    Es braucht die kontinuierliche Arbeit mit Teams, auch wenn
    moderne Technologien nicht einfach adaptiert werden können.
    Das ist aufwendig.
    Der Aufwand lohnt sich, um glückliche Mitarbeiter und eine
    gesunde Tech-Kultur zu erreichen!

    View full-size slide

  30. Stephan Stapel
    Head of Development
    [email protected]
    @StephanStapel
    https://www.linkedin.com/in/stephan-stapel
    Diese und weitere Präsentationen auf
    https://speakerdeck.com/hermes/

    View full-size slide