Scaled Agile Framework bei EnBW B2Run - Nutzen und Fallstricke»

Transkript

1 Scaled Agile Framework bei EnBW B2Run - Nutzen und Fallstricke» EnBW Informationsverarbeitung Silvia Vierneusel, Projektmanagerin B2Run Stefan Kurock, Projektmanager B2Run 4. Nov. 2014

2 Agenda 1. Kontext: EnBW 2. Das Projekt B2Run: Ziel, Struktur, Ablauf 3. Scaled Agile Framework allgemein und im Projektkontext 4. Bisher beobachteter Nutzen 5. Herausforderungen und Fallstricke 6. Was würden wir anders machen? 7. Zusammenfassung 2

3 1. Kapitel Kontext: EnBW 3

4 Kurzporträt EnBW Energie Baden-Württemberg AG EnBW Energie Baden-Württemberg AG Eines der größten Energieversorgungsunternehmen in Deutschland und Europa Geschäftsfelder: Strom Erzeugung und Handel, Strom Netz und Vertrieb, Gas, Energie- und Umweltdienstleistungen Jahresumsatz 2013: über 20 Milliarden Euro Kunden: rund 5,5 Millionen Mitarbeiter: rund B2B Segment Bundesweiter Vertrieb in allen relevanten B2B-Segmenten Mengengerüst Zählpunkte und Geschäftspartner Verträge in Belieferung und Angebote/Jahr 28,6 TWh Absatz Strom, 6,2 TWh Absatz Gas 4

5 2. Kapitel Das Projekt B2Run: Ziel, Struktur, Ablauf 5

6 Projektauftrag B2Run: Erreichung von definierten Zielkosten für B2B Strom und Aufbau einer Konzern Operations Plattform Auftrag B2Run Hebung von Effizienzpotenzialen innerhalb des Gesamtkonzerns, Erreichung der Zielkosten in 2015 Schaffen der prozessualen Grundlagen für EINE gemeinsame Systemlandschaft für alle Sparten Segmente und Auftraggeber Stringente Orientierung an den SAP Standardprozessen Aufbau einer übergreifenden Systemlandschaft Leitlinien Betrachtung der gesamten Wertschöpfungs-kette im Konzern (Vertriebe, Operations, Handel, IT) Ausrichtung an Leistungsfähigkeiten, nicht an Prozessen. Eine Differenzierung in der Produktion muss nach Leistungsfähigkeiten stattfinden, nicht nach Vertriebssegmenten Einsatz konzernweit nutzbarer Module/ Services 6

7 Zeitplan Umsetzungsprojekt B2Run Q Phase 0 Vorprojekt Phase 1 Detailkonzept Phase 2 Umsetzung Folgeprojekt weitere Konsolidierungen Umsetzungsprojekt Erarbeitung Konzept und Agile Umsetzung in Stabilisierungsphase Grobkonzept (Leistungsfähigkeiten, IT Fähigkeiten, Umsetzungs- Szenario) Ausschreibungsphase Festlegung der Release- Stufen Vorbereitung/ Start für Umsetzung aufeinander aufbauenden Stufen Schulung der Mitarbeiter in neuen Systemen und Prozessen Konfiguration Standardfunktionalität für weitere Konsolidierungen Erhärtung der Vorbereitung Betrieb Effizienzen Abstimmung und Kommunikation 7

8 3. Kapitel Scaled Agile Framework allgemein und im Projektkontext 8

9 SAFe im Projekt B2Run Organisation B2Run als Agile Release Train Nur Betrachtung von Programm- und Team-Ebene Inhouse SAFe Program Consultant SAFe-Ausbildung aller Projektteilnehmer Vollzeit Release Train Engineer (extern) Anpassungen für den Projektkontext Programm-Ebene: Rollen und Artefakte Team: Engineering-Praktiken im SAP-Umfeld Wirtschaftlicher Grooming-Prozess 9

10 Anforderungen (Scope) Vorprojekt Erhebung von Anforderungen mit dem Ziel der Vergabe der Umsetzung per EU-Ausschreibung Fokus auf Leistungsfähigkeiten der bestehenden Applikationslandschaft Abgleich der Leistungsfähigkeiten mit dem SAP-Standard Leistungsfähigkeiten werden in Epics geclustert Ausschreibung auf Basis der Epics und Referenz User Stories Umsetzungsphase Bündelung von Epics in Roadmap Roadmap wird unterteilt in Releases Epics werden in User Stories detailliert Vier Releases alle zwei bis drei Monate mit jeweils drei bis vier Sprints Bündelung von User Stories in Releases, Basis für die Umsetzung Mengengerüste Ca. 350 Leistungsfähigkeiten aus Vorprojekt Ca. 60 Epics Ca. 500 User Stories zu Projektbeginn 10

11 Leistungsfähigkeiten und Abgleich gegen SAP-Standard Die fachlichen Leistungsfähigkeiten wurden definiert, auf das Wesentliche reduziert und mit den IT- Fähigkeiten eines SAP Standards abgeglichen 11

12 Epics und verbundene User Stories Die fachlichen Leistungsfähigkeiten wurden in Epics geclustert und zur Ausschreibung gebracht. Zu den Epics werden im Umsetzungsprojekt die verbundenen User Stories innerhalb der Sprints weiter detailliert. 12

13 Gliederung von User Stories in Releases Die User Stories werden zu Releases zusammengefasst. 13

14 Projektstruktur Umsetzungsphase Vier fachliche Cluster mit jeweils einem Produktmanager (PM) Zwölf Entwicklungsteams mit jeweils einem Product Owner (PO) Fünf Scrum Master (SM) Acht SAP-Entwicklungsteams (vorranging Dienstleister) Ein Cluster mit vier Subteams für Architektur, Qualitätsmanagement, System Team und Schnittstellenmanagement Geteilte Projektleitung durch EnBW und Dienstleister Insgesamt ca. 100 dauerhaft Beteiligte Ca. 50 Fachexperten zur temporären Unterstützung 14

15 4. Kapitel Bisher beobachteter Nutzen 15

16 Transparenz & Steuerungsmöglichkeit Schnelleres Aufbrechen von Konflikten als bei Durchführung mit klassischem Projektmanagement Kurze Zeiträume zur Integration des Gesamtsystems Schnellere Sichtbarkeit von Impediments durch Daily Kaskade Sichtbare Velocity durch öffentliche Taskboards Mehr Verständnis auf Seiten der Fachbereiche durch Integration in Teams Mehr Transparenz über Nutzen ihrer Entwicklungen innerhalb der Teams Sofortige Sichtbarkeit von Prioritätskonflikten bei Releaseplanung 16

17 Annäherung SAP Standard Ausgangspunkt für alle Anforderungen in Form von User Stories ist der SAP Standard Ausloten von Personalisierung und Customizing durch intensive Beratungsleistung/Umsetzung durch den Dienstleiter Erarbeitung von alternativen Lösungsmöglichkeiten mit Kosten/Nutzen Betrachtung Notwendige Erweiterungen durchlaufen den Governance Prozess (SAP Fazit: Intensive Erarbeitung der Möglichkeiten eines SAP Standard Frameworks 17

18 Know How Transfer, Priorisierung, bereichsübergreifendes Denken & Scopeanpassungen Konsequente Priorisierung und Abarbeitung der Anforderungen durch Product Owner nach Business Value Konzentration auf die werthaltigen Leistungsfähigkeiten Aufbau bereichsübergreifendes Know How, gemeinsames Verständnis und Sprache Gemeinsames Lernen der agilen Methode Change for Free Verfahren (Ersetzen neuer Fähigkeiten durch Streichen niedrig priorisierter Fähigkeiten) als Reaktion auf zunehmende Veränderungsgeschwindigkeit durch gesetzl. oder neue Anforderungen des Marktes 18

19 Synchronisation und Takt 19

20 Selbstorganisation Haupt-Fokus der Projektleitung auf Stakeholder Management und Behandlung von Eskalationen Verantwortung fachlicher Inhalte durch PM/PO Priorisierung und Festlegung Business Value durch PM/PO Daily Standup der POs als zentrales Ritual für den Status der Umsetzung und fachlichen Klärungen (ohne zusätzliche Koordinationsleistung) Lokale Abstimmungen mit Fachtestern in Entwicklungsteams 20

21 Gemeinsame Releaseplanung Alle Teams und Programm-Rollen für 2 Tage Vollzeit Gemeinsame Planung eines Releases mit allen Projektbeteiligten Überschlägige Planung von drei bis vier Entwicklungssprints à drei Wochen Länge Kontinuierliche Anpassung der Planung während der Arbeiten am Release Detailplanung im jeweiligen Sprint Planning der Teams Abstimmung der End 2 End Prozesse und Abhängigkeiten Stündliches Commitment zum Releaseumfang und Zielerreichung Ergebnis: Beladung der Sprints Zusage für Release-Scope (Features) durch gesamtes Projektteam Sichtbarkeit von Abhängigkeit auf Dependency Board durch Team 21

22 Planungswerkzeuge 22

23 Sichtbare Abhängigkeiten 23

24 System Demo Durchgängiger End-to-End-Prozess Volle Integration nach drei Releases Über zehn Systeme hinweg Beteiligung aller Teams Keine zentrale Koordination, gemeinsame Leistung aller Teams 24

25 5. Kapitel Herausforderungen und Fallstricke 25

26 Schulung, Coaching & Zusammenspiel mit den Linien Substantielle Aufwände für Schulung der Projektteilnehmer in Methodik Zeit und Coaching-Aufwand für Verhaltensänderungen von Projektteilnehmern ohne Erfahrung in Agilität Geringe Velocity bei geringen Steigerungen in den ersten Sprints bei unerfahrenen Teams Agiles Software-Engineering bei SAP-Projekten in der Energiewirtschaft Neuland Überzeugungsarbeit erforderlich bei Änderung der Rolle und des Engagements der Fachbereiche Key Player müssen mit Entscheidungsbefugnis durch die Linien ausgestattet sein Veränderungsprozess Richtung Selbstorganisation, Eigenverantwortung, übergreifendes Teamplay, etc. darf nicht unterschätzt werden Inkrementell-iterative Planung der Sanierung von Geschäftsbereichen und damit einhergehender Geschäftsprozess-Änderungen nicht immer möglich 26

27 Ressourcen, Freigabeprozess & Zusammenspiel agiler und nicht-agiler Teams Keine detaillierte, gar tagesscharfe Ressourcenplanung, sonders eine ausreichend hohe Verfügbarkeit der Key Player Rechtzeitig eingeplanter Ressourcenhochlauf ist unerlässlich Flexible Verfügbarkeit von Spezialisten muss gewährleistet sein Räumliche Konzentration der Teams drei Tage pro Woche und Nutzung neuer Medien nur ergänzend Angepasste Vorgehensweise für Migration & BI, Erarbeitung eines größeren Arbeitsvorrates durch die Quellen erforderlich Problematik von Freigabeprozessen, die Selbstorganisation der Teams konterkarieren Konstantes Aushandeln zwischen widerstrebenden, aber berechtigten Interessen 27

28 Artefakte & Reporting Geringe Verbreitung von DoR, DoD (Definition of Ready, Definition of Done), statischer Analyse, Code Reviews bei SAP-Projekten im energiewirtschaftlichen Umfeld Overhead durch Reporting-Ansprüche der klassisch gesteuerten Umwelten (wenn keine Verwendung von SAFe-Portfolio-Ebene oder ähnlich) Hohes Tempo bei Deployment nur mit Ausstattung und Verantwortung des System Teams möglich Sinnvolles Reporting nur mit agilem Projektmanagement-Werkzeug machbar ( JIRA Agile reicht nicht! ) 28

29 6. Kapitel Was würden wir anders machen? 29

30 Was wir anders machen würden Mehr Ausbildung und Coaching Mindset agiler Verträge allen Stakeholdern bewusst machen Nur noch 100%-Kräfte Noch mehr Aufmerksamkeit auf Stakeholder Management Fünf Tage vor Ort Ausreichendes Entscheidungsmandat in der Linie einfordern Ausgestattetes Querschnittsthemen Cluster von Anfang an Entscheidungsfähige Personen 30

31 7. Kapitel Zusammenfassung 31

32 Zusammenfassung Ohne Agilität keine Einhaltung des Zeitplans des Projektes B2Run möglich Annäherung an SAP Standard wird durch agile Vorgehensweise unterstützt Deutliche Verringerung des Risikos des Projektes durch den Einsatz von Agilität Keine Heilung für Probleme der (Projekt-) Organisation durch Agilität, aber schnellere und schonungslosere Sichtbarkeit Standard-Scrum alleine nicht ausreichend zur Bewältigung der Komplexität von B2Run Scaled Agile Framework als guter Startpunkt zum Einsatz agiler Verfahren für Großprojekt Deutlicher Aufwand bei Einführung und permanentem Austausch (evtl. Konflikt) mit den Umwelten durch Einsatz von Agilität 32

33 Kontakt EnBW Energie Baden-Württemberg AG Silvia Vierneusel Durlacher Allee Karlsruhe EnBW Energie Baden-Württemberg AG Stefan Kurock Schelmenwasenstraße Stuttgart 33