Description on how we introduced Scrum at mobile.de across the whole organization, including a Meta-Scrum w/ the Management Team.
The introduction took place after a migration of the platform from perl to java. This led to a feature jam, which we could only get rid of by introducing something fundamentally different. Further, we were in a situation, where we needed to change from a single-large-project to a lots of concurrent-projects organization.
Even though we strugggled, we managed to get the first 12 projects done in time and budget.
The presentation describes how we introduced Scrum and describes some observations.
Journey Into Agile Land / Unsere Reise ins agile Land - Pecha Kucha
Scrum-Einführung bei mobile.de
1. Scrum Einführung bei mobile.de
23.06.2009 / Hamburg
Hotel Atlantic
Markus Andrezak /
mandrezak@team.mobile.de
Projekt Management
1
2. Wer bin ich?
Markus Andrezak
mandrezak@team.mobile.de
Projekt Manager
> Teil der mobile.de Technology Abteilung
> Product Development
> Delivery Management
Davor:
Projektleitung, Entwicklungsprozeß
und Enterprise Architecture bei
AOL, Capgemini, Philips,
Aventis, Heidelberger Druck
2
2
3. Wer sind wir
mobile.de ist Deutschlands größter (Online-)Fahrzeugmarkt
mobile.de gehört zu
Dort gehören wir zur Global Classifieds Group, wie auch:
Alle beschäftigen sich als horizontale oder vertikale Plattform mit
Classifieds.
3
3
6. Mobile.de - größter deutscher Online-Marktplatz für
Fahrzeuge
ca. 1,5 Mrd. PI‘s / Monat (IVW)
> 55 Millionen Visits (IVW)
> ! Verweildauer ca. 42 min
> 1,4 Millionen Inserate
> 33.000 Händler
auch starker B2B Anteil
Großer Sekundärmarkt auf Basis
6
6
7. 2 voll redundante Data Center
jeweils aktiv und voll failoverfähig,
also 50% over capacity
ca. 400 Server produktiv
ca. 1Gbit/s sustained
bandwidth am Tage
7
7
17. Wer macht was?
Dealer Consumer International Marketing, etc.
Product Mgmt, Product owner, Content
Business
Web Development PD QA Site Operations
6 HC ca. 20 HC 8 HC 8 HC
Technology
mobile.international
+Outsourcing (local)
eBay vehicles ! = ca. 120 HC
10 HC +Outsourcing (offshore)
10 HC
17
17
18. Warum Scrum? Ein Projekt bedingt viele Projekte
Projekt 1
Ein großes Projekt, Projekt 1
Ein Projektmanager Projekt 2 (incl. Outsourcing)
Kein Outsourcing Projekt 2 Projekt 3
(Scrum-like)
Projekt 4 (incl. Outsourcing)
Search-Projekt
(Scrum-like) Projekt 3 Projekt 5 (Outsourced)
Projekt 6
Projekt 4
(Scrum-like) Projekt 7 (incl. Offshoring)
angesammelter Projekt 8
Featurestau Projekt 5
Projekt 9
1:1 Platform Migration Neue strategische Projekte
Neue Features verlangt
Perl -> Java -> Start Gear Programm
Neue Projekte
Featurestau Alles in Scrum
Jan 2007 Mar 2008 Mai 2008 Sept 2008
18
18
19. Ziele der Scrum-Einführung
Skalierbarkeit über viele Projekte
Bezieht die Gesamtorganisation mit ein
Ausnutzung der Ansätze selbstverantwortlicher Kultur
Steuerbarkeit des Multiprojektansatzes
Einheitlich
schlank & lightweight
19
19
20. Wie haben wir Scrum eingeführt?
Überhastet ;-)
Uns war klar,
dass wir nicht gut vorbereitet sind
dass wir nicht das ganze Problem überschauen
dass wir unterwegs auf viele unbekannte Probleme treffen
dass wir gerade noch viele andere Baustellen haben:
Multiprojektmanagement
Outsourcing, Offshoring
20
20
21. Deshalb …
Wollten wir trotzdem und nahmen uns vor nicht aufzugeben
und holten einen Coach (Stefan Roock (CST), it-agile.de)
Zur Unterstützung
Als Sparringpartner für alle Parteien
Als wandelnde Lösungsbibliothek
Als Moderator bzgl. Resitance To Change im täglichen Geschäft
21
21
22. First things first
Collocated Teams quer über alle Disziplinen: PO, Entwickler, Web
Development, QA, Content, Site-Ops etc.)
!!! Umzugsmarathons!!!
Wir etablierten die zentralen Instanzen von Scrum in allen Teams:
3-weekly Sprints
Meetings: Sprint Planning, Daily Scrum, Sprint Review,
Retrospektive,
Deliverables: Product Backlog, Sprint Backlog, Burn Down, Product
Burnup
Rollen: Scrum Master, Product Owner, etc.
22
22
23. Erste Schwierigkeiten
Banales: Umzugsmarathons vorprogrammiert!
Vorlieben: Zu geringe Vorgaben an Prozeßgestaltung gemacht (?)
Identifikation: Code Ownership geht verloren
Projektleiter -> welche Rolle in Bezug zu Scrum Master und PO?
PO: iteratives Vorgehen ungewohnt, MMFs nicht etabliert, liebt big
bang (braucht ihn), mag PRD’s (aka Pflichtenhefte)
Die Wand! - Unterschiedliche Akzeptanz von Teamkommunikation,
Kollaboration und Gruppenprozeßen
23
23
24. Mehr Schwierigkeiten
Schätzung im Sprint
Feature Points in Planning Poker & yesterday’s wheather
don‘t overdo it!
Wann sind wir fertig? Product Progress Tracking?
EPICs in Epic Points schätzen
Product Burnup mappt Feature Points auf Epic Points
Descoping & Priorisierung zur flexiblen Steuerung nicht eingeübt
Commitment - Was ist das? Wie committed sich ein Team auf
vorgegebene Ziele?
24
24
25. Hat‘s geklappt? Erste Welle.
Alle Projekte lieferten on time, schlimmstenfalls 3 Wochen (=1
Release) Verzug
Selbststeuerung: Ja, zum großen Teil
Multiprojektmanagement: Ausbaubar
Einschränkungen vorhersehbar:
Descoping, Beschränkung auf’s Notwendige fällt schwer.
Multiprojektmanagement: Koordination zwischen den Projekten
Mgmt. Involvement, technische Probleme (Branches, Merges)
25
25
26. Verbesserungen: Multiprojektmgmt.
Einführung von Scrum of Srums der TL (technische Koordination), PO
(Koordination der Requirements), DM (Organisatorisch) -> Meta Scrum
Mgmt Team Meta
Scrum
Unsolved
Impediments
Requirements Technical Organizational
Coordination Coordination Coordination
SoS SoS SoS
Product Owners Technical Leads Delivery Managers
Unsolved
Impediments
Projekt 1 Projekt 2 Projekt 3 Projekt ... Projekt ... Projekt n
26
26
27. Wir wollen mehr! Echte Agilität!
Die Basics des Nokia Test (*) würden wir bestehen.
Wir stellen fest, dass Agilität letztlich doch einfach Meisterschaft
in technischen Grunddisziplinen und Disziplin bedeutet:
Durchlaufzeiten veringern:
Branching & merging vereinfachen
Test automation erhöhen (Story tests)
Work in progress begrenzen
Stop-the-line-Mentalität einüben
Unit Test coverage erhöhen
User Stories besser schneiden (MMF, EPICS, descoping, Occams Razor)
(*) http://agileconsortium.blogspot.com/2007/12/nokia-test.html
27
27
28. Bsp.: Maintenance Workflow als Kanban
Den Maintenance Workflow für die internationalen Plattformen haben
wir auf Kanban umgestellt
> bildet den aktuellen Prozeß so ab wie er ist
> lässt Disziplinen bestehen, will sie nicht auflösen
> begrenzt WIP (Work-In-Progress)
> erleichert Identifikation von Bottlenecks
> unterstützt Qualität direkt
> bringt geringe restistance to change mit sich
> ermöglicht unterschiedliche Behandlung unterschiedlicher
Tickets in „service classes“
> beobachten das Resultat
28
28