Einstieg in die agile EntwicklungGroßprojekterfahrung bei Otto

sven.guenther@ottogroup.com henning.wolf@it-agile.de

Agenda

• Wer ist Otto, was ist NOA?• Ausgangslage und Zielsetzung• Vorgehen / Timeline• Das Neue Liefermodell (Kurzvorstellung)• Aktueller Stand• Was wir heute anders machen würden• Lernerfahrungen in acht Episoden• Ausblick und Fazit

Die otto group ist weltweit zweitgrößter Online­Anbieter im Endkundengeschäft

• 123 Einzelfirmen• 19 Länder• 53.000 Mitarbeiter• Segmente

• Multichannel‐Einzelhandel• Finanzdienstleistungen• Service

NOA ist eines der größten IT­Einzelprojekte des Konzerns

Host‐Migration

0

50

100

150

200

NOA ist eines der größten IT­Einzelprojekte des Konzerns

Kunde

Artikel

AuftragSendung

~70 Mio.

~5 Mio.

~1 Mio. pro Tag ~500.000 pro Tag

NOA Abteilungsstruktur

Abteilung Auftrag

Abteilung Kunde

Abteilung Artikel

Abteilung Lieferung

Zentrale Dienste

Analyse

Entwicklung

AnalyseEntwicklung

Analyse

Analyse

Entwicklung

Entwicklung

Situation Ende 2007

• Lange Releasezyklen statt geplant 2-3 pro Jahr nur 1-2

• Langer Zeitraum von Abgabe Fachbereichskonzept bis zum Rollout >1 Jahr

• Späte Änderungen durch Fachbereich werden teuer und führen zu Unzufriedenheit auf beiden Seiten

• Viele Abhängigkeiten zwischen Projekten vorhanden

• Integration der Software erst zum Ende der Entwicklungsphase

Ziele für ein neues Entwicklungsmodell

1. Häufigere und flexiblere Auslieferung2. Bessere Qualität liefern3. Tests effektiver durchführen4. Entwicklung kostengünstiger gestalten5. Schnellere Reaktion auf Änderungen ermöglichen6. Geplante Termine zuverlässig einhalten7. Personal gleichmäßiger auslasten

Timeline

ErstePilotprojektestarten

ExternerCoach kommt dazu

Erste agileMultiplikatoren-schulungen

GO! Vom Vorstand

WeitereAbteilungenfolgen

JAX

Timeline

Wie sind wir vorgegangen?

1 Entwicklung

2 Analyse

3 Reporting / Management

4 Kunde

5 Andere Systeme

optional

Anforderung

Themenporträt Vorläufiges Angebot

IT-Konzept

PriorisierteFeatureliste

Detaillierte Stories für Iteration 1

Iteration 2 Iteration 3Iteration 0 (Exploration) Iteration 1

Verbindliches Angebot

Detaillierte Stories für Iteration 3

Detaillierte Stories für Iteration 2

Grob- Architektur• Design• Entwicklung• Modultest• Fachlicher Test

• Design• Entwicklung• Modultest• Fachlicher Test

• Design• Entwicklung• Modultest• Fachlicher Test

Kurzüberblick Neues Liefermodell

Kurzüberblick Neues Liefermodell

Fachliche / technische Integration

Performance und Stabilität

User Acceptance Test

Projektentwicklung

Produkttest

Der Iterationsablauf (looks like Scrum)

Stand heute

• Management steht dahinter• Analyse nimmt die Aufteilung der Anforderungen in Features und

Storys an (und es erleichtert die Angebote)• Entwickler stehen größtenteils auch dahinter und wollen agil arbeiten• Aber auch schon erste Ergebnisse sichtbar• Zur konkreten Umsetzung herrscht oft Unsicherheit und Unklarheit• Nach wie vor viele Fronten:

– Builds, die oft zerbrechen– Mehr automatisierte Tests nötig– Wissensinseln behindern die Planung und die Teambildung– Integrationstests dauern sehr lange und sind instabil

Was hätten wir besser machen können / sollen?

Frühes Abholen der Basis über• Mehr Informationen• Probleme abfragen und berücksichtigen

Frühere Festlegungen und Vorgaben• Tool•Reporting•Qualitätsstandards•Templates

Lernerfahrungen in Episoden

Mitspielen erlaubt: Pilotprojekte bringen nichts?

• Pilotprojekte mit wenig Ressourcen• Wenig Sichtbarkeit im Bereich• Wenn es schlecht läuft: „Klappt nicht mal im Piloten“ • Wenn es gut läuft: „War ja nur ein Pilot“

• Trotzdem erste Lernerfahrungen möglich/wichtig:– Wie viel Unterstützung des Projekts nötig?– Was fällt den Entwicklern / Analysten schwer daran?– Welche Infos fehlen?– Welchen Rahmen muss man setzen?

• Wen informiert man wann über was?• Frühe Info prinzipiell hilfreich, verwirrt aber

manche• Zu späte Info verärgert und führt zu

Wildwuchs („das war ja nicht klar, da haben wir es irgendwie gemacht“)

• Schön, wenn man als Ansprechpartner da ist, aber nur wenige kommen von alleine

• Viel Fragen, um rauszubekommen, was man nicht weiß und was die anderen nicht wissen

Info, Info, Info oderIch weiß nicht, was Du nicht weißt

Code­Wissensinseln contra Team

• Wenn sich für viele Themen jeweils nur einer auskennt, steht vermeintlich immer fest, wer es bei der Planung tun muss

• Da treffen die Ziele Planungssicherheit und Effizienz auf einander

Produkt CentralLogistic Services (CLS)

LV

P07 Run

P05 Run

P02 Run

P0...Run

P01 Run

Produkt CentralOrder Services (COS)

System NOA

Auftragsverwaltung

DAT7NOABP

D3NOA

P015 Run

Kundenverwaltung

PreisberechnungBestandszuteilung

Artikelbeilagen-verwaltung &

ZuteilungNINA-Kette

Kundenbuchhaltung Fakturierung

C-Brief Tool

Abrufbreitschaftprüfen

Lieferungs-optimierung

Kategorisierung&

Lieferungsbildung

Mengensteuerung(Dez. + HF)Packplatzbeilagen

EK-Rechner

Anwendungauf EKR

NOA Bestandsverwaltung

EXPORT

SAMMLER

Lager (KR2)

NDEKUBIS /Internet

IBA / OPOS

Rechnungsdatenbank

Teradata

Teradata-Exporte

Lager-kommunikation

Sendungsbeschleunigung

Richtungsermittlung

3GL-Verarbeitung

Effizienzzwang: Beim Planen hinderlich• Alle Meetings werden als Overhead empfunden• Deswegen will man möglichst schnell durch jedes Meeting

kommen• Also wird schnell geplant und nicht diskutiert• Dabei steckt in den Diskussionen viel wert!• Das Planen ist wichtiger als der Plan!

Hierarchie vs. Rolle: Scrum­Master übernehmen Sie

Bisherige Hierarchie schwer abzubauen

Abteilungsleiter

Entwicklungsleiter Projektleiter

Entwickler

Entwickler

Entwicklungsleiter Projektleiter

Entwickler

Scrum-Master achten darauf, dass die Teams den Prozess richtig leben

• Erste Retrospektiverfahrungen:– Retrospektiven sind nicht immer leicht– Gibt es was Neues oder

ist es nicht eigentlich wie immer?– Was wird wohl passieren,

wenn man mal was sagt? (ändert sich ja doch nichts)

– „Können wir jetzt wieder entwickeln?“

• Auch hier hilft Moderation und Scrum-Master mit der Aufgabe zur Verbesserung

• Festgelegte Maßnahmen müssen umgesetzt werden!

Hinterher ist man immer schlauer:Retrospektiven wichtig aber ungewohnt

Retro

Gebrochene Builds:Das wird schon wieder ...• Viele gebrochene Builds• Es wird keine Verantwortung übernommen• Kein schnelles Feedback• Lange Buildzeiten• An der Lösung wird noch gearbeitet

Störungen ...... damit können Sie rechnen!

• Viele Störungen in der Iteration durch– Wartung– Bugfixing in Teststufen– Analysenachfragen– Schätzungen für neue Projekte

• Alles einplanen, was geht• Beispielsweise durch leere Storys als Container• Gedeckelter Aufwand für Störungen

• Langer Atem ist nötig• Große Organisationen bedürfen früher Standardisierung

(zumindest muss ein grober Rahmen abgesteckt sein, sonst entstehen viele Varianten)

• Ausbildung und Information für alle wichtig• Scrum-Master-Rolle (Methodenbegleitung) hilfreich

• Ausblick: – Es geht weiter, wir haben Fahrt aufgenommen– Builds stabilisieren– Baustelle: Integrationstests– Harte Qualitätskriterien einführen– Vorgehen in den Teams standardisieren– Ausrollen in der gesamten Otto-IT

Fazit und Ausblick