OOP2015 agile im konzern gloger ewe
4 gefällt mir1,445 aufrufe
Das Dokument behandelt die agile Transformation eines großen Unternehmens im Energiesektor, mit einem Fokus auf Scrum-Implementierungen zur Steigerung der Kundenzufriedenheit und Effizienz. Es werden Herausforderungen, Lösungsansätze, aktuelle Resultate und Lessons Learned im Zuge der agile Transition vorgestellt. Die agile Methodik wird als Schlüssel für die Überwindung vorheriger Engpässe und die Verbesserung der internen Zusammenarbeit sowie der Produktentwicklung hervorgehoben.
OOP2015 agile im konzern gloger ewe
- 1. Geschichte(n) einer Transition Agile im Konzern Vortrag, OOP 2015, Di 6.2. München
- 2. Ganzheitliche Lösungen in drei Schlüsselbranchen 2 EWE bündelt mit Energie, Telekommunikation und Informationstechnologie die Schlüsselkompetenzen für nachhaltige, intelligente Energiesysteme
- 3. EWE – eines der größten Unternehmen im Nordwesten 3 Umsatz 8,9 Mrd. € Ergebnis 57,2 Mio. € Mitarbeiter Ø 9.162
- 4. Sehr guter Service, Beratung und die Nähe zu unseren Kunden sind unsere Stärke 4 2013 1,4 Mio. Stromkunden 1,6 Mio. Gaskunden 680.000 Telekommunikationskunden
- 5. Selbst sicher zum Erfolg.
- 6. Die Leistungen Scrum Grundlagen Arbeit im Team Best Practices für die Produkt- entwicklung Agile HR als unterstützend e und fördernde Funktion Zusammenarb eit mit Lieferanten Führungsmod elle für die Selbst- organisation Ausrichtung der Organisation auf Agilität Die Veränderung zur Agilität kann nicht top-down verordnet werden. Sie wächst aus kleinen, selbstorganisierten Einheiten und verändert Organisationen von innen heraus. Wir begleiten jede Stufe dieses Entwicklungsprozesses.
- 7. Team Scrum-Grundlagen Arbeit hands-on mit den Teams Ausbildung und Training on-the-job von ScrumMastern und Product Ownern Bereitstellung von Interim ScrumMastern und Interim Product Ownern bei personellen Engpässen • Team • Team • Team • Abteilung • Abteilung • Organisation Wir arbeiten auf allen Ebenen Abteilung Abteilungsübergreifende Skalierung von Scrum Unterstützung des Anforderungsmanagements Produktentwicklung mit Design Thinking Schärfen der Produktvision Führungstrainings für das mittlere Management Organisation Beratung des Managements bei Analyse und Aufbau von Change- Prozessen Bilden von Management- und Transition-Teams Internationale Skalierungen Virtuelles Arbeiten
- 8. Helene Valadon Ausbildung & Erfahrung Studium der Wirtschaftswissenschaften, Université de Lille I Business Coach Projektleiterin und Beraterin für europäische Förderprogramme in der industriellen Technologie, Stuttgart Forschungsförderungsgesellschaft Wien Konzeptionierung und Aufbau eines Technologieparks (Bratislava) Expertise Agile Leadership Coaching Aufbau und Begleitung von Transition Teams Skalierung von Scrum Agile mit SAP, Agile in der Hardware Scrum-Implementierungen in den Branchen: Automotive, Medizintechnik, Energiewirtschaft, Finanzdienstleistung, Versandhandel, Versicherung Kontakt: helene.valadon@borisgloger.com
- 9. Markus Theilen Diplom-Informatiker 2001 – 2012 bei BTC AG als Software-Entwickler und Software- Architekt in easy+-Entwicklung (ABAP) tätig Erstellung und Etablierung von Entwicklungsvorgaben Einführung von automatisierten Prüfungen von Entwicklungsobjekten seit 2012 als IT-Koordinator für E-IT-Gruppe Abrechnung und Marktpartner-Kommunikation (AMK), zuständig für Entwicklungskoordination und Betrieb easy+ Seit 2009 stellv. Sprecher des DSAG-Arbeitskreis Development Seit Oktober 2014 SAP Mentor Kontakt: markus.theilen@ewe.de
- 10. easy+ Vorstellung – Rückblick 2012
- 11. • Umfasst die Komponenten Ablesung, Abrechnung, Fakturierung und Forderungsmanagement, Marktkommunikation und Reporting/Controlling für Energiedienstleistungen des EWE-Konzerns • Vollständige Eigenentwicklung auf Basis von SAP ERP 6.0 • Funktional in etwa vergleichbar mit SAP IS-U • Komplett in ABAP entwickelt • Rund 100 Personen in der Entwicklung tätig, ca. 200 Personen involviert in Fachbereichen, I-IT und BTC Fachbereiche • Kunden • User ISIS I-IT • Product Owner BTC AG • Scrum Master • DevTeams Vorstellung easy+
- 12. 10 TByte Datenvolumen 10 Mio. Lines of Code 1.600 Pakete 11.000 Programme 8.600 Klassen und 1.500 Interfaces 1.500 Funktionsgruppen 4.400 Tabellen Technische Daten rund um easy+
- 13. Rückblick 2012 die übliche Fragen… Wie können wir mit die Anforderungen aus den verschiedene Fachbereichen (über 30 Ansprechpersonen) zu recht kommen? Wie können wir sicherstellen dass wir an dem gerade wichtigsten Thema arbeiten? Wie bekommen wir Transparenz über die Projekte, deren Fortschritte und Ergebnisse? Wie können wir schneller werden und gleichzeitig die Qualität unserer Applikation (u.a. Performance und Verfügbarkeit) garantieren bzw. ausbauen? Könnten wir als Auftragsgeber uns nicht besser auf das Anforderungs-management fokussieren, als auf Ressourcenmanagement beim DL?
- 14. Ausgangslage (1) (2012) Niedrige Kundenzufriedenheit: • Anforderungsstau • Bisher Tests komplett manuell, hoher Aufwand für Fachbereiche bei Releasewechseln und Fehlerbehebungen • 2 Release pro Jahr Portfolio: • Viele Projekte greifen parallel auf die gleiche Ressourcen zu • Keine Transparenz über Projektfortschritt • IT-Sparprogram Ressourcen: • Mitarbeiter sind zerrissen zwischen verschiedenen Projekten • Viele Kopfmonopole sowohl in der Entwicklung, als beim Fachbereich
- 15. Ausgangslage (2) (2012) Entwicklung: • Strenger Wasserfallprozess • Releasezyklen von sechs Monaten mit aufwendigem Releasewechsel • Kaum Änderungen am Scope während der Releasephase Qualität: • 2/3 der Budget für Entwicklung, 1/3 für Fehlerbehebung • Performanceprobleme Betrieb: • Kein definierter Applikationssupport auf technischer Ebene • Kaum Sichtbarkeit des Applikationsbetriebs für die Entwicklungsmannschaft
- 16. Scrum bei easy+
- 17. Ziele ▪ Wir wollen die Kundenzufriedenheit im Fokus stellen. ▪ Wir müssen schneller werden: Verkürzung der Lieferzeit (Vorablieferung, kürzere Releasezyklen oder sogar kein Release mehr?) ▪ Wir müssen mit Veränderung umgehen können (kontinuierliches Anforderungsmanagement) ▪ Wir brauchen mehr Transparenz über Projektfortschritte ▪ Wir müssen die Qualität und die Performance erhöhen und die Wartungskosten reduzieren ▪ Wir wollen die Testaktivitäten weg von den Fachbereichen verlagern Warum Scrum bei easy+?
- 18. „Die Komplexität und Abhängigkeiten von Projektdurchführungen in SAP kann mit Scrum nicht beherrscht werden“ „In Scrum wird nicht geplant, alle machen was sie wollen!“ Unsere Erfahrung: "Richtig aufgesetzt, funktioniert agile Produktentwicklung selbst in einem regulierte Umfeld ebenso strukturiert wie einWasserfall-Prozess„ „Es ist möglich in regulär en Abständen Kundenwert zu liefern ohne monatelang auf den Big Bang zu warten“ „Wir haben seit Scrum sogar mehr Bewusstsein für Qualität und Kundenzufriedenheit als je zuvor geschafft“ Vorurteile über Scrum und über SAP
- 19. Anforderungsmanagement- Kontinuierliche Planung Product Owner Team Release Grooming Estimation Meeting PO Weekly ▪ 3-Monats-Releases inkl. vielen Vorablieferung ▪ Kontinuierliches Anforderungsmanagement ▪ Wertgetriebene Lieferung (Epic- und Story- Schnitt) ▪ Gemeinsame Priorisierung und Abarbeitung des Backlogs ▪ alle Projektinteressenten (Fachbereich, Stakeholder) beim Scrum Meetings ständig auf den aktuellen Stand und im Austausch miteinander bringen.
- 21. Kundenzufriedenheit Arbeit mit Kunden Review Meeting Discovery Workshop Herausforderung • Fachbereich hat viel Wissen (Fachlichkeit, Produkt) und will bei der Lösungsauswahl („wie“) involviert werden • Fachbereiche waren gewöhnt selbst die Arbeit zwischen mehrere Teams aufzuteilen • Mehrere Fachbereiche in der Anforderungsprozess und der Priorisierungsprozess • Lange Wartezeit bis Releasewechsel Ansatz • Wissensaufbau in den Teams (Fachlichkeit, Produkt) • Cross funktionale Teams können selbständig liefern • Übergeordnete Priorisierung • Vorablieferung • Nah und kontinuierliche Zusammenarbeit! • „nach kürzester Zeit können wir ein Teil des fertigen Produktes testen • und anwenden, Feedback geben, Ideen für die • weitere Implementierungsphase…“
- 22. Herausforderung • Cross funktionale Team trotz SAP Moloch? • Code Ownership? Ansatz • Wissensaufbau in den Teams (Fachlichkeit, Produkt) • Cross-funktionale Teams, aber immer noch Experten- schaft für bestimmte Code-Bereiche • Einsatz agiler Entwicklungsmethoden • Vorsichtiges Refactoring Team Zusammenstellung Scrum Teams Aktuelle Teamschnitt easy+ Teamschnitt easy+ 2013
- 23. Scrum und Betrieb Architekturteam • Team mit applikationsnahen Basistätigkeiten nutzt Kanban als Methode zur Selbst- orgabinsation • Monatliche Reviews und Betriebsreports geben Transparenz über Tätigkeiten und Erfolge • Wichtiges Feedback aus dem Produktivsystem für Scrum-Teams Kanban Board
- 24. Schulung und Coaching • Begleitung der Teams und der einzeln Rollen (Entwickler, ScrumMaster und Product Owner und Management/Transition Team) durch agile Coaches (Boris Gloger consulting) • Schulung und Ausrollen von agilen Entwicklungspraktiken (ASE) • Schulungen Visual Facilitation • SCRUM Informationsveranstaltung für Fachbereich
- 25. Scrum bei easy+ - Die Ergebnisse
- 26. Wo sind wir besser geworden? - Kompakt Planung Umsetzung Produktivsetzung Feedback • Feedback aus FB - von 2 Mal im Jahr auf 2 Mal / Monat (Reviews) - enge Zusammenarbeit • FB fragt nach Scrum! • Anzahl der Vorabauslieferungen - von 12 auf 62 Vorabauslieferungen • stabileres System • Sichtbarkeit des Systemzustandes für Entwickler führt zur Performance-Optimierungen • Plan/ Ist Aufwand - Bis zu 30% Effizienzsteigerungen in der Umsetzung • Verbesserungsmaßnahmen - Wissenstransfer - mehr Testabdeckung • Anforderungsmanagement • Von 9 auf 2 involvierte Instanzen • kein Anforderungsstau • kontinuierliche Planung/Annahme von Anforderung und Priorisierung • Release-Planung • Kontinuierlich • Aufwand 400 PT auf 100 PT (Tendenz weiter sinkend) • Anzahl der CRs - von 152 auf 36
- 27. ▪ Anbindung an easy+ von SAP classic Modul PM (Planned Maintenance) ▪ Erreichung des technischen Durchstichs durch das easy+- und SAP PM-System (und damit deren erste Integration) nach dem ersten Sprint ▪ Lieferung der IT-Lösung in Time und in Budget! ▪ Gut besuchte Reviews mit überwiegend hervorragendem Feedback vom Kunde SCRUM Mehrwert für den Kunden bei MRO (Customization)
- 28. SCRUM neue Zusammenarbeit Meeting Point MRT
- 30. Scrum bei easy+ - aktuelle Herausforderung
- 31. Neue Herausforderung Architekturlandschaft Continious delivery (kleine Batches) Stärkere Unabhängigkeit ohne Steigerung der Wartungskosten Projekte werden immer grösser, übergreifende Zusammenarbeit weiter die Kompetenzen in der Organisation aufbauen Schnittstelle Scrum und Nicht-Scrum Scrum mit Zuliefern Vertragsrahmen für agile Zusammenarbeit Rahmenvertrag basierend auf Ideen des agilen Festpreises
- 32. DANKE!
- 34. Systemlandschaft: IST-Stand TK1 EAK Konsolidierung RCK Produktion easy+ EWE AG EWE TEL (easy+ und SAP Classic) EAE Wartung, Customizing (alle Mandanten) SCE Release – Entwicklung SCK REK SAP Classic EWE AG Entwicklung G.EN (Polen) (easy+ und SAP Classic) ECT ECK TP1 EAP SCP ECP RVK CRM EWE-Vertrieb RCE REE RVE
- 35. Systemlandschaft SAP Systeme: Zielvision Abschaffung der Releasesysteme Produktion easy+ EWE AG EAE SCE SAP Classic EWE AG Entwicklung ECT EAP SCP ECP CRM EWE-Vertrieb EAQ Q1 SCQ ECQ EAK Q2 SCK ECK
- 36. Lessons Learned Scrum und Betrieb • Es werden bestehende Verantwortungen aufgelöst à Es ist frühzeitig zu definieren wie Support geleistet wird à Als Sprint oder mit eigner Organisation • Es wird in die Codeownership eingegriffen à Es ist frühzeitig zu definieren wo Knowhow und Skill für den SourceCode liegt. • Scrum geht von einem Produkt aus, der Betrieb umfasst ein Gesamtwerk à Monitoring und Schwellwerte werden wichtiger und sind unbedingt erforderlich à Die Übergabe Dokumente insbesondere Definition of Done, Story Readiness müssen diszipliniert gelebt werden. Biggest Lesson: Entwickler leben den Freiheitsgrad Restriktionen frühzeitig definieren
- 37. Anforderungsmanagement Alter Prozess zum Anforderungsmanagement ging über viele Instanzen (Anwender, TL FB, Fachkoordinator FB, E-IT Anf.-mgmt, BTC Anf.-mgmt, PL, Expertengremium,…) mit dem Ausfüllen sehr vieler Dokumente und Artefakte (Clarity, PRP, Aufwandschätzlisten, Projektsteckbriefe,…) Im neuen Prozess gibt es im Optimum nur noch 2 Parteien, nämlich den Anwender und den Product Owner. Auch bei den Artefakten und Dokumenten wird sich auf das „Notwendigste“ reduziert (Dokumentation im Jira und SolMan). Planung Umsetzung Produktivsetzung Feedback
- 38. Umsetzung Wissenstransfer • Pairing • Teaminterne Workshops/Vorträge • Communitys of Practice, z.B. zu agilen Softwareentwicklungsmethoden, Testautomatisierung oder zum Solution Manager Einsatz agiler Softwareentwicklungsmethoden • Pair Programming • Test-Driven-Development • Clean Code Qualitätssteigernde Maßnahmen • Testautomatisierung (Unit Tests und eCATT) • Teams testen z.T. gemeinsam mit dem Fachbereich • Immer mehr Tests in den Teams selbst • Teams entwickeln eigene Ideen zur Qualitätssteigerung wie z.B. ein interner Team Review (4-Augen-Prinzip) Planung Umsetzung Produktivsetzung Feedback
- 39. Produktivsetzung • Produktivsetzungen (Auslieferungen) innerhalb von Releases steigen! • Auslieferungen vor den Releasewechseln erfolgen teamabhängig! • Auslieferungen beeinflussen Jobläufe negativ! Lösung: Definierte Produktivsetzungs-Tage • 2 mal pro Monat • Weniger Beeinflussung der Job-Läufe • Stabilisierung Produktionssystem • Abgestimmt mit Fachbereich Lösung: Definierte Abnahmetestphase • Testaussagefähigkeit steigt • Regressionstests werden möglich • Mehr Planbarkeit f. Testaufwände Planung FeedbackProduktivsetzungUmsetzung