Scaled Agile in der Praxis. Scrum Day, Böblingen am

Transkript

1 Scaled Agile in der Praxis Scrum Day, Böblingen am

2 Agenda 1 Scaled Agile Chancen, Prinzipien, Hürden, Frameworks Fall #1 Wincor Nixdorf: Scaled Agile Transformation im Software-Business Fall #2 Niederländische Bank: Scaled Agile Projektportfolio-Management Fall #3 Internet-Provider: Scaled Agile Programm-Management 5 Erfolgsfaktoren für eine Scaled Agile Transformation 2

3 Wir sind überzeugt von den Prinzipien von Agile und wir haben den Nutzen von Scrum erlebt. Agile Prinzipien Agiler Nutzen! Frühe und regelmäßige Lieferungen! Ermächtigung und Selbstorganisation! Überprüfung und Anpassung! Transparenz! Timeboxing 3

4 Bei der Umsetzung stoßen wir alle an die Glasdecke der Scrum Verbreitung. Es geht nicht weiter. Scrum verbreitet sich nicht von alleine Scrum ist keine Antwort für alle Teams Scrum liefert keine Antworten zur Zusammenarbeit mehrerer Teams und für die Gestaltung eines durchgängigen Wertstroms. 4

5 Wir benötigen Antworten auf die Koordination mehrerer Teams und die Rolle der Führung. Dies nennen wir Skalierung. 5

6 Frameworks wie SAFe und LeSS sind nützlich um Lösungsideen zu entwickeln. Man sollte sie aber nicht als Blueprints nutzen. All models are wrong, but some are useful. George Box! Wrong: Ausrollen von Blueprints hat noch nie funktioniert.! Useful: Blueprints sind nützlich, um ein Zielbild zu entwickeln. 6

7 Wir haben aus den Frameworks und unserer Erfahrung die Konstruktionsprinzipien entwickelt, um individuelle und stabile Kundenlösungen zu gestalten. 1. Die Skalierung organisiert eine Koordination mehrerer Teams in Richtung eines gemeinsamen Ziels. Diese Koordination hat zwei Aspekte: Vertikale Koordination bricht Ziele und Aufgaben herunter. Horizontale Koordination verbindet Teams. 2. Die Skalierung ist fraktal. Sie nutzt die selben Elemente im großen (Organisation) wie im kleinen (Team): Takt bzw. Zeitscheiben Arbeitszyklus mit PDCA Rollen mit Produkt-, Prozess- und Erstellungsverantwortung Artefakte 3. Die Skalierung organisiert eine Koordination der Architektur 4. Die Skalierung beinhaltet Lean Management 5. Die Skalierung definiert klare Spielregeln und entsteht emergent 7

8 Die operative Ebene ist das Team. LeSS und SAFe nutzen dafür Scrum. 8

9 Die Lösung von LeSS zur Koordination von Teams mit einem gemeinsamen Ziel: gemeinsame Ereignisse. 9

10 Die größere Lösung von SAFe: ein PDCA Zyklus, der auf einer höheren Abstraktionsebene arbeitet (taktische Ebene). 10

11 Auf der taktischen Ebene werden Features behandelt, die sich in 2-3 Monaten umsetzen lassen. Auf der Teamebene werden Stories behandelt, die sich in 1-4 Wochen umsetzen lassen. Stories Features 11

12 Die strategische Ebene dient dazu, das Portfolio mehrerer taktischer Einheiten (z.b. Programme) zu koordinieren. 12

13 Auch auf der strategischen Ebene setzen wir einen PDCA Zyklus um. 13

14 Scaled Agile Framework (SAFe) von Dean Leffingwell ist ein bekanntes Framework für Skalierung, das Team, Programm und Portfolio-Ebene detailliert definiert. Vorteile:! Hilft bei der Vision! Programm und Portfolio-Ebene sind konsequent durchdacht! Viele Techniken! Klassische Begriffe machen Adoption scheinbar einfach Nachteile:! Häufig andere Begriffe als in Scrum! klassische Begriffe verschleiern Transformationsbedarf und machen Adoption für Agilisten schwer! Tailoring schwierig weil muss und kann unklar 14

15 Large-Scale Scrum (LeSS) von Craig Larman ist ein bekanntes Framework für Skalierung, das stark auf Scrum beruht und auf die Koordination mehrer Teams eingeht. Vorteile:! Hilft bei der Vision auf Programmebene! Multi-Team-Koordination ist konsequent durchdacht und dokumentiert! Anschlussfähig für Agilisten, weil es Scrum konsequent für die Koordination weiterdenkt. Nachteile:! Strategische Ebene wird nicht adressiert 15

17 Fall #1: Scaled Agile bei Wincor Nixdorf! Die Marke Wincor Nixdorf steht in Filialen von Banken und Handel für wettbewerbsfähige Produkte und Abläufe.! Zwei Kategorien von Software: hardware-abhängig (ATM) und Business-Anwendungen.! 350 Entwickler und QA Engineer, 15 Product Manager! An weltweit 6 Standorten (Paderborn, Berlin, Leipzig, Shanghai, Kattowice, Madrid) sind jeweils mehrere Teams an der Entwicklung der Produkte beteiligt.! wibas unterstützt Wincor Nixdorf bei der Einführung von Scaled Agile in der Produktenwicklung, weltweit über mehrere Standorte und Teams verteilt. 17

18 Fall #1 Das GO Agile Programm für die Scaled Agile Transformation des Wincor Nixdorf Software Business Scaled Agile ist die Basis für standortübergreifende verbindliche Abstimmung, Planung und Herstellung von Releases und Produktinhalten.! Fun and passion in die Entwicklungs-Community zurück bringen! Erkenntnisse über Kunden- und Markt-Veränderungen berücksichtigen! Spezifikations-Arbeit auf einen längeren Zeitraum verteilen! QA-Arbeit auf einen längeren Zeitraum verteilen! Mehr Transparenz bezüglich der erledigten Arbeit schaffen! Schneller liefern und mit höherer Qualität! Fokus auf die wichtigsten Aufgaben zuerst 18

19 Product management, development, and quality assurance collaborate closely. Teams are entrusted to decide, design, code, and test. Sprinting in small steps, avoiding waste, doing it right! We provide features of high quality that deliver value.

20 Fall #1 Scaled Agile bei Wincor Nixdorf: GO Agile Big Picture M2 3years Roadmap ProductBacklog 1year Refine DoR Feature Version Kickoff VersionBacklog Commitment Oppty M6 DoD IAT IAT SprintBacklog Sprint Planning DoR Story Team composition alternatives Refine Sprint Planning s Epic Feature Story Review & Retro Standup Feature Reviews DoD Dev/QA SprintBacklog Standup SprintBacklog Standup SprintBacklog Standup DoR Task Meeting Definition of Ready M5 Review & Retro QA Team Review & Retro Dev Team Review & Retro Single Team DoD Definition of Done 20

21 Fall #1 Scaled Agile bei Wincor Nixdorf: Artifact Version Backlog Regular Update called Refinement participants Chief Engineer Technical Owner Test Manager Product Manager (optional) Architect Chief Scrum Master Version Backlog Rank Story Team Feat. 1 Story M T1 C 5 Story Points 2 Story Q T3 B 20 Granularity initial break down of Features into technical Stories fulfilling requirements of Story Definition of Ready Story size: implementation in one Sprint by one Team Absolute Order no gaps, no overlaps ranking by Chief Engineer with respect to Feature order from Product Backlog 3 Story R T2 H 3 4 Story N T3 C 2 5 Story P T1 H 5 6 Story L T2 B 20 Commitment green: Story is Commitment for the Version blue: Story is an Opportunity for the Version but is not guaranteed Commitment is given during Version Kickoff 7 Story K T1 C 13 8 Story S T2 D 2 9 Story T T2 D Story V T3 E 8 a story has more attributes than shown Commitment Opportunity Size established by Planning Poker with Teams Story Points ½

22 Fall #1 Scaled Agile bei Wincor Nixdorf: Übersicht der Product und Version Backlogs Product Backlog Version granularity Rank Feature Story Points 1 Feature C 20 2 Feature B 40 3 Feature H 8 4 Feature D 20 5 Feature E 13 6 Feature F 40 7 Feature G 100 PBL Refinement a feature has more attributes than shown Version Kickoff Feature Reviews Ran k Version Backlog Sprint granularity Story Team Feature Story Points 1 Story M T1 C 5 2 Story Q T3 B 20 3 Story R T2 H 3 4 Story N T3 C 2 5 Story P T1 C 13 6 Story L T2 B 20 7 Story K T1 H 5 8 Story S T2 D 2 9 Story T T2 D Story V T3 E 8 VBL Refinement a story has more attributes than shown Commitment Opportunity Product Line R&D SWT 22

23 Fall #1 Scaled Agile bei Wincor Nixdorf: Übersicht der Version und Sprint Backlogs Ran k Version Backlog Story Team Feature Story Points 1 Story M T1 C 5 2 Story Q T3 B 20 3 Story R T2 H 3 4 Story N T3 C 2 5 Story P T1 C 13 6 Story L T2 B 20 7 Story K T1 H 5 8 Story S T2 D 2 9 Story T T2 D Story V T3 E 8 a Story has more attributes than shown Commitment Opportunity Sprint Planning Review & Retrospective Daily Standup Sprint Backlog Team 1 Story Story M Story P Story K To do Task Task Task Task Task Task Task Task In Work Task Task Task Task Done Task Task 23

24 Fall #1 Scaled Agile bei Wincor Nixdorf: Beispiel Epic zu Feature zu Story zu Task Epic Feature Story Task Transaction Safe Self Service Transactions Assisted Self Service Transactions Cash Out Check Cashing Self Initiated Cash In write tech spec. chapter write UI tech spec. chapter peripherals implement workflow implement dispenser Cross Channel Transactions write Unit Test for workflow 24

25 Fall #1 Scaled Agile bei Wincor Nixdorf: Definition of Ready (DoR) für Features Feature in User Story syntax fulfill INVEST criteria small enough to be implemented within 1 Version/release (recommended 2-3 Sprints) reviewed, es!mated by Chief Engineer, Architect, Technical Owner, Test Manager ranked by Product Manager INVEST criteria independent nego!able valuable es!matable small testable DoR Feature Contents must!tle Feature descrip!on in User Story syntax Acceptance Criteria, both func!onal and non- func!onal Contents should Chief Engineer may omit these points if Commitment can be achieved without. scenario(s), like use cases, rules business architecture, that is structure of components from customer perspec!ve descrip!on of change rela!ve to current func!onality Contents may GUI mockups references to incremental implementa!on approach, that is basic, extended, solid, sexy levels 25

26 Fall #1 Scaled Agile bei Wincor Nixdorf: Erkenntnisse / Empfehlungen aus dem GO Agile Programm Setup des Agilen Transformations-Projekt:! Agiles Transformations-Team! Transformation ist selbst agil! Workshops zur Zielvision mit Teams! Regelmäßige Kommunikation und Stakeholder-Meetings Erkenntnisse aus den Piloten:! Unterstützung der Geschäftsleitung zu Agilen Prinzipien ist Herausforderung! Management muss Präsenz zeigen! Anhaltendes Team-Coaching ist notwendig für positive Erfahrungen! Entwicklung der Agile-Master Rolle ist schwer! Adaption vom Ansatz nötig in z.b. China (selbst-organisierte Teams nicht leicht zu erreichen)! Veränderung von komponenten-getriebene zu feature-getriebene Entwicklung ist schwer 26

28 Fall #2: Scaled Agile Einführung bei einer niederländischen Bank: Ausgangssituation! Kleine kommerzielle Bank! 60 Entwickler und Tester in der Anwendungs-Entwicklung und Wartung! Eigenentwickelte Online-Banking Anwendungen (teilw. 15 Jahre alt)! Änderungswünsche der Fachseite überstiegen die Kapazität der IT! Projekte wurden automatisch nach Business-Case Genehmigung gestartet è Überlast! Große Projekte mit langfristigen Verpflichtungen (> 12 Monate) è unflexibel! Starke top-down command & control, Wasserfall Projekt-Governance è keine Ermächtigung! Lösung: Lean Management, Lean Prinzipien! wie z.b. Leadtime-Reduzierung, kleine Batch-Größen, Flow, Pull, Entwicklungs-Takt, WIP- Limits, kontinuierliche Verbesserung! Flaschenhals: Integrations- und Test-Umgebungen! Flaschenhals: Personal für Akzeptanztesting 28

29 Fall #2: Scaled Agile Einführung bei einer niederländischen Bank: Veränderungs-Roadmap basierend auf SAFe Sep Okt Nov Dez Jan Feb Mrz Apr Mai Jun Jul Q Q Q Q Scrum + in-sprint Kanban in 4 Entwicklungsteams in großem Erneuerungsprojekt umsetzen Kanban in Wartungsteams umsetzen Scrum in 2 weiteren Entwicklungsteams umsetzen Portfolio Kanban System (SAFe) definieren und umsetzen Program Level (SAFe) definieren und umsetzen Stufe 1a. Team Level Stufe 2. Portfolio Level Stufe 1b. Program Level Erste Release Planning für ART (Ende Q2) 29

30 Fall #2: Scaled Agile Einführung bei einer niederländischen Bank: Agilisierung eines großen Projektes! Stufe 1a: Umsetzung von Scrum auf Team-Ebene! Umfangreiche Scrum Trainings & Coachings für alle Teams! 2-wöchige Sprints für alle Teams! Batchgröße reduziert: inkrementelle Go-lives für jedes Teilprojekt! Normalisierte Story-Points à vergleichbare Schätzungen! Kanban WIP-Limit innerhalb des Sprints! Verbesserungen! Häufige Integration & Test, frühes Feedback! Produkt-Qualität ist bekannt (nicht sofort gut)! Alle 2 Wochen ein fertiges Inkrement! Transparenz des Fortschritts; Verzögerungen früher erkennen und einfacher dagegen zu steuern 30

31 Fall #2: Scaled Agile Einführung bei einer niederländischen Bank: Agilisierung des IT-Portfolio-Managements! Erkenntnis: Strategische und operative Planung nicht aligned! Keine Abstimmung zwischen Portfoliomanagement und Kapazitäts- und Projektsteuerung! Keine Transparenz über die Pipeline, Zyklen von Über- und Unterlast, kein Flow! Umdenken beim oberen Management! Zentralisierte Strategie und Portfolio-Vision! Kanban-Systeme sorgen für Portfolio Transparenz und WIP-Limits! Akzeptanz der Umsetzungsgeschwindigkeiten, Pull-Prinzip 31

33 Fall #3 Scaled Agile Programm-Management bei einem Internet-Provider: Ausgangssituation und Ziele In Deutschland wechseln jedes Jahr rund 3 Millionen Kunden ihren Mobilfunk- oder Festnetzanbieter.! Der Wechsel des Mobilfunkanbieters funktioniert gut, weil fast vollautomatisch.! Der Wechsel von Telefon- und DSL-Anschlüssen bereitet gelegentlich Probleme, da noch einiges noch von Hand erledigt werden muss. Zudem können unvollständige oder fehlerhafte Angaben von Kunden zu Verzögerungen führen. Ziele des Programms! Anbieterwechsel-Zielprozess mit kritischer Masse an anderen Anbietern und Vordienstleistern zu etablieren.! Die resultierenden internen Prozesse zu definieren, zu etablieren und die Abstimmungen mit den anderen Anbietern zu treffen! Die technische Architektur für die Prozesse festzulegen! Die Software-Produkte für die Prozesse zu bauen! Alle technischen Leistungen in den Regelbetrieb zu überführen 33

34 Fall #3 Scaled Agile Programm-Management bei einem Internet-Provider: Wertschöpfungskette DoR DoD PE BT CT DEV Releases EPICs NKs Use Cases Architektur User Stories Approved Verified Discussed Implemented Legende: DoR = Definition of Ready DoD = Definition of Done PE = Produktentwicklung BT = Business Team (CPO - Chief Product Owner, Requirements Engineers, Architekten) CT = Content Team (TPOs - Technical Product Owners) DEV = Entwicklungsteams NK = Nutzerkonzept 34

35 Fall #3 Scaled Agile Programm-Management bei einem Internet-Provider: Koordination der beteiligten Teams! 6 Scrum Teams (DEV Teams)! 1 Scrum Team der Product Owner (Content Team)! Gleiche Taktung: 2-Wochen Sprints! PDCA Zyklus in jedem Team 35

36 Fall #3: Scaled Agile Programm-Management bei einem Internet-Provider: Lean Prinzipien im Programm 2-Wochen-Sprint als Steuerungsmittel à Jeder Sprint ist ein definierter Meilenstein SOLL / IST - Meilensteinerreichung - Burndown - Aufwände - Risiken - Qualität DEV Teams SOLL / IST - Meilensteinerreichung - Burndown - Aufwände - Risiken - Qualität Content Team Review 14-tägig Do SOLL / IST - Meilensteinerreichung - Burndown - Aufwände - Risiken - Qualität Programm Review 14-tägig Mo Fachlicher Steuerungskreis Review 14-tägig Mi Lenkungskreis Review 14-tägig Mi Business Team Produktentwicklung Review 14-tägig Di/Mi 36

37 Fall #3 Scaled Agile Programm-Management bei einem Internet-Provider: Erkenntnisse und Empfehlungen Herausforderungen:! Produktentwicklung zu agilisieren ist ein langer Weg! Die Aufarbeitung der fachlichen Anforderungen in einem Schritt! Hoher Analyseaufwand durch die Transformation von Nutzerkonzept (fachlich und technisch) in Use Cases (fachlich)! Ein Nutzerkonzept (Epic) liefert ein releasefähiges, endkundenwirksames Ergebnis! Abhängigkeiten zwischen Epics! Veränderung von komponenten-getriebener zu feature- getriebener Entwicklung! Ein übergeordnetes technisches Konzept auf Basis der Architekturrichtlinien und Domänen pro System-Release! Integration der abteilungsübergreifenden Entwicklungsteams! Synchronisation Releasemanagement und technische Umsetzung! Infrastruktur und Organisation 37

38 Fall #3 Scaled Agile Programm-Management bei einem Internet-Provider: Erkenntnisse und Empfehlungen Success Stories:! Agile Arbeitsweise in sämtlichen Teams! Vereinbarung über die Qualität der Anforderungen (DoR) und Qualität der Lieferung (DoD)! Kontinuierlicher Fluss in der Wertschöpfung im Programm! Hohe Transparenz und Planbarkeit (Jira Workflow)! Fachliche Prozessabläufe und Architekturelle Rahmenbedingungen entstehen frühzeitig! Releases anstelle Big Bang! Gemeinsamer Einstieg in die technische Konzeption (Grooming) um ein gemeinsames Verständnis für die fachlichen und technischen Anforderungen zu entwickeln! Tägliche Synchronisierung zwischen den Teams (SOS, CT, PE/BT)! Erstellung der Testkonzepte in Abstimmung zwischen Entwicklung und QA auf Basis Releases! Regelmäßige Lieferung von fertigen SW-Inkrementen (Sprint-Länge: 2 Wochen)! Kontinuierliche Verbesserung der Arbeitsweise (Inspect & Adapt, Sprint Retrospektiven) 38

40 Scaled Agile Transformation Was sagen unsere Kunden, wenn Sie anderen Scaled Agile empfehlen? Agile Transformation braucht Investition in Fähigkeiten und Veränderung. Dies benötigt aktive Unterstützung. Haben Sie Geduld. Nach einem Jahr mit Agile ist es zu früh, um von Erfolg oder Misserfolg zu reden. Teams nehmen die Kultur und die Methoden nur Schritt für Schritt an. Selbstorganisation ist nicht führungslos. Entwickeln Sie Ihre Führung weiter. Führungskräfte sollten bereit sein, zuzuhören und selbst agile Techniken lernen. Agil ist wirkungsvoll - wenn Sie die Methode konsequent anwenden und nicht nur, wenn es bequem ist. Agil verlangt Disziplin auf allen Ebenen. Agil kommt mit einer Kulturänderung oder lassen Sie die Finger davon. Investieren Sie in Ausbildung und Coaching. Damit von Anfang an positive Erfahrungen gemacht werden. 40

41 Der Weg zur agilen Organisation dauert eine Weile und sieht in jeder Organisation anders aus. Gefahr:! Blueprint Big Bang Rollout Lösung:! Es geht nur in kleinen Schritten! Es braucht Strategie:! Es beginnt auf der Teamebene.! Es geht auf der taktischen bzw. auf der Programm-Ebene weiter.! Die strategische Ebene kommt zuletzt.! Die Veränderung ist ein empirischer Prozess! Nicht verzagen: es beginnt mit Scrum- But und Agile-But. Das geht nicht anders.! Wichtig ist, dass man dem Ziel immer näher kommt. 41

42 Scaled Agile Transformation eine gezielte Beachtung der Erfolgsfaktoren einer Transformation sichert den Erfolg. 42

43 Transformation Kotter: Die Kraft der zwei Systeme Harvard Business Manager Dezember 2012, Seite 22ff. 43

44 Ihre Ansprechpartner Malte Foegen Dipl. Wirtsch.-Inform. Partner SAFe Agilist * Certified Scrum Trainer * Management Coach Mobil: malte.foegen@wibas.de Caroline Gansser Dipl. Wirtsch.-Inform. (BA) Executive Consultant SAFe Agilist * Certified Scrum Professional * Agile Coach Mobile: caroline.gansser@wibas.de 44

45 Deutschland Otto-Hesse-Str Darmstadt Niederlande Sprookjesbosch JB Eindhoven Schweiz Bahnhofstr Buchs