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.

Transcript

1. Nobody is left behind. Stephan Stapel Hermes Germany GmbH
2. 01 Intro. 02 Technische Patterns. 03 Organisatorische Patterns. 04 Sharing Knowledge. 05 Erkenntnisse. Inhalt
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.
4. Unser Ansatz. DevOps ist unser Betriebssystem. Continuous Delivery. Unsere Strategie seit 2017.
5. Dies hat uns deutliche Verbesserungen ermöglicht. Deutliche Geschwindigkeits-Steigerung. Höhere Qualität, höhere Sicherheit. Hohe Durchdringung mit Cloud-Technologie.
6. Wir haben festgestellt, dass unsere Teams in unterschiedlichen Geschwindigkeiten arbeiten.
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.
8. Ich werde die Begriffe Langsames System-Team bzw. Schnelles System-Team nutzen.
9. Wir haben zwei Hauptgründe für Langsamkeit gefunden.
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.
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.
12. Keines der gefundenen Gründe kann einfach gelöst werden.
13. 02 Einige technische Patterns helfen uns, um die Zusammenarbeit mit Teams mit langsamen Systemen zu erleichtern.
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.
15. Pattern #2 Kontrakte nutzen, um Implementierungsphasen zu entkoppeln. Schnelles System Langsames System Teams verständigen sich auf einen expliziten Schnittstellenkontrakt.
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
17. Pattern #3 Gemeinsame Entwicklung. Schnelles System Langsames System • Kooperation • Pull Request
18. 03 Patterns für die organisatorische Entwicklung.
19. Niemals aufgeben, die Teams verbessern zu wollen.
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.
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.
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.
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!
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.
25. 04 Wissen teilen.
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.
27. 05 Unsere Erkenntnisse.
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
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!
30. Stephan Stapel Head of Development stephan.stapel@hermesworld.com @StephanStapel https://www.linkedin.com/in/stephan-stapel Diese und weitere Präsentationen auf https://speakerdeck.com/hermes/