A CASE STUDY IN LARGE SCALE LEAN-AGILE ADOPTION Chris Berridge Maersk Line
About Maersk Line • Worlds largest container fleet • Truely global business • 325 offices in 125 countries • 25.000 employees (7,600 seafarers) • 14.5% world market share [1] • 570 container vesssels • Turnover $26 billion [2] [1] Source: Alphaliner Jan 2011 [2] Source: Annual Report 2011
Fragmented IT Landscape • Thin outsourcing model • Tier 1 vendors only • 2,500 applications • Core applications are tightly coupled • 23,000 bookings/day
How we started our lean-agile journey? New Existing Project, Platform, Team Project, Platform, Team Revolutionary Evolutionary Lean Product Development
X-leap: The goal Under Maersk Lines paraplystrategi - streamLINE - er der i værksat en række initiativer, der sikre at rederiet bliver endnu mere konkurrencedygtige gennem industriens bedste leveringssikkerhed, fortsatte CO2-reducerende initiativer og sidste men ikke mindst ved at sætte kunden i fokus X-Leap er Maersk Lines største og vigtigste af disse programmer. Formålet er at gøre det ligeså enkelt at booke en container hos os som en bog hos Amazon.com Maersk Line CEO (at the time) Source: http://epn.dk/brancher/transport/skib/article2069838.ece
X-leap: How we sold agile to our stakeholders Maersk is complex Two delivery approaches are common SAF 1. Waterfall 2. Prototyping career. marine iReceivab WebSimo eProfile P&O USI maersk.c sailing les n Nedloyd (SCV) om schedule (MLIS) s www. Mondo- LivePerso Emergen World einfo maersk.c search n cy pages RKST map om VMLO GSMS (CAF) MARS Referenc Portal GUPS service e-Data MARS ATS2 ≈ Rates Followup SAF shipment marine s eXport eRates booking MEPC W8 Message broker eXport eDB CCC documen -tation Schedule MEPC s Phone SFX book 3 Office WS ePaymen (docume NGP3 client/por t nt pouch) GEO tal Tracking No customer facing Lots of functionality service sROE 3 NGP3 Payment MailServi office system functionality for the early, but no ce service NGP3 mall first 18-24 months connection to backend SAF GEO IBM MEX marine RKEM mainfram MCS GCSS payment SCV (MLIS) portal e systems Our approach is fundamentally different ▪ 100’s of backend systems ▪ Convoluted and unstable application Agile SOA architecture ▪ Inconsistent master data Minimal set of customer ▪ High product complexity facing functionality – More than 20 000 lines in some contracts delivered with true backend Service bus – More than 500 commodity types connections as early as possibly (in our case 9 – 10 months)
X-leap: What we got right from the outset • Strong customer focus • Clear customer experience vision created • Co-location • Shared Key Performance Indicators for whole team • Onboard experienced people • Willingness to experiment with new approaches • Great senior leadership support
X-leap: 22 practices we (now) know that need to master • Visualised Flow and Process • Continuous Delivery • Continuous Integration • Test Driven Development • Automated Developer (Unit) Tests • Release Often • Evolutionary Design • Simple Design • Automated Acceptance (Functional) Tests • Refactoring • Collective Code Ownership • Definition of Done • End2End Iterations • Single Prioritised Backlog • Demo • Limit Work-in-Progress • Pair Programming (To Drive Standards) • Test Driven Requirements • Pair Programming (To Ease Platform • Feature Teams Constraints) • Customer (proxy) Part Of The Team • Stand Up Meetings
X-leap: A feature team in action
X-leap: Learnings within team Manage requirements • Prioritise effectively between functional & non-functional requirements • Break down requirements and agree on what size is appropriate • Need a process vision to support a customer experience vision Iteration 0 is surprisingly large • e.g. Reducing hardening phase took forever
X-leap: Value stream analysis for a feature X-leap: Root cause analysis for why hardening phase takes so long
X-leap: Learnings within team Manage the change • Engage advisors who focus on optimising the whole • Own and manage practice adoption progress Minimise thrashing • E.g. Struggle to measure velocity due to constant changes
X-leap: Learnings outside team Stakeholders need careful management • Reluctant to exchange predictability for speed • Difficult to explain refactoring & technical debt • High expectations of delivering fast Dependencies external to the development team are a headache • Feature teams help but are no silver bullet • There’s no replacement for good project management to identify and manage external dependencies • Others have to change their working practice (architects, infrastructure, other applications)
How we are completing the lean-agile journey. New Existing Project, Platform, Team Project, Platform, Team Revolutionary Evolutionary Lean Product Development
600 Cycle Time Analysis 400 Median = 150 days # Requirements GCSS Over last 24 mo Med = 280 days GCSS Over last 12 mo 200 Med = 373 days 0 Days Source: Focal Point – requirements that have been put into production over the last 2yrs, measured from date of creation to when set to working-in-production
Framing the methodologies Lean Product Enterprise Development Practices Agile Project Practices SCRUM Team Practices XP* Engineering Practices * Extreme Programming
The Starter Pack: 8 selected practices 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 more frequent releases
GCSS: Release Frequency The effect of creating large release batches upstream Requirements S Des Dev T R25 S Des Dev T R24 S Des Dev T R23 S Des Dev T R22 Apr Jul Oct Jan Jan 2011 2012 Development Dev Dev Dev Dev Perspective: Estimated ~10,000 hours of idle time in 2010
GCSS: More Frequent Releases Enable the smooth flow of requirements Requirements T S Des Dev Releases
Faster Feedback Eight Standard Measures Requirement Started Completed Launched captured coding coding in production Integrated Decided Requirement & built for launch validated Feasible Demonstrated Require- ments Accepted Code complete Code Feature complete Release Launchable candidate Launched
Faster Feedback Comparing GCSS with the X-leap on the Eight Measures All times are in days
WIP LIMIT of 8 on bottleneck GCSS: Actively Manage Work-in-Progress Department Slide no. 23
GCSS: Work-in-Progress reduced …whilst at least maintaining throughput 8,8 7,9 7,1 6,4 6,1 6,0 5,2 190 # Requirements* Rel 19- R23 R24 R25 R26 R27 R28 22 76% Guesstimate points/week 46 Oct 2010 Jan 2012 *”Authorized” to “Launched”
GCSS: Requirement size variability Before Max. size # Requirements <2 weeks After Guesstimate Points
GCSS: Standardized Upstream Process Get to initial prioritisation faster Get to point of writing code quickly Dynamic Refine Triage Pull to Dev Priority coding… Buffer List <2 weeks <1 week Max 5 Expect >10% attrition Quickly identify the otherwise upstream ideas that will be the process is too heavy most profitable
GCSS: Quality improvements Releases 2010-2011 12,0 -88% 10,0 8,0 Defects 6,0 -80% Patches Defects Delays 4,0 Delays 2,0 -85% 0,0 Average Rel18-Rel22 Average Rel23-Rel28 E1+E2 Defects raised in HOAT 8,2 1,0 Production slippage (in days) 11,2 2,2 Patches Patches 2wks after Prod 2,0 0,3 Up to June 2011 Since July 2011
GCSS: Cycle time Average time elapsed from starting work to released Refine Realise Release 0 50 100 150 200 208 Releases 11 to 22* days Rel 23 Half Rel 24 Rel 25 the Rel 26 time Rel 27 104 Days Rel 28 *No data for R18, R19
Rolling out! Jan 2012 Feb 2011 May 2011 Sept 2011 Aug 2012 GCSS Pilot Hermes Rollout Starter Pack to all delivery streams SOA SAP Masterdata London EDI Systemic issues
Department Slide no. 30
Recommend
More recommend
