WIXLIB

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

ReferentenDavid CroomeConsultant/Trainerwibas GmbHDr. Christian SchloegelVice President Global Software DevelopmentWincor Nixdorf AG» www.wibas.com2

Agenda1Scaled Agile – Chancen, Prinzipien, Hürden, Frameworks2Fall #1 – Wincor Nixdorf:Scaled Agile Transformation im Software-Business3Fall #2 – Niederländische Bank:Scaled Agile Projektportfolio-Management4Fall #3 – Internet-ProviderScaled Agile Programm-Management5Erfolgsfaktoren für eine Scaled Agile Transformation3

Wir sind überzeugt von den Werten von Scrum und wir habenden 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» www.wibas.com4

Bei der Umsetzung stoßen wir alle an die Glasdecke der ScrumVerbreitung. Es geht nicht weiter. Scrum verbreitet sich nicht von alleineScrum ist keine Antwort für alle TeamsScrum liefert keine Antworten zur Zusammenarbeit mehrerer Teams und für dieGestaltung eines durchgängigen Wertstroms.» www.wibas.com5

Wir benötigen Antworten auf Koordination mehrerer Teams unddie Rolle der Führung. Dies nennen wir Skalierung.» www.wibas.com6

Frameworks wie SAFe und LeSS sind nützlich um Lösungsideenzu 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.» www.wibas.com7

Wir haben aus den Frameworks und unserer Erfahrung dieKonstruktionsprinzipien entwickelt, um individuelle und stabileKundenlösungen zu gestalten.1. Die Skalierung organisiert eine Koordination mehrerer Teams in Richtung einesgemeinsamen 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§ Artefakte3. Die Skalierung organisiert eine Koordination der Architektur4. Die Skalierung beinhaltet Lean Management5. Die Skalierung definiert klare Spielregeln und entsteht emergent» www.wibas.com8

Die operative Ebene ist das Team. LeSS und SAFe nutzen dafürScrum.» www.wibas.com9

Die nächste Ebene dient der Koordination mehrerer Teams miteinem gemeinsamen Ziel.» www.wibas.com10

Für die Koordination mehrerer Teams (z.B. Programme oderProduktlinien) braucht es einen PDCA Zyklus, der auf einerhöheren Abstraktionsebene arbeitet (taktische Ebene).» www.wibas.com11

Die strategische Ebene dient dazu, das Portfolio mehrerertaktischer Einheiten (z.B. Programme) zu koordinieren.» www.wibas.com12

Auch auf der strategischen Ebene setzen wir einen PDCA Zyklusum.» www.wibas.com13

Scaled Agile Framework (SAFe) von Dean Leffingwell istbekanntes Framework für Skalierung, das Team, Programm undPortfolio-Ebene detailliert definiert.Vorteile:! Hilft bei der Vision von Scaled Agile! Programm und Portfolio-Ebene sindkonsequent durchdacht und dokumentiert! Viele Techniken sind dokumentiert! Auf der Programmebene nutzt es viele„klassische“ Begriffe – im ersten Momentmacht es SAFe einfacherNachteile::! Häufig andere Begriffe als in Scrum –dadurch schwer zu verstehen! Auf der Programmebene nutzt es viele„klassische“ Begriffe – das verschleiertTransformationsbedarf und macht dieAdoption von SAFe für Agilisten schwer! Tailoring ist schwierig weil unklar ist, was„muss“ und „kann“ ist» www.wibas.com14

Large-Scale Scrum (LeSS) von Craig Larman ist ein bekanntesFramework für Skalierung, das stark auf Scrum beruht und aufdie Koordination mehrer Teams eingeht.Vorteile:!Hilft bei der Vision von Scaled Agile aufProgrammebene!Multi-Team-Koordination istkonsequent durchdacht unddokumentiert!Anschlussfähig für Agilisten, weil esScrum konsequent für die Koordinationweiterdenkt.Nachteile:» www.wibas.com!Strategische Ebene wird nicht adressiert!Tailoring ist schwierig weil unklar ist,was „muss“ und „kann“ ist15

Agenda1Scaled Agile – Chancen, Prinzipien, Hürden, Frameworks2Fall #1 – Wincor Nixdorf:Scaled Agile Transformation im Software-Business3Fall #2 – Niederländische Bank:Scaled Agile Projektportfolio-Management4Fall #3 – Internet-ProviderScaled Agile Programm-Management5Erfolgsfaktoren für eine Scaled Agile Transformation16

Fall #1: Scaled Agile bei Wincor Nixdorf.!Die Marke Wincor Nixdorf steht in Filialen von Banken, Handel und Post fürwettbewerbsfähige Produkte und Abläufe.!Zwei Kategorien von Software: hardware-abhängig (ATM, POS), pure BusinessAnwendungen!An weltweit 6 Standorten (Paderborn, Berlin, Leipzig, Shanghai, Kattowice, Madrid) sindjeweils 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 derProduktenwicklung, weltweit über mehrere Standorte und Teams verteilt.» www.wibas.com17

Fall #1 – Das „GO Agile“ Programm für die Scaled AgileTransformation des Wincor Nixdorf Software BusinessScaled 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» www.wibas.com18

Product management, development, and quality assurance collaborateclosely. Teams are entrusted to decide, design, code, and test. Sprintingin small steps, avoiding waste, doing it right! We provide features of highquality that deliver value.

DoRIATIATSprintBacklogDoDOppty log3years Roadmap1year ProductBacklogFall #1 – Scaled Agile bei Wincor Nixdorf:“GO AgiLe” Big tureReviewsFeatureStoryTaskMeetingDoR Definition of ReadyM5Review& RetroStandupQATeamReview& cklogReview& RetroSprintBacklogTeam composition alternativesSprintPlanningsReview& RetroStandupSingleTeamDoD Definition of Done» www.wibas.com20

Fall #1 – Scaled Agile bei Wincor Nixdorf:Übersicht der Regel-MeetingsSprint 2 IATPM CE CSMDev. TeamsVersionProductSprint 1» finePBLRefineVBLRefineReview& ew& RetroReview& RetroSprintPlanningTOs/ Teams 1.n& TSMsTMsSprintPlanningSprintPlanning21

Fall #1 – Scaled Agile bei Wincor Nixdorf:Artifact Version BacklogRegular Update called „Refinement“ participants Chief Engineer Technical Owner Test Manager Product Manager (optional) Architect Chief Scrum MasterAbsolute Order no gaps, no overlaps ranking by Chief Engineer with respect to Feature orderfrom Product BacklogCommitment green: Story is Commitmentfor the Version blue: Story is an Opportunityfor the Version but is notguaranteed Commitment is given duringVersion KickoffGranularity initial break down of Featuresinto technical Stories fulfilling requirements of StoryDefinition of Ready Story size: implementation inone Sprint by one TeamVersion BacklogRankStoryPointsStoryTeamFeat.1Story MT1C52Story QT3B203Story RT2H34Story NT3C25Story PT1H56Story LT2B207Story KT1C138Story ST2D29Story TT2D1310Story VT3E8CommitmentOpportunitySize established by PlanningPoker with Teams Story Points ½ 1 2 3 5 8 13 20 40 100a story has more attributes than shown » www.wibas.com22

Fall #1 – Scaled Agile bei Wincor Nixdorf:Übersicht der Product und Version BacklogsProduct BacklogVersion BacklogVersion granularitySprint granularityRank1FeatureFeature CRankStoryPoints20VersionKickoffStoryTeam FeatureStoryPoints1Story MT1C52Story QT3B202Feature B403Story RT2H33Feature H84Story NT3C24Feature D205Story PT1C136Story LT2B207Story KT1H58Story ST2D29Story TT2D1310Story VT3E85Feature E136Feature F407Feature G100PBLa feature has more attributes than shown RefinementProduct Line» Opportunitya story has more attributes than shown R&D SWT23

Fall #1 – Scaled Agile bei Wincor Nixdorf:Übersicht der Version und Sprint BacklogsVersion BacklogSprint BacklogTeam 1RankStoryTeam FeatureStoryPoints1Story MT1C52Story QT3B203Story RT2H34Story NT3C25Story PT1C136Story LT2B207Story KT1H58Story ST2D29Story TT2D1310Story VT3E8StorySprintPlanningCommitment» askStory PReview &RetrospectiveTaskTaskTaskTaskStory KOpportunitya Story has more attributes than shown To doTaskTaskTaskTaskDailyStandup24

Fall #1 – Scaled Agile bei Wincor Nixdorf:Beispiel – Epic zu Feature zu Story zu TaskEpicTransactionSafeFeatureSelf ServiceTransactionsAssisted SelfServiceTransactionsCrossChannelTransactions StoryCash OutCheckCashingSelf InitiatedCash In write techspec.chapterwriteUI entdispenserwrite UnitTest forworkflow » www.wibas.comTask 25

Fall #1 – Scaled Agile bei Wincor Nixdorf:„Definition of Ready“ (DoR) für FeaturesContents“must”Feature !tle Featuredescrip!oninUserStorysyntax AcceptanceCriteria,bothfunc!onalandnon- ‐func!onal wri@eninUserStorysyntax fulfillINVESTcriteria ecommended2- ‐3Sprints) alOwner,TestManager reINVESTcriteria independent nego!able valuable es!matable small testable» www.wibas.com hievedwithout. scenario(s),likeusecases,rules omcustomerperspec!ve ents“may” GUImockups sbasic,extended,solid,sexylevels26

Fall #1 – Scaled Agile bei Wincor Nixdorf:Wo stehen wir gerade beim „GO Agile“ ProgrammPilotierung 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 UmsetzungenNä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» www.wibas.com27

Fall #1 – Scaled Agile bei Wincor Nixdorf:Erkentnisse / Empfehlungen aus dem „GO Agile“ Programm (1/2)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, dasses funktioniert!Hybrid-Programm-Teams (teils Scrum, teils Wasserfall) in der Pilotierungs-Phase hat nichtgut funktioniert!Regelmäßige Stakeholder-Meetings waren essenziellErkenntnisse 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» www.wibas.com28

Fall #1 – Scaled Agile bei Wincor Nixdorf:Erkentnisse / Empfehlungen aus dem „GO Agile“ Programm (2/2)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 zuvereinbaren – Ziel: „one location“!Agile-Master Rolle ist schwer zu bestehenden Entwicklern zuzuweisen (wenn dies alsseparate 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 istschwer» www.wibas.com29