SAFe, P2A, DAD Orientierung im Methodendschungel für Agilität bei Grossprojekten

Transkript

1 SAFe, P2A, DAD Orientierung im Methodendschungel für Agilität bei Grossprojekten SAFe, P2A, DAD SIS OIBKP Lutz Ehrlich 1.0 / Energie braucht Impulse

2 Aufstellung Wer hat schon einmal agile Projekte gemacht mit: Personen? 2

3 Vor welchen Herausforderungen stehen agile Teams im Kontext grosser Projekte/Organisationen? Wie strukturieren wir sehr große agile Projekte mit vielen Teams? Wie adressieren wir in agilen Projekte Governance-Funktionen (Enterprise Architektur Management, UX, PMO, Q)? Wie adressieren wir das Miteinander von Entwicklung und Betrieb von Lösungen? Was bedeutet Agilität außerhalb der reinen Entwicklungseinheiten einer Organisation? Wie erzeugen unsere Entwicklungseinheiten hohe Qualität? Wie passen wir agile Praktiken auf unsere Gegebenheiten an? 3

4 Eigene Motivation und Hintergrund Motivation EnBW durchläuft grosse Veränderungen Alle IT-Großprojekte immer Multi-Team, Multi-System, Multi-Standort Positive Erfahrung bei Einsatz von Scrum und SAFe-Elementen keine zentrale Change-Initiative hin zur Agilisierung Agile Verfahren müssen an etablierte Strukturen/Prozesse andocken Hintergrund SAFe Certified Scaled Agilist Wohlwollender Beobachter von DAD und P2A ohne praktische Erfahrung 4

5 5 Die Kandidaten

6 Disciplined Agile Delivery DAD disciplinedagiledelivery.com Scott Ambler, IBM Rational Chief Methodologist for IT Weiterentwicklung des Agile Unified Process Dient als Grundlage für Skalierung, verweist aber auf Larman/SAFe keine veröffentlichten Case Studies 6

7 Scaled Agile Framework SAFe scaledagileframework.com Dean Leffingwell RUP Godfather ex-rational, Rally, RequisitePro Skalierung von ScrumXP mit Lean- Konzepten von Reinertsen Einige case studies veröffentlicht 7

8 Path to Agility P2A Vormals: Continuous Improvement Framework Ken Schwaber Scrum Godfather noch nicht veröffentlicht verwendet Scrum als Change Management-Prozess, um Agilität in Unternehmen einzuführen keine case studies 8

9 9 Kernideen der Frameworks

10 DAD Entwicklung von Lösungen in 3 Phasen mit Iterationen, die zur Priorisierung neben Geschäftswert Risiko betrachten 10

11 SAFe Kontinuierlicher Produkt-Entwicklungs-Fluss auf Team/Programm/Portfolio- Ebene 11

12 P2A Scrum für inkrementelles Change Management auf Ebene der Praktiken 12

13 13 Unvollständige Einordnung nach Cobb 2013

14 Unterscheidungen für den Vergleich Sichtbares Rollen, Strukturen, Flow, Artefakte Unsichtbares Integration mit den Umwelten Wie wird im Framework gelernt Meta Training, Zertifizierung, Community, Berater, Literatur 14

15 Sichtbares Flow Rollen & Strukturen Artefakte 15

16 16 16I Flow

17 Flow in den Frameworks (1) Alle Frameworks ziehen Kadenzen ein Auf Teamebene verwenden alle Frameworks Scrum (+XP Praktiken) Nur SAFe modelliert Organisationsebenen explizit P2A Change-Inkremente im Quartalsturnus DAD Projekt-Phasen: Inception, Construction, Transition Sprints: 1-6 Wochen 17

18 Flow in den Frameworks (2) SAFe: Explizite Modellierung von Team, Programm, Portfolio Portfolio: Kanban Programm: Agile Release Train Team: ScrumXP Produkt-Entwicklungs-Fluss in Inkrementen(PSI) 4 Entwicklungs-Sprints + 1 Härtungs-Sprint a 2 Wochen Normalisierte Geschwindigkeit, weighted shortest job first 18

19 Flow in den Frameworks (3) Arbeitssteuerung über priorisierte Arbeitsspeicher DAD: Work item stack/pool/backlog SAFe: Team backlog, program backlog, portfolio kanban P2A: Practise Backlog Planung DAD: wie Scrum SAFe: Team wie ScrumXP, program PSI planning, portfolio pull P2A: kein Aussage 19

20 20 Rollen

21 Rollen in den Frameworks DAD Zusätzliche Rollen für Unterstützungsfunktionen und Führung SAFe Team wie Scrum Programm explizite Koordinationsrollen: System Team, Release Mgmt, RTE Product Manager P2A Nur Scrum-Rollen für Change Management auf EbenenTeam, Area, Chief 21

22 22 Artefakte

23 Artefakte in den Frameworks Alle Frameworks führen neue Artefakte für Projektmanagement ein Artefakte, die Change Management zum Inhalt haben, nur in P2A und SAFe P2A Agility Index SAFe Team und Program metrics SAFe: Skalierung der Anforderungs-Artefakte Team: User Story Programm: Feature Portfolio: Epic (Architektur oder Business) DAD, SAFe ermuntern auch zum Einsatz von klassischer Anforderungsdokumentation (wenn nützlich) 23

24 Unsichtbares Integration mit Umwelten Lernen 24

25 25 Integration mit Umwelten

26 Integration in Umwelten in den Frameworks Keines der Frameworks macht Aussagen zur Dienstleister-Integration SAFe bezieht diese implizit im PSI planning mit ein Funding (Allokationvon Mittel auf Vorhaben) nur in SAFe explizit modelliert P2A explizit nur Managements als Treiber des Change modelliert Operations/Betrieb bei DAD über explizite Aktivitäten in Construction modelliert 26 bei SAFe als Teil des System Team modelliert

27 Wie wird im Framework gelernt? DAD Retrospektiven Umfragen Massnahmen mit Erfolgsmessung (measured improvements) Post mortem SAFe Team retrospectives Program Inspect & Adapt meeting 27 P2A Inspect & Adapt

28 Meta Training Berater Literatur Zertifizierung Community 28

29 Welche Trainings/Zertifizierungen werden angeboten? DAD Kurse über disciplinedagileconsortium.org Yellow/green/black belt Zertifizierungen SAFe Kurse über scaledagileacademy.com SAFe Practitioner/Agilist/Program Consultant Zertifizierungen P2A Kurse zur Ausbildung als P2A-Manager in Entwicklung 29

30 Welchen Beraterpool gibt es? DAD diverse US-amerikanische Beratungen, potentiell über IBM buchbar SAFe weltweites Netz von SAFe Agilistsund Program Consultants über scaledagileacademy.com in Deutschland geschätzt ausgebildete SAFe Agilists, per Google+/Xing- Gruppe oder persönlichen Kontakt 30 P2A P2A Engagement Managers

31 Welche Community existiert? DAD LinkedIn Forum Schwerpunkt der Aktivität in USA/Kanada International: scaledagileacademy.com DACH: Google+ Gruppe, Xing Gruppe P2A 31 Nichtöffentliche Community

32 Gibt es Literatur? 32 DAD Ambler: Disciplined Agile Delivery Larman/Vodde: Practises for Scaling Lean and Agile Development SAFe P2A Leffingwell: Agile Software Requirements Cobb: Managed Agile Development Buch voraussichtlich Spätsommer

33 Subjektive Einschätzung der Frameworks DAD hat praktisch keine Skalierungsempfehlung für sehr grosse Projekte, adressiert aber den Konzern-Kontext gut DAD hat stärkeren Empfehlungscharakter, hier muss bei konkretem Einsatz viel Transferleistung gebracht werden P2A ist kein Framework mit konkreter Anleitung zur Strukturierung von Grossprojekten, sondern ein Ansatz zur nachhaltigen Unternehmens-Transformation die Organisation entdeckt für sich dann die geeigneten Rollen, Flow, Artefakte im Rahmen der kontinuierlichen Verbesserung 33 SAFe gibt sehr konkret und preskriptiv Rollen, Flow und Artefakte für Grossprojekte vor Aspekte des Change Managements bisher sehr schlicht Nur bei SAFe liegen bisher dokumentierte Case studies mit belegbaren Erfolgen vor DAD/SAFe sind ankopplungsfähig an klassische Organisationsstrukturen Wie agil sind eigentlich DAD und SAFe?

34 Take home P2A nicht wirklich mit DAD, SAFe vergleichbar Es gibt nicht das eine Framework, das den anderen überlegen ist Sie müssen entscheiden, welches Framework anschlussfähiger in Ihrer Organisation ist Plangetriebene Organisationen fahren potentiell mit den präskriptiven Ansätzen von DAD, SAFebesser Potentiell höhere Nachhaltigkeit von agiler Transformation mit P2A, da die Organisation in ihrem Kontext die richtigen Praktiken einführen kann (Empowerment auf Ebene der Organisation) Austausch mit Praktikern in verschiedenen Organisationen essentiell, da bisher eher wenig Erfahrungen mit Frameworks 34

35 Wie weiter? 35 ScrumDay in Berlin kommende Woche SAFe Ausbildung und BOF Xing-Gruppe SAFe Karlsruher Scrum User Group für Austausch zu agilen Grossprojekten entern EnBW-Partner: Ken Schwaber Path to Agility im Juli in Karlsruhe SAP, Telekom, EnBW: GAPS Lutz Ehrlich

36 Details der Unterscheidungen Flow Rollen Artefakte Integration mit den Umwelten 36

37 Flow (1) DAD P2A SAFe Organisationsebene Team, Ausweitung auf Programm angedeutet Umsetzungdes Change auf verschiedenen Ebenen Team Programm Portfolio Spezielle Phasen Inception, Construction, Transition Quartale, gekoppelt an Reifemessung Releases imtaktvon 10 Wochen Spezielle Meilensteine Ende der Phasen Sprint-Endterminebei Sprints von 1-6 Wochen Dauer Inception: Iterative AnforderungsklärungsowieSetup von Team und Architekturrahmen Unterschied zu Scrum Flow Construction: keine wesentlichen Wie wird geplant wie Scrum Transition: Iterativer Rollout Sprintendefür Enterprise Scrum Teamebene: kein Unterschied alleanderenebenen: Verbesserungender Praktiken anstelle Entwicklung von Produkten Releases alle 10 Wochen, darin 4 Sprints a 2 Wochen + 1 HIP-Sprint 2 Wochen Team: XP Praktiken verpflichtend, normalisierte Geschwindigkeit, WSJF Programm: nicht in Scrum Portfolio: nicht in Scrum Team wie Scrum, mit normalisierter Velocity Programm: PSI-Planung teamübergreifend nach festem Ablauf 37 Portfolio: Kanban für Epics

38 Flow (2) DAD P2A SAFe Team: Iterationsmetriken (Burndownetc) und Prozessreife Wie wird reported Fertigstellungsgradmitranged burndown charts MetrikenzurMessung des Grades an Agilität Programm: PSI Metriken (PorgrammBurndown) und Prozessreife Portfolio: Lean KPIs auf Epic- EbenesowieEnterprise Balanced Scorecard in formalisierten PSI- Wie werden Abhängigkeiten aufgelöst keineaussage keineaussage Planungs-Meetings zwischen allen beteiligten Teams verschiedene Strategien ermöglicht: Scrum Backlog Wie werden work items verwaltet Work item stack Work item pool Formales Change Control Board Practise backlog Team: Sprint-Backlog für User Stories Programm: Programm- Backlog von Features Portfolio: Kanban für Epics Wie wird priorisiert keine detaillierten Aussagen Anreicherung der Priorisierung um Risiko neben reinem Geschäftswert ROI für Einführung von Practises aus dem Practise Backlog Priorisierung immer nach weighted shortes job first mit relativereinschätzung von Geschäftswert, Risikound Chancenbewertung 38

39 Details der Unterscheidungen Flow Rollen Artefakte Integration mit den Umwelten 39

40 Rollen DAD P2A SAFe Rollenfür Anforderungsklärung Rollenfür technische Umsetzung Rollen für Koordination Rollen für Governance Primärrollen: Product Owner, Stakeholder Sekundärrollen: Domain Expert Primärrollen: Team Member, Architecture Owner, Team Lead Sekundärrollen: Specialist, Technical Expert, Integrator, Independent Tester Primärrollen: Team Lead, Architecture Owner Rollen für Change Management Skaliert: Leadership Team aus Project Management Subteam, Product Owner Team, Architecture Owner Team (allejeweilsausden Rollen der Teams besetzt) Governance board und governors durch Rotation aus den DAD Teams über Scrum hinaus über Scrum hinaus über Scrum hinaus über Scrum hinaus agile Change Team, Area PO/SM, Chief PO/SM Team: Product Owner Programm: Product Manager Portfolio: Epic Owner Team: Developers and Testers Programm: System Team Programm: Release Train Engineer, System Architect, Release Management Porfolio: Program Portfolio Management Program: User Experience Specialist Portfolio: Enterprise Architect, implizit Berateroder Release Train Engineer 40

41 Rollen DAD P2A SAFe Rollenfür Anforderungsklärung Rollenfür technische Umsetzung Rollen für Koordination Rollen für Governance Primärrollen: Product Owner, Stakeholder Sekundärrollen: Domain Expert Primärrollen: Team Member, Architecture Owner, Team Lead Sekundärrollen: Specialist, Technical Expert, Integrator, Independent Tester Primärrollen: Team Lead, Architecture Owner Rollen für Change Management Skaliert: Leadership Team aus Project Management Subteam, Product Owner Team, Architecture Owner Team (allejeweilsausden Rollen der Teams besetzt) Governance board und governors durch Rotation aus den DAD Teams über Scrum hinaus über Scrum hinaus über Scrum hinaus über Scrum hinaus agile Change Team, Area PO/SM, Chief PO/SM Team: Product Owner Programm: Product Manager Portfolio: Epic Owner Team: Developers and Testers Programm: System Team Programm: Release Train Engineer, System Architect, Release Management Porfolio: Program Portfolio Management Program: User Experience Specialist Portfolio: Enterprise Architect, implizit Berateroder Release Train Engineer 41

42 Rollen DAD P2A SAFe Rollenfür Anforderungsklärung Rollenfür technische Umsetzung Rollen für Koordination Rollen für Governance Primärrollen: Product Owner, Stakeholder Sekundärrollen: Domain Expert Primärrollen: Team Member, Architecture Owner, Team Lead Sekundärrollen: Specialist, Technical Expert, Integrator, Independent Tester Primärrollen: Team Lead, Architecture Owner Rollen für Change Management Skaliert: Leadership Team aus Project Management Subteam, Product Owner Team, Architecture Owner Team (allejeweilsausden Rollen der Teams besetzt) Governance board und governors durch Rotation aus den DAD Teams über Scrum hinaus über Scrum hinaus über Scrum hinaus über Scrum hinaus agile Change Team, Area PO/SM, Chief PO/SM Team: Product Owner Programm: Product Manager Portfolio: Epic Owner Team: Developers and Testers Programm: System Team Programm: Release Train Engineer, System Architect, Release Management Porfolio: Program Portfolio Management Program: User Experience Specialist Portfolio: Enterprise Architect, implizit Berateroder Release Train Engineer 42

43 Rollen DAD P2A SAFe Rollenfür Anforderungsklärung Rollenfür technische Umsetzung Rollen für Koordination Rollen für Governance Primärrollen: Product Owner, Stakeholder Sekundärrollen: Domain Expert Primärrollen: Team Member, Architecture Owner, Team Lead Sekundärrollen: Specialist, Technical Expert, Integrator, Independent Tester Primärrollen: Team Lead, Architecture Owner Rollen für Change Management Skaliert: Leadership Team aus Project Management Subteam, Product Owner Team, Architecture Owner Team (allejeweilsausden Rollen der Teams besetzt) Governance board und governors durch Rotation aus den DAD Teams über Scrum hinaus über Scrum hinaus über Scrum hinaus über Scrum hinaus agile Change Team, Area PO/SM, Chief PO/SM Team: Product Owner Programm: Product Manager Portfolio: Epic Owner Team: Developers and Testers Programm: System Team Programm: Release Train Engineer, System Architect, Release Management Porfolio: Program Portfolio Management Program: User Experience Specialist Portfolio: Enterprise Architect, implizit Berateroder Release Train Engineer 43

44 Details der Unterscheidungen Flow Rollen Artefakte Integration mit den Umwelten 44

45 Artefakte DAD P2A SAFe Anforderungsdokumentation Empfehlung: leichtgewichtige Projektvision, Spezifikation Work items priorisiertnachwert und Risikoim Arbeitsspeicher Team: wie Scrum Programm: Vision, Roadmap, Programm Backlog mit Features Portfolio: Business und Architektur-Epics in Kanban Lösungsdokumentation Empfehlung: leichtgewichtig, kontinuierlich erzeugt Tiefe und Zeitpunkt der Erzeugung abhängig vom Kundenkontext empfohlen sind Domain Model und Use Case model Projektmanagement-Dokumentation Ranged Burndown Charts, Risikoliste Change Management Dokumentation keineaussage Metrik-Datenbank mit historischer Projektinformation Practise Backlog und Practise database Team: Team Metriken Programm: PSI reports, Feature completeness reports, Programm Metriken Portfolio: Enterprise Balanced Scorecard Team: Team Metriken Programm: Programm Metriken 45

46 Artefakte DAD P2A SAFe Anforderungsdokumentation Empfehlung: leichtgewichtige Projektvision, Spezifikation Work items priorisiertnachwert und Risikoim Arbeitsspeicher Team: wie Scrum Programm: Vision, Roadmap, Programm Backlog mit Features Portfolio: Business und Architektur-Epics in Kanban Lösungsdokumentation Empfehlung: leichtgewichtig, kontinuierlich erzeugt Tiefe und Zeitpunkt der Erzeugung abhängig vom Kundenkontext empfohlen sind Domain Model und Use Case model Projektmanagement-Dokumentation Ranged Burndown Charts, Risikoliste Change Management Dokumentation keineaussage Metrik-Datenbank mit historischer Projektinformation Practise Backlog und Practise database Team: Team Metriken Programm: PSI reports, Feature completeness reports, Programm Metriken Portfolio: Enterprise Balanced Scorecard Team: Team Metriken Programm: Programm Metriken 46

47 Artefakte DAD P2A SAFe Anforderungsdokumentation Empfehlung: leichtgewichtige Projektvision, Spezifikation Work items priorisiertnachwert und Risikoim Arbeitsspeicher Team: wie Scrum Programm: Vision, Roadmap, Programm Backlog mit Features Portfolio: Business und Architektur-Epics in Kanban Lösungsdokumentation Empfehlung: leichtgewichtig, kontinuierlich erzeugt Tiefe und Zeitpunkt der Erzeugung abhängig vom Kundenkontext empfohlen sind Domain Model und Use Case model Projektmanagement-Dokumentation Ranged Burndown Charts, Risikoliste Change Management Dokumentation keineaussage Metrik-Datenbank mit historischer Projektinformation Practise Backlog und Practise database Team: Team Metriken Programm: PSI reports, Feature completeness reports, Programm Metriken Portfolio: Enterprise Balanced Scorecard Team: Team Metriken Programm: Programm Metriken 47

48 Artefakte DAD P2A SAFe Anforderungsdokumentation Empfehlung: leichtgewichtige Projektvision, Spezifikation Work items priorisiertnachwert und Risikoim Arbeitsspeicher Team: wie Scrum Programm: Vision, Roadmap, Programm Backlog mit Features Portfolio: Business und Architektur-Epics in Kanban Lösungsdokumentation Empfehlung: leichtgewichtig, kontinuierlich erzeugt Tiefe und Zeitpunkt der Erzeugung abhängig vom Kundenkontext empfohlen sind Domain Model und Use Case model Projektmanagement-Dokumentation Ranged Burndown Charts, Risikoliste Change Management Dokumentation keineaussage Metrik-Datenbank mit historischer Projektinformation Practise Backlog und Practise database Team: Team Metriken Programm: PSI reports, Feature completeness reports, Programm Metriken Portfolio: Enterprise Balanced Scorecard Team: Team Metriken Programm: Programm Metriken 48

49 Details der Unterscheidungen Flow Rollen Artefakte Integration mit den Umwelten 49

50 Umwelt DAD P2A SAFe Management PMO Getrennte QA-Organisation mit linearem Planungsansatz nicht hilfreich, sollte Teams statt dessen bei der Sammlung/Verbreitung von best practises unterstützen getrennte Tests denkbar, aber QA sollten eingebettet sein Funding Operations Offshore-Dienstleister werden zum zentralen Treiber beim Rollout in der Transition-Phase muss als Chief Product Owner für die agile Transformation auftreten trifft Investment-Entscheidungen und ist Konsument der Enterprise Scorecard sowie anderer Metriken in klassischer Ausprägung als Altlast betrachtet, sollte sich transformieren zuagile Program Portfolio Management, welches den Kanban- Prozess moderiert keine explizite Aussage, Tester sollten generell im Team sein wird über Portfolio-Ebene explizit modelliert implizit im System Team angesprochen, stellt Integrationssysteme bereit nimmt an PSI Release Plannings teil, teilweise synchron an Offshore- Lokation Klassisch gesteuerte Teams können in Release Train (Programm) eingekoppelt werden, der meiste Nutzen erst bei Einsatz von ScrumXP aufd er Teamebene Enterprise Architekt Enterprise sollten DAD Teams unterstützen und bei kritischen Projekten Architecture Owner werden explizit modelliert 50

51 Umwelt DAD P2A SAFe Management PMO Getrennte QA-Organisation mit linearem Planungsansatz nicht hilfreich, sollte Teams statt dessen bei der Sammlung/Verbreitung von best practises unterstützen getrennte Tests denkbar, aber QA sollten eingebettet sein Funding Operations Offshore-Dienstleister werden zum zentralen Treiber beim Rollout in der Transition-Phase muss als Chief Product Owner für die agile Transformation auftreten trifft Investment-Entscheidungen und ist Konsument der Enterprise Scorecard sowie anderer Metriken in klassischer Ausprägung als Altlast betrachtet, sollte sich transformieren zuagile Program Portfolio Management, welches den Kanban- Prozess moderiert keine explizite Aussage, Tester sollten generell im Team sein wird über Portfolio-Ebene explizit modelliert implizit im System Team angesprochen, stellt Integrationssysteme bereit nimmt an PSI Release Plannings teil, teilweise synchron an Offshore- Lokation Klassisch gesteuerte Teams können in Release Train (Programm) eingekoppelt werden, der meiste Nutzen erst bei Einsatz von ScrumXP aufd er Teamebene Enterprise Architekt Enterprise sollten DAD Teams unterstützen und bei kritischen Projekten Architecture Owner werden explizit modelliert 51

52 Umwelt DAD P2A SAFe Management PMO Getrennte QA-Organisation mit linearem Planungsansatz nicht hilfreich, sollte Teams statt dessen bei der Sammlung/Verbreitung von best practises unterstützen getrennte Tests denkbar, aber QA sollten eingebettet sein Funding Operations Offshore-Dienstleister werden zum zentralen Treiber beim Rollout in der Transition-Phase muss als Chief Product Owner für die agile Transformation auftreten trifft Investment-Entscheidungen und ist Konsument der Enterprise Scorecard sowie anderer Metriken in klassischer Ausprägung als Altlast betrachtet, sollte sich transformieren zuagile Program Portfolio Management, welches den Kanban- Prozess moderiert keine explizite Aussage, Tester sollten generell im Team sein wird über Portfolio-Ebene explizit modelliert implizit im System Team angesprochen, stellt Integrationssysteme bereit nimmt an PSI Release Plannings teil, teilweise synchron an Offshore- Lokation Klassisch gesteuerte Teams können in Release Train (Programm) eingekoppelt werden, der meiste Nutzen erst bei Einsatz von ScrumXP aufd er Teamebene Enterprise Architekt Enterprise sollten DAD Teams unterstützen und bei kritischen Projekten Architecture Owner werden explizit modelliert 52

53 Umwelt DAD P2A SAFe Management PMO Getrennte QA-Organisation mit linearem Planungsansatz nicht hilfreich, sollte Teams statt dessen bei der Sammlung/Verbreitung von best practises unterstützen getrennte Tests denkbar, aber QA sollten eingebettet sein Funding Operations Offshore-Dienstleister werden zum zentralen Treiber beim Rollout in der Transition-Phase muss als Chief Product Owner für die agile Transformation auftreten trifft Investment-Entscheidungen und ist Konsument der Enterprise Scorecard sowie anderer Metriken in klassischer Ausprägung als Altlast betrachtet, sollte sich transformieren zuagile Program Portfolio Management, welches den Kanban- Prozess moderiert keine explizite Aussage, Tester sollten generell im Team sein wird über Portfolio-Ebene explizit modelliert implizit im System Team angesprochen, stellt Integrationssysteme bereit nimmt an PSI Release Plannings teil, teilweise synchron an Offshore- Lokation Klassisch gesteuerte Teams können in Release Train (Programm) eingekoppelt werden, der meiste Nutzen erst bei Einsatz von ScrumXP aufd er Teamebene Enterprise Architekt Enterprise sollten DAD Teams unterstützen und bei kritischen Projekten Architecture Owner werden explizit modelliert 53

54 Umwelt DAD P2A SAFe Management PMO Getrennte QA-Organisation mit linearem Planungsansatz nicht hilfreich, sollte Teams statt dessen bei der Sammlung/Verbreitung von best practises unterstützen getrennte Tests denkbar, aber QA sollten eingebettet sein Funding Operations Offshore-Dienstleister werden zum zentralen Treiber beim Rollout in der Transition-Phase muss als Chief Product Owner für die agile Transformation auftreten trifft Investment-Entscheidungen und ist Konsument der Enterprise Scorecard sowie anderer Metriken in klassischer Ausprägung als Altlast betrachtet, sollte sich transformieren zuagile Program Portfolio Management, welches den Kanban- Prozess moderiert keine explizite Aussage, Tester sollten generell im Team sein wird über Portfolio-Ebene explizit modelliert implizit im System Team angesprochen, stellt Integrationssysteme bereit nimmt an PSI Release Plannings teil, teilweise synchron an Offshore- Lokation Klassisch gesteuerte Teams können in Release Train (Programm) eingekoppelt werden, der meiste Nutzen erst bei Einsatz von ScrumXP auf der Teamebene Enterprise Architekt Enterprise Arch sollten DAD Teams unterstützen und bei kritischen Projekten Architecture Owner werden explizit modelliert 54