OOP2015 agile im konzern gloger ewe

938 Aufrufe

Veröffentlicht am

Folien vom Vortrag auf der OOP 2015 mit Hélène Valadon von boris gloger consulting über die agile Transition im EWE-Konzern.

Veröffentlicht in: Leadership & Management
0 Kommentare
3 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
938
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
14
Aktionen
Geteilt
0
Downloads
9
Kommentare
0
Gefällt mir
3
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

OOP2015 agile im konzern gloger ewe

  1. 1. Geschichte(n) einer Transition Agile im Konzern Vortrag, OOP 2015, Di 6.2. München
  2. 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. 3. EWE – eines der größten Unternehmen im Nordwesten 3 Umsatz 8,9 Mrd. € Ergebnis 57,2 Mio. € Mitarbeiter Ø 9.162
  4. 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. 5. Selbst sicher zum Erfolg.
  6. 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. 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. 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. 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. 10. easy+ Vorstellung – Rückblick 2012
  11. 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. 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. 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. 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. 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. 16. Scrum bei easy+
  17. 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. 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. 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.
  20. 20. Produktivität - Prozesssicherheit
 ScrumMaster Team
  21. 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. 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. 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. 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. 25. Scrum bei easy+ - Die Ergebnisse
  26. 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. 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. 28. SCRUM neue Zusammenarbeit Meeting Point MRT
  29. 29. CoP agile&lean@EWE
  30. 30. Scrum bei easy+ - aktuelle Herausforderung
  31. 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. 32. DANKE!
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. 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
  38. 38. 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
  39. 39. Betriebskennzahlen
 Planung Produktivsetzung FeedbackUmsetzung

×