Improving Agility (Learning from Maersk Line's Journey) | Özlem Yüce | Agile Greece Summit 2016

Özlem Yüce [email protected]

@OzzieYuce

Improving Agility (Learning from Maersk Line’s journey)

Together > Σ(parts)

World’s largest container fleet

Turnover: $27 billion

Bookings/day: 23,000

Bookings/day: 23,000 Turnover: $27 billion

Truly global business

Containers in circulation: 2.2 million

Fragmented Technology Landscape USI WebSimon P&O Nedloyd career.

maersk.com eProfile (SCV) iReceivables (MLIS)

World map

VMLO (CAF)

ATS2

eXport booking

eXport documen-

tation

SFX (document

pouch)

SCV

RKST

GSMS

MARS

SAF marine eRates

Message broker

MEPC

NGP3 GEO

NGP3 office

NGP3 mall

SAF marine portal RKEM GEO

mainframe MCS GCSS IBM payment systems MEX (MLIS)

SAF sailing schedules

einfo Maersk.com Mondo-search LivePerson Emergency pages

Reference-Data MARS service

Rates

Schedules

GUPS

Followup shipments

CCC

ePayment

Payment system service

eDB

Phone book 3

Tracking 3 sROE

Portal

Office WS client/portal

service

MailService

MEPC W8

Outsourced Development

Design Test Develop

Analyse

(2007)

Department

(2007)

Department

Department

Department

Source: http://epn.dk/brancher/transport/skib/article2069838.ece

Make it as simple to book a container

as it is to buy a book through Amazon.com

– Maersk Line CEO ”

“

Introduction to Agile thinking

• Making progress visible • Delivering working software • Collaboration towards shared goal • Acting as Scrum Master • Various roles in Feature Teams

Individuals and interactions Co-located teams in Copenhagen

First booking : Together with customer in Poland

Release early, release o;en

Working Software Beta Release of the new booking application

Customer Collaboration Focus on Customer and Innovation

Responding to change Taking on different roles and self organising

Breaking down

requirements

Developing Product

Roadmaps Facilitating

Prioritisation

Customer Experience

Design

Scrum Master

Feature Team Coach

Observing

Customer Needs

Real Options

Adapt to

Customer

Feedback

Managing

dependencies Managing change

Business Analyst

Product Owner

Lessons from the revolutionary approach

Manage stakeholder expectations

Don’t attempt to scale until you’re ready

Defer architectural

decisions

Legacy dependencies

are painful

Only tacit knowledge of

‘agile’...

0 10

0 20

0 30

0 40

0 50

0 60

0

30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 More

# R

equi

rem

ents

Days

Cycle time analysis From Lightbulb (idea) to Live (in production)

Median = 150 days

During 2010 Med = 373 days

GCSS

From Revolution to Evolution...

New Project, Platform, Team

Revolutionary

Existing Setup, Platform, Team

Evolutionary

Lean Product Development

The vision

More Value

Faster Flow

Better Quality

Supported by an agile mindset: Customer doesn’t really know what they want

The developer doesn’t really know how to build it

Things change!

Faster delivery of value (<90 days lead time)

+ +

Mature practices they weren’t leveraging

Lean Product Development

Agile

SCRUM

Enterprise Practices

Team Practices

Project Practices

XP

Engineering Practices

Selected Lean Enterprise practices for 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

<1 week

Dynamic Priority

List

Prioritise new ideas quickly

Triage Refine Realise Release

Prioritise by knowing the

Cost of Delay

Manage capacity with a pull system

Increase quality with

fast feedback

Get the point of writing

code quickly

Break down the work

Limit the Work in Progress

Reduce batching to smooth flow

Scope: Lightbulb... to Live

The end-to-end innovation process

0 10

0 20

0 30

0 40

0 50

0 60

0

30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 More

# R

equi

rem

ents

Days

Cycle time analysis From Lightbulb (idea) to Live (in production)

Median = 150 days

During 2010 Med = 373 days

GCSS

State # RQ Idea! 729 New 897 Being Drafted 416 Ready for Review 422 Ready for Guesstimation 181 Ready for Prioritization Analysis 2980 335

Ready for Estimation 68 Ready for Authorization 219 Authorized Estimation 502 215

Development Initiated 242 Development Complete Development 326 84

Testing (total of all states) Testing 395 395

On Hold Waiting 471 471

Fuzzy Front End

* Requirements work-in-progress (October 2010)

Go Live! Dev & Test

(82 hrs) Captured PoC

(24 hrs)

18 weeks waiting 9 weeks waiting 11 weeks waiting

Wait waste = 38 weeks

Fuzzy Front End

Focus the upstream process 1. Get to initial prioritisation faster 5. Get to point of writing code quickly

<1 week <2 weeks Triage Dynamic

Priority List Max 5

Refine Pull to coding…

Dev Buffer

Expect >10% attrition otherwise upstream process is too heavy

Don’t waste time

doing too much

analysis too early! Don’t waste time on low-value ideas

Quickly identify the ideas that will be the

most profitable

Problem: Demand is unlimited

Consumerisation of I.T. high expectations…

Most change is now enabled by I.T. so they need more

HiPPO: Highest Paid Person’s Opinion

2. Improve Prioritisation

Benefits $

Cost of Delay

Duration

Prioritise features by

How value decays over time Information

discovery value

2. Improve Prioritisation Using CD3: Cost of Delay Divided by Duration

Benefits of using Cost 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…

Cutting I.T. costs

Delivering value quickly

Delivering “on time”

Data driven decision-making

Makes urgency

visible

Handles multiple

delivery streams

Maximises ROI

Cost

Scope Schedule

Value!

Try this at home...

Ask each person on one of your project teams:

What would you estimate the

Cost of Delay for this project to be?

System A: Value by quartile

$230,000/wk $220/wk

Bottom 25%

Top 25% of RQs

$18,600/wk

Next 25%

$5,200/wk

Next 25%

Average $ Benefits Per Requirement

$0

$200,000

$400,000

$600,000

$800,000

$1,000,000

$1,200,000

$1,400,000

$1,600,000

$1,800,000

$2,000,000

$2,200,000

$2,400,000

$2,600,000

$2,800,000

0 10 20 30 40 50 60 70 80

Requirements sorted by Cost of Delay

Cos

t of

Del

ay /

wee

k

Focal Point Feb 28 2012.

A small number of features have a very high Cost

of Delay

System A: Value distribution

System B: Value distribution

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

0 10 20 30 40 50 60

Cos

t of D

elay

(U

S$ p

er w

eek)

80:20 Pareto Principle “the vital few”

Requirements sorted by Cost of Delay

Cos

t of

Del

ay /

wee

k

<1 week

Dynamic Priority

List




Cost of Delay

Manage capacity with a

pull system


fast feedback

Get the point of writing code

quickly

Break down the work




Before: Feast and Famine The effect of creating large release batches upstream

Requ

irem

ents

S Des Dev T

Apr

S Des Dev T

S Des Dev T

S Des Dev T

R22

R23

R24

R25

Jul Jan 2011

Oct Jan 2012

Dev Dev Dev Dev

…Vendor team had ~10,000 hours of idle time in 2010

Development Perspective:

Time

13 wks

Next train: in 13 weeks

Next train 7 wks

<1 week

Dynamic Priority

List




Cost of Delay

Manage capacity with a pull system


fast feedback


quickly

Break down the work



The end-to-end innovation process

Pull System From Dynamic Priority List

Fund the capacity to deliver change ...and make small adjustments over time

Time

Thro

ughp

ut

Mobilise (3 months?)

Learning curve (9 months?)

Stop!

Go!

Required flexible funding 3 potential models

Fund a given team size for a period of time

Fund small batches of requirements in advance

Fund individual requirements on demand

Time–based

Buffering

Just-in-Time

T Dev Des S

After: Smooth, sustainable flow Reduce batching of requirements upstream

Requ

irem

ents

Releases

Action:

Change batching

Time

Cost

Scope Schedule

Pull System!

Flexible scope!

Predicting scope using data Refine

Clarify WHW Check DPL:

Priority Q: Dev Buffer

RQ-XXX

Realise Dev Demo Tests

Prod

uctio

n

18/07 14/07 07/07 05/07 27/06 23/06 04/07 14/08

15/08 12/07 05/08 03/08 18/07 14/07 02/08 11/09

RQ-XXX RQ-XXX

RQ-XXX

RQ-XXX

RQ-XXX

RQ-XXX RQ-XXX RQ-XXX RQ-XXX

RQ-XXX

RQ-XXX

RQ-XXX

RQ-XXX

Rn

Rn+1

Then, work backwards from fixed release dates to the option expiry date

Measure duration for each step.

Variable Typical measures Usual outcomes Lean-‐Agile alternaBves

Time Delivering on a predicted date

Incen;vises hidden ;me buffers and slower delivery

Maximise speed in geGng to the point where value starts to be realised

Scope Delivering all of the originally predicted scope

Incen;vises gold pla;ng and discourages exploita;on of learning.

Minimize size of work packages to maximize both learning and early release of value

Cost Delivering at or below a predicted development cost

Incen;vises hidden cost con;ngencies, pushing costs up.

Maximize value delivered (trade development cost against the opportunity cost of delay)

Quality Delivering changes with zero down;me and no errors

Resistance to making any changes. Overinvestment in tes;ng & documenta;on.

Shorten feedback cycles at many levels (coding, defects…)

Key Performance Measures for IT

Refine

<1 week

Dynamic Priority

List


Triage Realise Release


Cost of Delay


pull system


fast feedback


quickly

Break down the work



Break down the work

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 More

Requirement size variability

Guesstimate Points

Benefits split? - Break down during Triage

Max. size <2 weeks

# R

equi

rem

ents

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 More

Highly variable with some very

large requirements

Before

After

<1 week

Dynamic Priority

List




Cost of Delay


pull system


fast feedback


quickly

Break down the work



Constraining Work-in-Progress

Department Slide no. 61

Streamline impact

assessment Improve error

tracing

Daily feedback/

review

Actively Manage Work-in-Progress

WIP LIMIT of 8 (upstream of bottleneck)

190

# R

equi

rem

ents

*

46

6.0 5.2 6.1

7.9 8.8

6.4 7.1

Rel 19-22 R23 R24 R25 R26 R27 R28

Work-in-Progress. Controlled.

Oct 2010 Jan 2012

76%

…whilst at least maintaining throughput

Reduced wait waste

Improved

visibility

*”Authorized” to “Launched”

Guesstimate points/week

<1 week

Dynamic Priority

List




Cost of Delay


pull system


fast feedback


quickly

Break down the work



‘Quality’ requires feedback

Faster Feedback Eight Standard Measures

Requirement captured

Requirement validated

Started coding

Integrated & built

Completedcoding

Accepted for launch

Launched in production

Feasible Demonstrated

Accepted

Launched

Code complete

Feature complete

Require-ments

Release candidate

Code

Launchable

Faster Feedback Comparing GCSS with the X-leap on the Eight Measures

All times are in days

Action:

HOAT Forward

Action: Faster SPT

<1 week

Dynamic Priority

List




Cost of Delay


pull system


fast feedback


quickly

Break down the work



What about the outcomes?

Faster Delivery How do we know the changes are an improvement?

Half the time 60

104

168

208

FACT

GCSS

90 150

Target All

Apps

days

days

days

days SAP

For GCSS : Prioritised to Live For FACT : Idea to Live

Better Quality How do we know the changes are an improvement?

8.2

11.2

2 1

2.2

0.3

Defects Delays Patches

88% 85% 80%

More Value How do we know the changes are an improvement?

$26.30

$44.80

GCSS FACT MLIT Average (Before)

Benefits per dollar invested

$4.10

(After)

And... delivering Cheaper Not what we were aiming for, but reducing waste has led to...

$82.8

$75.6

Cost per hour

6

7.3

Throughput

22% 9%

The data is for GCSS Throughput is measured as guesstimate point/week

“Absolutely worth it”

People love it!

“Less yelling & screaming”

“Smaller and clear changes delivered faster”

“Fewer defects in a release to handle”

“Daily calls provide good visibility

of changes”

“We have not had such a smooth launch since Release 16 –

I thought my phone had stopped working”

“It (LPD) does more then just making the development cycle more cost and time effective, it also improves quality of work, enjoyment of work and teamspirit” “Things have

improved with cycle time, now I have hardly anything in my queue”

Harit Gupta, BPO

Dirk Van Mierlo, SAP Developer

Learnings from an evolutionary approach •  It’s possible to make a huge impact on cycle time

without changing engineering practices •  Every team is like a separate company •  Long lead time to get to ‘kick off’ •  It’s easier to sell when the process is knowingly broken •  Two steps forward one step backwards • Organizational uncertainty is a challenge • Huge push back for WIP limits from some •  It’s all about stakeholder management (70%) • Systemic issues block adoption…

What went well? •  Enthusiastic portfolio managers make it easier to get buy-in

from the business partners •  People with right mindset and background in the team make a

difference •  People in the field get it; Practices work well on team level •  All parts of the organisation were on our Steering Group •  Combination of Consultants+Maersk resources as Lean-Agile

coaches •  COD adoption went viral after the pilot •  Presenting an engagement plan and defining the coach’s role

upfront •  Kanban boards and Standups go viral (but..)

What could have been better?

•  Organisational changes shifted the entire stakeholder map •  We could have brought management closer to the work •  Introduce training on the principles early on to embed the

mindset •  Mandate to change the organisation and process •  Set up champions network early on

What still puzzles us? •  Success with legacy changed the perception that ‘agile works

with greenfield’ •  How to predict the value for a pipeline over the longer term •  How to approach teams that are on a likely path to failure •  How to encourage the organisation as a whole to learn •  How to get senior managers to lead the transformation •  How to change the culture of an organisation •  How to explain Cumulative Flow Diagrams to people better

Bottom of the iceberg It’s not just process…

Visible change

Hidden Culture & Mindset

Change

Finish the Roll-out Drive the Std Process

Address Systemic Issues

Additional Practices

Transformational Leadership

Mindset Change Coaching & Training

for Verticals

Transformation: ‘Be Lean-Agile’

Adoption: ‘Do Lean-Agile’

Behaviours Customs Language Values Traditions Beliefs Stereotypes Taboos

Org chart Processes Roles Tools

Final piece of advice

• Don’t give up • Avoid Agile vs. Waterfall > Outcomes • Look at the whole end to end • Make the problem visible • Start with the principles • Study your stakeholders • Appeal to hearts & minds

Drawing by Portia Tung

If you’re not moving at the speed of the marketplace you're already dead

…you just haven't stopped

breathing yet

Jack Welch CEO of General Electric 1981-2001

“ ”

Maersk Line Experience report and lots of other material

BLACK SWAN FARMING.COM

Want more?

[email protected] @OzzieYuce

Özlem Yüce