scaled agile in der praxis - 2015.agileworld.de · large-scale scrum (less) von craig larman ist...

49
Scaled Agile in der Praxis Agile World, München am 30.06.2014

Upload: others

Post on 16-Oct-2019

5 views

Category:

Documents


1 download

TRANSCRIPT

Scaled Agile in der Praxis Agile World, München am 30.06.2014

Referenten

2 » www.wibas.com

Dr. Christian Schloegel Vice President Global Software Development Wincor Nixdorf AG

David Croome Consultant/Trainer wibas GmbH

3

1 Scaled Agile – Chancen, Prinzipien, Hürden, Frameworks

3 Fall #2 – Niederländische Bank: Scaled Agile Projektportfolio-Management

Agenda

5 Erfolgsfaktoren für eine Scaled Agile Transformation

2 Fall #1 – Wincor Nixdorf: Scaled Agile Transformation im Software-Business

4 Fall #3 – Internet-Provider Scaled Agile Programm-Management

4 » www.wibas.com

Wir sind überzeugt von den Werten von Scrum und wir haben den Nutzen von Scrum erlebt. Seht ihr das auch so?

Die Agilen Teams haben

! Frühe und regelmäßige Lieferungen

! Ermächtigung und Selbstorganisation

! Überprüfung und Anpassung

! Transparenz

! Timeboxing

5 » www.wibas.com

•  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.

Bei der Umsetzung stoßen wir alle an die Glasdecke der Scrum Verbreitung. Es geht nicht weiter.

6 » www.wibas.com

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

7 » www.wibas.com

„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.

Frameworks wie SAFe und LeSS sind nützlich um Lösungsideen zu entwickeln. Man sollte sie aber nicht als Blueprints nutzen.

8 » www.wibas.com

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

Wir haben aus den Frameworks und unserer Erfahrung die Konstruktionsprinzipien entwickelt, um individuelle und stabile Kundenlösungen zu gestalten.

9 » www.wibas.com

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

10 » www.wibas.com

Die nächste Ebene dient der Koordination mehrerer Teams mit einem gemeinsamen Ziel.

11 » www.wibas.com

Für die Koordination mehrerer Teams (z.B. Programme oder Produktlinien) braucht es einen PDCA Zyklus, der auf einer höheren Abstraktionsebene arbeitet (taktische Ebene).

12 » www.wibas.com

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

13 » www.wibas.com

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

14 » www.wibas.com

Vorteile: ! Hilft bei der Vision von Scaled Agile ! Programm und Portfolio-Ebene sind

konsequent durchdacht und dokumentiert ! Viele Techniken sind dokumentiert ! Auf der Programmebene nutzt es viele

„klassische“ Begriffe – im ersten Moment macht es SAFe einfacher

Nachteile:: ! Häufig andere Begriffe als in Scrum –

dadurch schwer zu verstehen ! Auf der Programmebene nutzt es viele

„klassische“ Begriffe – das verschleiert Transformationsbedarf und macht die Adoption von SAFe für Agilisten schwer

! Tailoring ist schwierig weil unklar ist, was „muss“ und „kann“ ist

Scaled Agile Framework (SAFe) von Dean Leffingwell ist bekanntes Framework für Skalierung, das Team, Programm und Portfolio-Ebene detailliert definiert.

15 » www.wibas.com

Vorteile:

! Hilft bei der Vision von Scaled Agile 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

! Tailoring ist schwierig weil unklar ist, was „muss“ und „kann“ ist

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.

16

1 Scaled Agile – Chancen, Prinzipien, Hürden, Frameworks

3 Fall #2 – Niederländische Bank: Scaled Agile Projektportfolio-Management

Agenda

5 Erfolgsfaktoren für eine Scaled Agile Transformation

2 Fall #1 – Wincor Nixdorf: Scaled Agile Transformation im Software-Business

4 Fall #3 – Internet-Provider Scaled Agile Programm-Management

17 » www.wibas.com

! Die Marke Wincor Nixdorf steht in Filialen von Banken, Handel und Post für wettbewerbsfähige Produkte und Abläufe.

! Zwei Kategorien von Software: hardware-abhängig (ATM, POS), pure Business-Anwendungen

! An weltweit 6 Standorten (Paderborn, Berlin, Leipzig, Shanghai, Kattowice, Madrid) sind jeweils mehrere Teams an der Entwicklung der Produkte beteiligt.

! 350 Entwickler und QA Engineer, 15 Product Manager

! wibas unterstützt Wincor Nixdorf bei der Einführung von Scaled Agile in der Produktenwicklung, weltweit über mehrere Standorte und Teams verteilt.

Fall #1: Scaled Agile bei Wincor Nixdorf.

18 » www.wibas.com

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

Fall #1 – Das „GO Agile“ Programm für die Scaled Agile Transformation des Wincor Nixdorf Software Business

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 » www.wibas.com

SprintBacklog

IAT

Fall #1 – Scaled Agile bei Wincor Nixdorf: “GO AgiLe” Big Picture

Com

mitm

ent

Opp

ty

M2

M6

Version Kickoff

DoR

DoR

DoD

VersionBacklog

SprintBacklog

SprintBacklog

1year

Feature Reviews

Roadmap 3years

Review & Retro

Sprint

Plannings

Feature

Story

Refine

Refine

Standup

Standup

Review & Retro

Single Team

Dev Team

Review & Retro

Standup

Feature

Story

Task

Meeting M5

ProductBacklog

DoR

DoD

Definition of Ready

Definition of Done

Epic

DoD

Dev/QA

IAT Sprint

Planning

SprintBacklog

QA Team

Review & Retro

Standup

Team composition alternatives

21 » www.wibas.com

Fall #1 – Scaled Agile bei Wincor Nixdorf: Übersicht der Regel-Meetings

Sprint

Planning

Version Kickoff

Pro

du

ct

Ver

sio

n

Dev

. Tea

ms

PBL Refine

VBL Refine

TOs/ TMs

PM CE CSM

Sprint 2 IAT …

VBL Refine

VBL Refine

VBL Refine

Review & Retro

Sprint

Planning

Review & Retro

Sprint 1

PBL Refine

PBL Refine

PBL Refine

Teams 1..n & TSMs

Review & Retro

Version Kickoff

Sprint

Planning

22 » www.wibas.com

Fall #1 – Scaled Agile bei Wincor Nixdorf: Artifact Version Backlog

Version Backlog

Commit-ment

Oppor-tunity

Rank Story Team Feat. 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 H 5

6 Story L T2 B 20

7 Story K T1 C 13

8 Story S T2 D 2

9 Story T T2 D 13

10 Story V T3 E 8

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

Absolute Order • no gaps, no overlaps • ranking by Chief Engineer • with respect to Feature order from Product Backlog

Size • established by Planning Poker with Teams

• Story Points • ½ 1 2 3 5 8 13 20 40 100

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

Regular Update • called „Refinement“ • participants

•  Chief Engineer •  Technical Owner •  Test Manager •  Product Manager (optional) •  Architect •  Chief Scrum Master

a story has more attributes than shown…

23 » www.wibas.com

Version Kickoff

Product Backlog Version granularity

Version Backlog Sprint granularity

Fall #1 – Scaled Agile bei Wincor Nixdorf: Übersicht der Product und Version Backlogs

Commit-ment

Oppor-tunity

Product Line R&D SWT

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

Rank 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 13

10 Story V T3 E 8

VBL Refinement

PBL Refinement

a story has more attributes than shown… a feature has more attributes than shown…

Feature Reviews

24 » www.wibas.com

Sprint Planning

Review &

Retrospective

Fall #1 – Scaled Agile bei Wincor Nixdorf: Übersicht der Version und Sprint Backlogs

Sprint Backlog Team 1

Story To do In Work Done

Story M

Task Task

Task Task

Task Task

Story P

Task Task

Task Task

Story K

Task Task Task Task

Version Backlog

Commit-ment

Oppor-tunity

Rank 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 13

10 Story V T3 E 8 a Story has more attributes than shown…

Daily Standup

25 » www.wibas.com

Epic Feature Story Task

Fall #1 – Scaled Agile bei Wincor Nixdorf: Beispiel – Epic zu Feature zu Story zu Task

Self Service Transactions

Transaction Safe

Assisted Self Service Transactions

Cross Channel Transactions

write tech spec.

chapter UI

implement workflow

Cash Out

Check Cashing

Self Initiated Cash In

write tech spec.

chapter peripherals

implement dispenser

write Unit Test for

workflow

… …

… …

26 » www.wibas.com

Fall #1 – Scaled Agile bei Wincor Nixdorf: „Definition of Ready“ (DoR) für Features

Contents  “must”  • !tle  • Feature  descrip!on  in  User  Story  syntax  

• Acceptance  Criteria,  both  func!onal  and  non-­‐func!onal  

INVEST  criteria  • independent  • nego!able  • valuable  • es!matable  • small  • testable  

DoR Feature

Feature  • wri@en  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  

Contents  “may”  • GUI  mockups  • references  to  incremental  implementa!on  approach,  that  is  basic,  extended,  solid,  sexy  levels  

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  

27 » www.wibas.com

Pilotierung abgeschlossen: ! Adaptierter Framework für unseren skalierten Agilen Ansatz definiert

! Schulungen für alle Agile Rollen durchgeführt

! Agile Teams je Produkt definiert und besetzt

! Rollout zu allen Teams größtenteils umgesetzt

! Anhaltendes Team-Coaching

! Skalierungs-Meetings (Programm-Ebene) definiert und erste Umsetzungen

Nächste Schritte: ! Finale Entscheidung betreffend Agile Tool (derzeit eigenentwickeltes Tool verwendet)

! Anpassung des Top-Management-Reportings

! Entscheidung, Agile Elemente in die Hardware-Entwicklung einzuführen in Diskussion

Fall #1 – Scaled Agile bei Wincor Nixdorf: Wo stehen wir gerade beim „GO Agile“ Programm

28 » www.wibas.com

Setup des Agile Transformations-Projekt: ! Aufbau eines Agile Kernteam war essenziell (PMO, Entwicklung und QA Kompetenzen)

! Workshops zur Ansatz-Definition mit dedizierten Teams war entscheidend

! Transformations-Projekt wurde mit einem Agilen Ansatz umgesetzt, um zu zeigen, dass es funktioniert

! Hybrid-Programm-Teams (teils Scrum, teils Wasserfall) in der Pilotierungs-Phase hat nicht gut funktioniert

! Regelmäßige Stakeholder-Meetings waren essenziell

Erkenntnisse aus den Piloten: ! Produkt-Architekten sind unausweichlich in komplexen Produkt-Suite-Umgebungen

! Man soll den Abstimmungsaufwand zwischen Agilen Teams nicht unterschätzen

! Story-Point versus Manntag Denken nicht einfach zu ändern

! Der Blueprint aus dem Buch funktioniert nicht in allen Unternehmens-Kontexten

Fall #1 – Scaled Agile bei Wincor Nixdorf: Erkentnisse / Empfehlungen aus dem „GO Agile“ Programm (1/2)

29 » www.wibas.com

Erkenntnisse aus dem Agilen Leben: ! Unterstützung der Geschäftsleitung zu Agilen Prinzipien war schwer zu erreichen

! Anhaltende Kommunikation an allen Stakeholdern und Teams ist essenziell

! Management muss Präsenz zeigen in Meetings

! Anhaltendes Team-Coaching ist notwendig, um das Verständnis für Agile zu vertiefen

! Experten und Wissen über mehreren Standorten verteilt ist schwierig mit einem Team zu vereinbaren – Ziel: „one location“

! Agile-Master Rolle ist schwer zu bestehenden Entwicklern zuzuweisen (wenn dies als separate Rolle umgesetzt wird)

! Anderen Ansatz nötig in China (selbst-organisierte Teams nicht leicht zu erreichen)

! Veränderung von komponenten-getriebene zu feature-getriebene Entwicklung ist schwer

Fall #1 – Scaled Agile bei Wincor Nixdorf: Erkentnisse / Empfehlungen aus dem „GO Agile“ Programm (2/2)

30 » www.wibas.com

Was wir bislang erreicht haben:

„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

Fall #1 – Wincor Nixdorf: Das „GO Agile“ Programm für die Scaled Agile Transformation des Wincor Nixdorf Software Business

31

1 Scaled Agile – Chancen, Prinzipien, Hürden, Frameworks

3 Fall #2 – Niederländische Bank: Scaled Agile Projektportfolio-Management

Agenda

5 Erfolgsfaktoren für eine Scaled Agile Transformation

2 Fall #1 – Wincor Nixdorf: Scaled Agile Transformation im Software-Business

4 Fall #3 – Internet-Provider Scaled Agile Programm-Management

32 » www.wibas.com

! Kleine kommerzielle Bank

! Eigenentwickelte Online-Banking Anwendungen (beispielsweise 15 Jahre alt, ~10.000 Function-Points)

! ~60 Entwickler und Tester in Anwendungs-Entwicklung und Wartung

! Ä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

! Geringes/kein Bewußtsein für Lean Prinzipien

! wie z.B. Leadtime-Reduzierung, kleine Batch-Größen, Flow, Pull, Entwicklungs-Takt, WIP-Limits, kontinuierliche evolutive Verbesserung

! Flaschenhals: Integrations- und Test-Umgebungen

! Flaschenhals: Personal für Akzeptanztesting

Fall #2: Scaled Agile Einführung bei einer niederländischen Bank: generelle Ausgangssituation

33 » www.wibas.com

Fall #2: Scaled Agile Einführung bei einer niederländischen Bank: Veränderungs-Roadmap basierend auf SAFe

Scrum + in-sprint Kanban in 4 Entwicklungsteams in großem Erneuerungsprojekt umsetzen

Portfolio Kanban System (SAFe) definieren und umsetzen

Erste Release Planning für ART (Ende Q2)

Sep Okt Nov Dez Jan Feb Mrz Apr Mai Jun Jul

Scrum in 2 weiteren Entwicklungs-teams umsetzen

Kanban in Wartungs-teams umsetzen

Program Level (SAFe) definieren und umsetzen

Q4 2013 Q1 2014 Q2 2014 Q3 2014

Stufe 1a. Team Level

Stufe 2. Portfolio Level

Stufe 1b. Program Level

34 » www.wibas.com

Erneuerungs-Projekt einer großen Online-Banking Anwendung ! Ausgangssituation:

! Schätzung: 25 Entwickler x 12 Monate

! Projekt Steuerkreis setzte eine „Water-Scrum“ Entwicklung auf mit einem einzigen big-bang Go-Live am Projektende

! Ein Projektleiter führt gesamte Entwicklungsteam bestehend aus 2 externe Entwicklungsteams + 1 internes Entwicklungsteam + 1 Integrationsteam.

! Externe Entwicklungsteams arbeiteten in 3- bzw. 4-wöchigen Sprints.

! Keine Integrations-Umgebung; fertigentwickelten Umfänge konnten nicht getestet werden.

! Projekt Fortschritt war unklar, mit ständigen Verzögerungen.

! Agilisierung des Projektes

! Stufe 1a: Umsetzung von Scrum in multidisziplinären Entwicklungsteams

! Stufe 1b: Umstellung des Projektes zu einem „Release Train“ mit dem ersten „Release Planning“ Meeting mit Beteiligung aller Teammitglieder im August.

Fall #2: Scaled Agile Einführung bei einer niederländischen Bank: Agilisierung eines großen Projektes

Agile umsetzen, um das big-bang

Erneuerungs-Projekt zu retten!

35 » www.wibas.com

! Umsetzung von Agil auf Team-Ebene

! Umfangreiche Scrum Training & Coaching für alle Teams

! Batchgröße reduziert: inkrementelle Go-lives für jedes Teilprojekt

! 2-wöchige Sprints für alle Teams

! Normalisierte Story-Points zählen à bekannte Entwicklungskapazität pro Sprint

! Integration in Testumgebungen am Sprintende eingefordert (später: Sprint-Mitte)

! Kanban WIP-Limit innerhalb des Sprints à begrenzt auf 10 Story-Points

! Alle erforderlichen Kompetenzen (inkl. Tester) in den Entwicklungsteams

! Verbesserungen

! Häufige Integration & Test, frühes Feedback

! Produkt-Qualität ist bekannt (nicht sofort gut)

! Bei jedem Sprint ein laufendes Inkrement

! Transparenz des Fortschritts; Verzögerungen früher erkennen und einfacher dagegen zu steuern

Fall #2: Scaled Agile Einführung bei einer niederländischen Bank: Agilisierung eines großen Projektes

36 » www.wibas.com

Fall #2: Scaled Agile Einführung bei einer niederländischen Bank: Agilisierung des IT-Portfolio-Managements

! Strategische und operative Planung nicht „aligned“

! Keine Abstimmung zwischen Portfoliomanagement und Kapazitäts- und Projektsteuerung der einzelnen Teams und Projekten

! Hundezyklen von Über- und Unterlasten. Zerhakte „Flow“ und keine Pipeline-Transparenz

! Umdenken beim oberen Management

! Zentralisierte Strategie und Portfolio-Vision gibt Richtung für dezentralisierte Umsetzung vor

! Kanban-Systeme sorgen für Portfolio Transparenz und WIP-Limits

37

1 Scaled Agile – Chancen, Prinzipien, Hürden, Frameworks

3 Fall #2 – Niederländische Bank: Scaled Agile Projektportfolio-Management

Agenda

5 Erfolgsfaktoren für eine Scaled Agile Transformation

2 Fall #1 – Wincor Nixdorf: Scaled Agile Transformation im Software-Business

4 Fall #3 – Internet-Provider Scaled Agile Programm-Management

38 » www.wibas.com

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 ! Unternehmensziel: Anbieterwechsel-Zielprozess mit kritischer Masse an anderen

Anbietern und Vordienstleistern zu etablieren.

! Bereichsziel: Die resultierenden internen Prozesse zu definieren, zu etablieren und die Abstimmungen mit den anderen Anbietern zu treffen

! Ziele des Programms Anbieterwechsel: ! 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

Fall #3 – Scaled Agile Programm-Management bei einem Internet-Provider: Ausgangssituation und Ziele

http://www.faz.net/aktuell/wirtschaft/unternehmen/strafen-fuer-telekom-unternehmen-tagelang-ohne-internet-12809931.html

39 » www.wibas.com

Fall #3 – Scaled Agile Programm-Management bei einem Internet-Provider: Wertschöpfungskette

PE CT BT

Releases Epics

Features Use Cases Architektur

User Stories

DEV

„Approved“ „Verified“ „Discussed“

DoR DoD

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 Grooming = gemeinsamer Einstieg in die technische Konzeption

„Implemented“

40 » www.wibas.com

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

41 » www.wibas.com

Fall #3: Scaled Agile Programm-Management bei einem Internet-Provider: Lean Management im Programm

DEV Teams

Content Team

Programm

Lenkungskreis

Review 14-tägig Di/Mi

Review 14-tägig Do

Review 14-tägig Mo

Review 14-tägig Mi

SOLL / IST -  Meilensteinerreichung -  Burndown -  Aufwände -  Risiken -  Qualität

SOLL / IST -  Meilensteinerreichung -  Burndown -  Aufwände -  Risiken -  Qualität

SOLL / IST -  Meilensteinerreichung -  Burndown -  Aufwände -  Risiken -  Qualität

2-Wochen-Sprint als Steuerungsmittel à Jeder Sprint ist ein definierter Meilenstein

Business Team

Produktentwicklung

Fachlicher Steuerungskreis

Review 14-tägig Mi

42 » www.wibas.com

Fall #3 – Scaled Agile Programm-Management bei einem Internet-Provider: Beispiel Meeting Stundenplan

43

1 Scaled Agile – Chancen, Prinzipien, Hürden, Frameworks

3 Fall #2 – Niederländische Bank: Scaled Agile Projektportfolio-Management

Agenda

5 Erfolgsfaktoren für eine Scaled Agile Transformation

2 Fall #1 – Wincor Nixdorf: Scaled Agile Transformation im Software-Business

4 Fall #3 – Internet-Provider Scaled Agile Programm-Management

44 » www.wibas.com

Scaled Agile Transformation – Was sagen unsere Kunden, wenn Sie anderen Scaled Agile empfehlen?

Agil kommt mit einer Kulturänderung – oder lassen Sie die Finger davon.

Agil ist wirkungsvoll - wenn Sie die Methode konsequent anwenden – und nicht nur, wenn es bequem ist.

Investieren Sie in Ausbildung und Coaching.

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.

Agile Transformation braucht Investition in Fähigkeiten und Veränderung. Dies benötigt aktive Unterstützung.

45 » www.wibas.com

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.

Der Weg zur agilen Organisation dauert eine Weile und sieht in jeder Organisation anders aus.

46 » www.wibas.com

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

47 » www.wibas.com

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

Referenten

48 » www.wibas.com

Dr. Christian Schloegel Dipl.-Informatiker Vice President Global Software Development, Wincor Nixdorf AG Tel: +49 5251 693 4900 E-Mail: [email protected]

David Croome BSc. Production Engineering Senior Executive Consultant, wibas GmbH Mobil: +49 172 6666693 E-Mail: [email protected]

Deutschland Otto-Hesse-Str. 19 64293 Darmstadt +49 6151 503349-0 www.wibas.de

Niederlande Sprookjesbosch 53 5629 JB Eindhoven +31 4024 89822 www.wibas.nl

Schweiz Bahnhofstr. 29 9471 Buchs +41 41 51122-90 www.wibas.ch » www.wibas.com