Maersk Line's Agile Journey LESS 2012
- 1. LESS 2012 Maersk Line’sAgile Journey ozlem.yuce@maersk.com @OzzieYuce
- 2. Özlem Yüce • FromIzmir, Turkey • Degree in Economics • Lived in 5 different countries • 10 years at Maersk Line • Product Owner, Lean-Agile coach
- 3.
- 4.
- 5.
- 6. Fragmented Technology Landscape SAF career. P&O marine eProfile iReceivable USI WebSimon maersk.co Nedloyd sailing (SCV) s (MLIS) m schedules www. Mondo- Emergency einfo maersk.co LivePerson World map RKST search pages m VMLO GSMS MARS Reference- (CAF) Portal GUPS service Data MARS ATS2 SAF Rates Followup marine shipments eXport eRates booking Message MEPC W8 broker eXport eDB CCC documen- MEPC Schedules tation Phone SFX Office WS book 3 (document client/ ePayment NGP3 GEO pouch) portal service Tracking 3 sROE NGP3 Payment office MailServic system e service NGP3 mall SAF IBM GEO MEX marine RKEM MCS GCSS payment SCV mainframe (MLIS) portal systems
- 7.
- 8. Analyse Design Test Develop
- 11.
- 12.
- 14.
- 15.
- 17. Introduction to Agilethinking
- 19. “Make it assimple to book a container as it is to buy a book through Amazon.com – Maersk Line CEO ” Source: http://epn.dk/brancher/transport/skib/article2069838.ece
- 20. Individuals and interactions Co-located teams in Copenhagen • Making progress visible • Delivering working software • Collaboration towards shared goal • Acting as Scrum Master • Various roles in Feature Teams
- 21. Working Software Beta Releaseof the new booking application
- 22.
- 24. Responding to change Takingon different roles and self organising o Adapt t ing mer Ob serv eeds Custo N Customer ack mer Feedb C usto Experience Design Developing ng Product Fac ilitati ion Roadmaps Prior itisat Business Feature Analyst Team Coach Real wn ing do Options Break nts requireme Scrum Product Master Owner ng M anagi Managing ies dependenc change
- 25. Learning from arevolutionary approach Don’t attempt Tacit to scale until knowledge of you’re ready agile Manage Stakeholder Expectations Dependencies Defer are really architectural painful decisions
- 26. 600 Cycle time analysis From Lightbulb (idea) to Live (in production) 500 # Requirements 400 Median = 150 days 300 GCSS 200 During 2010 Med = 373 days 100 0 Days Source: Focal Point (requirements that have been put into production over the last 2yrs: 2008-Oct 2010)
- 27. Existing Project, Platform, Team Evolutionary Lean Product Development
- 28. Our vision Faster delivery of value (<90 days lead time) More Faster Better Value Flow Quality Supported by an agile mindset Customer doesn’t really The developer doesn’t Things know what they want really know how to build it change
- 29. Mature IT Practiceswe weren’t leveraging Lean Product Enterprise Development Practices Agile Project Practices SCRUM Team Practices XP* Engineering Practices * Extreme Programming
- 30. Selected LPD practicesfor Maersk Line First steps in improving the whole... Contains 8 practices selected for Maersk Line: 1. Get to initial prioritisation faster 2. Improve prioritisation 3. Pull Requirements from Dynamic Priority List 4. Reduce size of requirements 5. Get to the point of writing code quickly 6. Actively manage Work-In-Progress (WIP) 7. Enable Faster Feedback 8. Enable smooth, sustainable flow
- 31. Problem: Demand isunlimited Consumerisation I.T. high expectations… Most change is enabled by I.T. so they need more
- 32. HiPPO: Highest PaidPerson’s Opinion
- 33.
- 34. Improve Prioritisation Using CD3:Cost of Delay Divided by Duration How value Benefits decays over time Information $ discovery value Cost of Delay Prioritise features by Duration
- 35. Benefits of usingCost of Delay • ‘less yelling and screaming’ data-driven, more visible • Enables better trade-off decisions and increased ROI • Handles dependencies between teams • Changes the conversation… Delivering “on time” Delivering value quickly Cutting I.T. costs
- 36. Value! Cost Scope Schedule
- 37. Try this athome… Ask each person on one of your project teams: What would you estimate the Cost of Delay for this project to be?
- 38. Selected practices forMaersk Line First steps in improving the whole... Contains 8 practices selected for Maersk Line: 1. Get to initial prioritisation faster 2. Improve prioritisation 3. Pull Requirements from Dynamic Priority List 4. Reduce size of requirements 5. Get to the point of writing code quickly 6. Actively manage Work-In-Progress (WIP) 7. Enable Faster Feedback 8. Enable smooth, sustainable flow
- 39. Feast and Famine The effect of creating large release batches upstream S Des Dev T Requirements R25 S Des Dev T R24 S Des Dev T R23 S Des Dev T R22 Jan Apr Jul Oct Jan 2011 2012 Development Perspective: Dev Dev Dev Dev Vendor team had ~10,000 hours of idle time in 2010
- 40. Next train: 13weeks ?
- 41. Next train 7wks
- 42. Pull System From DynamicPriority List Dynamic Triage Priority Refine Realise Release List
- 43. Fund the capacityto deliver change Make small adjustments over time Throughput Learning curve (18 months?) Go! Stop Time Mobilise (3mo?)
- 45. 3 potential models: A. Time-based: Fund a given team size for a period of time B. Buffering: Fund small batches of requirements in advance C. Just-in-Time: Fund individual requirements on demand
- 46. Smooth, sustainable flow Reducebatching of requirements upstream : Ac tion ching at ge b Requirements C han S Des Dev T Releases
- 47. Cost Flexible Pull scope! System! Scope Schedule
- 48. Predicting scope basedon probability DPL Refine Q: Realise Produ Q: Dev ction Priority Clarify WHW Check Dev Demo Tests RQ-XXX RQ-XXX RQ-XXX RQ-XXX RQ- RQ-XXX RQ-XXX RQ-XXX XXX RQ-XXX RQ- RQ-XXX RQ-XXX XXX RQ-XXX RQ-XXX Rn 23/06 27/06 04/07 05/07 07/07 14/07 18/07 08/08 14/08 Rn+1 14/07 18/07 02/08 03/08 05/08 12/07 15/08 05/09 11/09 ➙ Use cycle-time analysis to compute length of each step then compute backwards the dates from the fixed release dates.
- 49. Try this athome… Consider what impact your funding and approval process has downstream: What would be the optimum batch size for smoothing the flow of work?
- 50. Cost Value Schedule Speed Scope Feedback
- 51. Key Performance Measuresfor IT Variable Typical measures Usual outcomes Lean-‐Agile alternaBves Time Delivering on a Incen-vises hidden -me Maximise speed in ge>ng to predicted date buffers and slower the point where value starts delivery to be realised Scope Delivering all of the Incen-vises gold pla-ng Minimize size of work originally predicted and discourages packages to maximize both scope exploita-on of learning. learning and early release of value Cost Delivering at or Incen-vises hidden cost Maximize value delivered below a predicted con-ngencies, pushing (trade development cost development cost costs up. against the opportunity cost of delay) Quality Delivering changes Resistance to making any Shorten feedback cycles at with zero down-me changes. Overinvestment many levels (coding, defects…) and no errors in tes-ng & documenta-on.
- 52. Try this athome… What are your key success measures? What is the impact of your success measures on value, speed and quality?
- 53. Selected practices forMaersk Line First steps in improving the whole... Contains 8 practices selected for Maersk Line: 1. Get to initial prioritisation faster 2. Improve prioritisation 3. Pull Requirements from Dynamic Priority List 4. Reduce size of requirements 5. Get to the point of writing code quickly 6. Actively manage Work-In-Progress (WIP) 7. Enable Faster Feedback 8. Enable smooth, sustainable flow
- 54. Faster Delivery How dowe know the changes are an improvement? 208 days GCSS 104 days Half FACT SAP 168 days the 60 days time All 150 Apps Target 90
- 55. Better Quality How dowe know the changes are an improvement? 11.2 8.2 88% 80% 85% 2.2 2 1 0.3 Defects Delays Patches
- 56. More Value How dowe know the changes are an improvement? $44.80 $26.30 $4.10 MLIT Average GCSS FACT (Before) (After) Benefits per dollar invested
- 57. And… delivering Cheaper Notwhat we were aiming for, but reducing waste has led to… 9% 22% $82.8 7.3 $75.6 6 Cost per hour Throughput
- 58. People love it! “Fewer defects in a release to handle” “Daily calls provide good visibility “Smaller and clear of changes” changes delivered faster” “Less yelling & screaming” “We have not had such a smooth launch since Release 16 – I thought my phone had stopped working” “Absolutely worth it”
- 59. highly fit for knowingly unknowingly func-onal purpose broken broken chaos Exis6ng Process highly severely func-onal func-onal ok dysfunc-onal dysfunc-onal Team dynamics excellent fair fit for purpose poor miserable Product Quality highly severely func-onal func-onal ok dysfunc-onal dysfunc-onal PO relaBon highly severely func-onal func-onal ok dysfunc-onal dysfunc-onal Vendor relaBon outstanding support suppor-ve neutral non-‐suppor-ve opposed Mgmt buy-‐in excellent fair ok poor miserable IT understanding <10 10 20 50 >100 Dev team size same same floor building same city same con-nent overseas Proximity to us <10 kUSD 10 kUSD 100 kUSD 1 MUSD >10 MUSD Budget
- 60. The Oracle The oracle predicts: Drawn out and MASSIVE Failure
- 61.
- 62. Address systemic issues To Do In Progress Mobilise new Reduce ”big projects design up Address faster front” Decouple organisational complexity funding and Fix availability Break work approval & quality of down Fix environments engineering Embed lean- practices agile mindset
- 63. Our vision Faster delivery of value (<90 days lead time) More Faster Better Value Flow Quality Supported by an agile mindset Customer doesn’t really The developer doesn’t Things know what they want really know how to build it change
- 64. Making it stick! Org chart Processes Roles Formal system Tools Informal system Behaviours Customs “Culture” Language Values Traditions Beliefs Stereotypes Taboos
- 66.
- 67. “ Anyone who has never made a mistake …has never tried anything new ” Albert Einstein
- 68.