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

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.

20. Produktivität - Prozesssicherheit
ScrumMaster Team

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

29. CoP agile&lean@EWE

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

40. Betriebskennzahlen
Planung Produktivsetzung FeedbackUmsetzung