Post on 17-Jun-2020
1Agile Skalierung in der Praxis embarc.de
Herausforderungen der agilen Skalierung am Beispiel eines Großprojekts
Stefan Toth | st@embarc.de | st_toth (twitter)
München22. Januar 2019
2Agile Skalierung in der Praxis embarc.de
Stefan Toth
st@embarc.de
xing.to/sto
www.embarc.dewww.swamuster.de
@st_toth
3Agile Skalierung in der Praxis embarc.de
Architektur-Reviews(Quick Check/Bewertung)
Microservices(Technologie/Migration)
Agilität & Architektur(Skalierung/Transformation)
CI/CD, DevOps & Cloud(organisatorisch/technisch)
Softwaredesign(Clean Code/DDD/Metriken)
UI-Architektur(Design/Frameworks)
Dokumentation(Techniken/Governance)
Unternehmensarchitektur(Strategie/Agility/Evolution)
4Agile Skalierung in der Praxis embarc.de
5Agile Skalierung in der Praxis embarc.de
Schnell-EinstiegAgile Skalierung und das Beispielprojekt.
6Agile Skalierung in der Praxis embarc.de
ADES: Lern-Framework für agile Organisationen
7Agile Skalierung in der Praxis embarc.de
ADES – Lernen als individueller Weg
§ Wichtige Eigenschaften vonagilen Organisationen
§ Iterative Optimierung der Lerngebieten
§ Wiederholte Selbstein-schätzung (Spinnennetz)
§ KEIN Maturity Modell
§ KEIN Skalierungs-Framework
§ 6 Lerngebiete. Enthalten Beispiel-Techniken fürExperimente
8Agile Skalierung in der Praxis embarc.de
Unser konkretes Beispiel.Mit echten Problemen.
Flug-Optimierung 2.0
7Agile Skalierung in der Praxis embarc.de
10Agile Skalierung in der Praxis embarc.de
11Agile Skalierung in der Praxis embarc.de
In der Black-Box
Performance Service - LPS
Optimizer Service - LOS
Crew Briefing - LCB
Airport Suitability Check - ASC
Integrated Flight Support - IFS
Aeronautical Information Mgmt - AIM
Air Traffic Management - ATM
Meteorological Service - MET
Message Broker - LMS
Load Balancer - LBS
Configuration Service - LCS
Logging Service- LLS
Authentication Service - LAS
Monitoring System - LMS
Domänenservice
Plattformservice
12Agile Skalierung in der Praxis embarc.de
Airlines als Kunden (stetig wachsend)
Flüge/Tag optimiert (Planung, Optimierung, Monitoring)
Marktanteil (große Airlines in Europa und dem nahen Osten)
6435.000
25%
13Agile Skalierung in der Praxis embarc.de
KontextIn welchem Kontext bewegen wir uns?
14Agile Skalierung in der Praxis embarc.de
400+ Beteiligte
4 Entwicklungsstandorte
Hohe fachliche Komplexität
Problematische Altlösung (ca. 200 Beteiligte)
Ruf nach Business Agility
Eckpunkte
15Agile Skalierung in der Praxis embarc.de
Wie wichtig ist Liefergeschwindigkeit?
Wie wichtig ist Innovation?
Wie wichtig ist Team-Empowerment?
Wo arbeiten die Teams?
Wie komplex und/oder verwoben ist das Produkt?
Was ist der Zeitrahmen um agil zu werden?
Wie problematisch sind Produkt-Defects?
Sehr wichtigNicht wichtig
Sehr wichtigNicht wichtig
Sehr wichtigNicht wichtig
Hochgradig verteiltAlle Co-located
Komplex/verwobenEinfach/lose gekoppelt
Unmittelbare BedrohungLangfristiger Wunsch
katastrophalvernachlässigbar
Scrum-at-Scale™ Business Context
X
X
X
X
X
X
X
16Agile Skalierung in der Praxis embarc.de
Altsysteme
17Agile Skalierung in der Praxis embarc.de
Ursprüngliche Probleme
Interne/externe Qualitäts-ansprüche verfehlt
Keine oder zu lange Feedback-Zyklen
Zu viele Übergaben / zu viel „über den Zaun werfen“
Viele Bottlenecks
Unklare und verteilte Verantwortlichkeiten
Zu langsame Entwicklung
Ineffizienzen und fehlende Automatisierung
Produktion zu weit weg von der Entwicklung
Risikoreiche Auslieferung von neuen Features
Dringender Handlungsbedarf!“
„
18Agile Skalierung in der Praxis embarc.de
Ursprüngliche Einschätzung (2016)§ Wenige Kunden-fokussierte Ziele,
wenig sichtbarer Fortschritt, keine Experimentierkultur
§ Keine selbstbestimmtenTeams, 3 Teams zwischen Entwicklung und Kunden
§ Technischer Monolith, starke Kopplung (auch erschlichen über Daten)
§ Starke Trennung von Architektur und Entwicklung (Standorte), nur Regeln
§ Teilweise gute Praktiken, aber isoliert
§ Seltene Releases, keine Fitness Functions, wenig Austauschplattformen
19Agile Skalierung in der Praxis embarc.de
Ansatz / ErfolgeWie arbeiten wir? Was ist gelungen?
20Agile Skalierung in der Praxis embarc.de
Organisationsmodell heute
21Agile Skalierung in der Praxis embarc.de
Self-Contained Systems (SCS), ”Teilprodukte” in “Product Suite”…
§ Unabhängigkeit fachlich forciert. PO/Backlog pro SCS
§ Großprojekte werden nicht mehr genehmigt. Innovation muss kleinteilig/evolutionär möglich sein
§ Migration als Teil-für-Teil „Strangler“
22Agile Skalierung in der Praxis embarc.de
Freiheit: Vorschläge statt Vorschriften
23Agile Skalierung in der Praxis embarc.de
DaD – Continuous Lifecycle
24Agile Skalierung in der Praxis embarc.de
ADES-Einschätzung (heute)§ Stärkerer Kundenkontakt (+Ziele),
sichtbare Backlogs, viele methodische Experimente
§ Starke Teams (DevOps?), Ziele zu high-level, wenigqualitative Verantwortung
§ Self-Contained Systems, Auflösung von Daten-kopplung (Altsystem naja)
§ Immer noch starke Architektur(Feedback und Responsibility)Erste Vorschläge statt Regeln
§ Im Delivery Bereich Verbesserungen
§ Seltene Releases (noch immer), Community, Blogs, Foren, Talks, ...
25Agile Skalierung in der Praxis embarc.de
Häufig problematisch, aber hier gut:
Strategisches Portfoliomanagement:Migration von Produktbereichen ist geplant und schrittweise
Agile Transition als Weg:Kein schnelles Einführungsprojekt, kein Cargo-Cult
Abhängigkeiten aufzulösen steht im Fokus:Allerdings: Autarkie vs. Zusammenarbeit schwierig auszutarieren
Keine Politik:Führung steht zusammen, keine Grabenkämpfe, gleiche Ziele
Top-Down Veränderung:Projekt/Linie wachsen zusammen, ganzer Wertstrom im Fokus
26Agile Skalierung in der Praxis embarc.de
ErkenntnisseWas nehmen wir aus den letzten Jahren mit?
27Agile Skalierung in der Praxis embarc.de
1Frameworks geben Rahmen, Namen und Akzeptanz. Das ‚wie‘ und der Prozess da hin fehlen aber!
Eine lernende Organisation ist wichtiger als jedes Skalierungsframework.
28Agile Skalierung in der Praxis embarc.de
29Agile Skalierung in der Praxis embarc.de
Ausgangsprobleme von Unternehmen sind sehr unterschiedlich
Der Weg zu „Agilität“ ist nicht immer gleich (einfach, komplex, ...)
Idee von einmaliger, abzuschließender „Transition“ passt nicht
Nur lernende Organisationen sind agil!
Ständige Iterative Verbesserung als Grundlage!
Experimente inkl. inspect & adapt als Treiber!
Neben methodischer und organisatorischer Innovation auch technische Seite interessant
Schablonen behindern beim malen...
Das hier muss man lernen!
30Agile Skalierung in der Praxis embarc.de
“The only Spotify way of working that actually works is turning on the Spotify volume really loud and dance.”— Erwin Verweij
31Agile Skalierung in der Praxis embarc.de
Aufsplittung der Transition macht Abhängigkeitsmanagement nötiger!
2Agile Kommunikation setzt auf ‘gleichzeitige‘ Arbeit von Teams - Das ist im großen Kontext oft nicht der Fall
32Agile Skalierung in der Praxis embarc.de
Meetings im agilen Kontext
33Agile Skalierung in der Praxis embarc.de
Strategische Ablösung von Teilprodukten
Performance Service - LPS
Optimizer Service - LOS
Crew Briefing - LCB
Airport Suitability Check - ASC
Integrated Flight Support - IFS
Aeronautical
Zeit
relativ isolierte Domänen
zum ersten
Mal UI
verwobene Fachlichkeit,
mehrere Teams
34Agile Skalierung in der Praxis embarc.de
Domänen-Teams Abhängigkeiten
35Agile Skalierung in der Praxis embarc.de
Architecture Owner
36Agile Skalierung in der Praxis embarc.de
Architekturrahmen an Ziele des Produkts und der Transition knüpfen!
3Widersprüchliche Qualitäts-ziele müssen aktiv und teamübergreifend bearbeitet werden.
37Agile Skalierung in der Praxis embarc.de
Kontext für Entscheidungen geben
38Agile Skalierung in der Praxis embarc.de
UX vs. SCSs für Monitoring / Planung
39Agile Skalierung in der Praxis embarc.de
Architekturziele - Qualität
Zuverlässigkeit(Reliability)
Ist das System verfügbar, tolerant gegenüber Fehlern, nach Abstürzen schnell wieder hergestellt? ...
Begriffe nach Norm ISO 25010
Funktionalität(Functionality)
Sind die berechneten Ergebnisse korrekt / exakt, ist die Funktionalität angemessen? ...
Wartbarkeit(Maintainability)
Ist die Software leicht zu ändern, erweitern, testen, verstehen? Lassen sich Teile wiederverwenden? ...
Benutzbarkeit(Usability)
Ist die Software intuitiv zu bedienen, leicht zu erlernen, attraktiv?
Sicherheit(Security)
Ist das System sicher vor Angriffen? Sind Daten und Funktion vor unberechtigtem Zugriff geschützt? ...
Kompatibilität(Compatibility)
Ist die Software konform zu Standards, arbeitet sie gut mit anderen zusammen?
Effizienz(Performance)
Antwortet die Software schnell, hat sie einen hohen Durchsatz, einen geringen Ressourcenverbrauch? ...
Portabilität(Portability)
Ist die Software leicht auf andere Zielumgebungen (z.B. anderes OS) übertragbar?
40Agile Skalierung in der Praxis embarc.de
Ziele desVorhabens
41Agile Skalierung in der Praxis embarc.de
Kompromisse klar benennen
User Experience „die Architektur“
42Agile Skalierung in der Praxis embarc.de
Kompromisse klar benennen
UX mit klarerer Trennung von Planungs und Exception/Monitoring Sichten
§ Geringere isolierte Wartbarkeit von SCSs
§ Höhere Komplexität durch feingranulare Abhängigkeiten
§ Kein unabhängiges Updatevon UI-Frameworks in SCSs
§ Keine schrittweise Ablösungvon technischen Lösungen
§ Schwierige Skalierung der Lösung auf kleine Kunden
§ ...
2Ziele:
1Ziele: 4 5 6
7 8
43Agile Skalierung in der Praxis embarc.de
Architektur-/Qualitätsziele
Architektur-/Lösungsansätze
Lösungsstrategie (Tabelle)Architekturziele und zugeordnete high-level Lösungsansätze
Form: Tabelle ([ Ziele | Lösungsansätze ]).
44Agile Skalierung in der Praxis embarc.de
bAkzeptanz ist wichtig, Unterstützungs-leistung sollte klar sein (Qualitätsziele)!
3Architektur-‘marketing‘ ist wichtiger als gute Regeln.
45Agile Skalierung in der Praxis embarc.de
46Agile Skalierung in der Praxis embarc.de
Neben organisatorischem Übergang auch auf Technikübergang achten!
4Trend-Technologien sind handhabbar, die technische Vergangenheit schwieriger. Die Kombination ist komplex.
47Agile Skalierung in der Praxis embarc.de
Altsystemablösung als „Strangler“
MonolithischeAlt-Applikation
NeuesService
MonolithischeAlt-Applikation
Dispatcher
NeuesService
NeuesService
NeuesService
MonolithischeAlt-Applikation
Dispatcher
Inkrementell Wert schaffenSchneller als bei Big-Bang-Migration
Stetiges FeedbackFrühe produktive Verwendung
48Agile Skalierung in der Praxis embarc.de
Klassische Migrationsprobleme
MonolithischeAlt-Applikation
NeuesService
Dispatcher
NeuesService
NeuesService
NeuesService
Dispatcher
Monolithische Alt-Applikation
Monolithische Alt-Applikation
49Agile Skalierung in der Praxis embarc.de
Ablösungsansatz Beispiel
50Agile Skalierung in der Praxis embarc.de
CI/CD-Pipelines und DevOps-Kultur bilden die Basis für viele agile Werte!
5Feinmaschiges Feedback für die Lösung muss früh fokussiert werden.
51Agile Skalierung in der Praxis embarc.de
Betrachtung des Wertstroms
Value Stream Maps sind ein Diagnose- und Planungswerkzeug welches den Zeitstrahl von der Kundenanfrage bis zur Problemlösung abbildet.
Nicht nur die Entwicklung betrachten und optimieren!
52Agile Skalierung in der Praxis embarc.de
Entwicklung bis Kunde...
Entwicklungs-team
Entwicklungs-team
Entwicklungs-team
SourceControl
DeliveryControl
Help Desk
150-200 Prod.-Env....
Tage bis Wochen
code,test
Integr.(test)
pkg,deploy preload,install,ops
Kein Monitoring(verteilte Logs)
Manuelle Config(Problem bei Redeploy)
Hohe Fehlerrate(wenige Tests)
Langer Prozess(keine Automatisierung)
(vor 2016)
53Agile Skalierung in der Praxis embarc.de
ADES-Einschätzung (heute)
Start der DevOps Initiative im Sept. 2016
Fokusthemen:§ Infrastruktur: Hardware (physikalisch,
virtualisiert, cloud), Netzwerke, Docker Infrastruktur, DR (disaster recovery), BC (business continuity)
§ Security: TSL/SSL, PKI, Security Testing§ Continuous Integration: Versionskontrolle,
Test/Build/Deployment Automatisierung§ Monitoring & Logging: inkl. Analyse§ Configuration: Configuration Services,
Infrastructure as Code§ Technische Dokumentation: Struktur,
Tutorials, Guidelines
54Agile Skalierung in der Praxis embarc.de
Häufige Wiederholung des Zwecks von allen Initiativen, Ziele konkret machen!
6Transitionsziele müssen runtergebrochen werden um auf unteren Ebenen Verant-wortung zu generieren.
55Agile Skalierung in der Praxis embarc.de
Fligh
t Lev
el 1
Flight Levels
Operative Ebene1 Team / 1 (Teil-)Produkt: Die tägliche Arbeit erledigen und optimieren
Verbesserung bis an Team-Grenzen, ggf. Schwierigkeiten in anderen Teams
Fligh
t Lev
el 2 Koordination
n Teams / 1 Produkt: Fokus auf schaffen von echtem Kundenwert
Regelmäßige, teamübergreifende Abstimmung mit Vertretern aus allen Teams in Stand-up, Daily etc.
Fligh
t Lev
el 3 Strategisches Portfoliomanagement
n Teams / n Produkte: Vielzahl von Projekten/Produkten managen und strategisch planen
Im Mittelpunkt steht das Gesamtergebnis der Organisation
siehe Dr. Klaus Leopold
56Agile Skalierung in der Praxis embarc.de
Lücke auch von Management erkannt
57Agile Skalierung in der Praxis embarc.de
OKRs – Objective Key Results
objective
this set of key results
§ Teams setzen sich wenige, aber inspirierende Objectives(oft quartalsweise, nicht unbedingt nur durch ihre eigene Arbeit erreichbar)
§ Teams stimmen sich in Alignments miteinander und mit oberen Ebenen ab § Key Results sind konkret und messbar (2-5 pro Objective)§ Initiativen ableiten, um Objectives zu erreichen (Tasks, Aktivitäten, Epics)
wor
kin
prog
ress § Einführung aufwendig! 25 Wochen und nicht in der Breite.
§ Top-Down Definition zur Orientierung wichtig
§ Aufwand und Integration in Process? Experimente notwendig!
58Agile Skalierung in der Praxis embarc.de
Achtung vor ‚falschen‘ Problemen und voreiligen Rollen-‘Optimierungen‘!
7Wirklich agile Denkweise zu etablieren muss lange im Fokus sein. Gerade bei sehr langer klassischer Historie.
59Agile Skalierung in der Praxis embarc.de
1: Kultur, Vertrauen, Führung, ... Historie
GER POL IND
60Agile Skalierung in der Praxis embarc.de
Autonomie UND Alignment = schwierig
Henrik Kniberg(Spotify Labs Blog)
61Agile Skalierung in der Praxis embarc.de
2: Root-Cause-Analyse - Delivery Issues
62Agile Skalierung in der Praxis embarc.de
Kommunikation
§ Cross-Team Exchange Meetings
§ Domain Talks§ DevOps Talks§ DevOps Week§ Open Lunch Bunch§ Compass – Ideen und
Fragenbereich
§ Wiki-Spaces mit Forumscharakter§ Retrospektiven (monatlich
Teamübergreifend)§ Blog§ OKR 360º Alignment§ OKR
A: XY macht seine Arbeit nicht, mit
dem Ergebnis kann ich nichts
anfangenB: Hast Du mit XY gesprochen?
A: Nein, ich hab mir das Draft-Dokument angesehen.
B: ...Gute Prozesse verhindern Interaktion?
Unklarheiten sind fehlendes Management?
63Agile Skalierung in der Praxis embarc.de
Rollen im Planning Poker “schärfen“?
Nicht zu früh!
64Agile Skalierung in der Praxis embarc.de
BonusWeitere Erkenntnisse undHerausforderungen ohne Lösung...
65Agile Skalierung in der Praxis embarc.de
Verteilte, diverse Kundenlandschaften brauchen methodische Unterstützung!
8Kundenzusammenarbeit muss auch in schwierigen Kontexten voran getrieben werden.
66Agile Skalierung in der Praxis embarc.de
Betrachtung des Wertstroms
Value Stream Maps sind ein Diagnose- und Planungswerkzeug welches den Zeitstrahl von der Kundenanfrage bis zur Problemlösung abbildet.
Nicht nur die Entwicklung betrachten und optimieren!
67Agile Skalierung in der Praxis embarc.de
Von der Idee zur Entwicklung
P-Mgmt
RE /Spezialisten
UX
Epics
Stories
Tasks
PO
Team
Goals?
Kunden KundenKunden
68Agile Skalierung in der Praxis embarc.de
Grundlagenarbeit von UX-TeamUser Journey Map...
„UX-Team kam zu spät“
- stimmt wegen UX, aber auch wegen agilem
Anforderungsprozess (vorderer Wertstrom-Teil)
69Agile Skalierung in der Praxis embarc.de
Herausforderungen ohne momentane Lösung:
§ Größe des Vorhabens & räumliche Verteilung
§ Fluktuation an Standorten
§ Gleichzeitige Entwicklung für Neu und Altsystem (organisatorisch und methodisch)
§ Fachliche Komplexität (Themen runterbrechen, Expertisenverteilung, Eigenständigkeit POs)
§ Fokussierung und Überblick im Transition-Management
70Agile Skalierung in der Praxis embarc.de
Im ÜberblickZusammengefasst...
71Agile Skalierung in der Praxis embarc.de
Erkenntnisse§ Eine lernende Organisation ist
wichtiger als jedes Skalierungs-framework.
§ Agile Kommunikation setzt auf ‘gleichzeitige‘ Arbeit von Teams -Das ist oft nicht der Fall.
§ Widersprüchliche Qualitäts-ziele müssen aktiv und team-übergreifend bearbeitet werden.
§ Architektur-‘marketing‘ ist wichtiger als gute Regeln.
§ Trend-Technologien sind handhabbar, die technische Vergangenheit schwieriger. Die Kombination ist komplex.
§ Feinmaschiges Feedback für die Lösung muss früh fokussiert werden.
§ Transitionsziele müssen runtergebrochen werden um auf unteren Ebenen Verant-wortung zu generieren.
§ Wirklich agile Denkweise zu etablieren muss lange im Fokus sein. Gerade bei sehr langer klassischer Historie.
§ Kundenzusammenarbeit muss auch in schwierigen Kontexten voran getrieben werden.
§ (Transitions-Board, Erfolgsindikatoren oder Innovations-Tokens helfen wohl)
72Agile Skalierung in der Praxis embarc.de
Danke.Jegliche Fragen sind willkommen!
stefan.toth@embarc.de
xing.to/sto
@st_toth
73Agile Skalierung in der Praxis embarc.de
Spicken erlaubt! Unsere Architektur-Spicker beleuchten die konzeptionelle Seite der Softwareentwicklung.
Bisher erschienen:
#1 Der Architekturüberblick#2 Quantitative Analyse#3 Microservices#4 Architektur-Reviews#5 Cloud-Anwendungen#6 Agile Architektur#7 Continuous Delivery
PDF, 4 - 6 SeitenKostenloser Download.
è https://www.embarc.de/architektur-spicker/