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

1.
Özlem Yüce
ozlem@agileatheart.com
@OzzieYuce
Improving Agility
(Learning from Maersk Line’s journey)

2. Together > Σ(parts)

3. World’s largest container fleet

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

5. Truly global business
Containers in circulation: 2.2 million

6. 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

7. Outsourced Development

8. Design TestDevelop
Analyse

10. (2007)

11. Department
(2007)

12. Department

14. Department

15. Department

18. 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
”
“

19. Introduction to Agile thinking

20. • 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

21. Working Software
Beta Release of the new booking application

22. Customer Collaboration
Focus on Customer and Innovation

24. 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

25. 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’...

26. 0
100
200
300
400
500
600
30
60
90
120
150
180
210
240
270
300
330
360
390
420
450
480
More
#Requirements
Days
Cycle time analysis
From Lightbulb (idea) to Live (in production)
Median = 150 days

27. From Revolution to Evolution...
New
Project, Platform, Team
Revolutionary
Existing
Setup, Platform, Team
Evolutionary
Lean
Product
Development

28. 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)
+ +

29. Mature practices they weren’t leveraging
Lean Product Development
Agile
SCRUM
Enterprise
Practices
Team
Practices
Project
Practices
XP Engineering
Practices

30. 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

31. <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

32. 0
100
200
300
400
500
600
30
60
90
120
150
180
210
240
270
300
330
360
390
420
450
480
More
#Requirements
Days
Cycle time analysis
From Lightbulb (idea) to Live (in production)
Median = 150 days
During 2010
Med = 373 days
GCSS

33. 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)

34. 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

35. 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 wastetime on low-value ideas
Quickly identify the
ideas that will be the
most profitable

36. Problem: Demand is unlimited
Consumerisation of I.T.
high expectations…
Most change is now
enabled by I.T. so they
need more

37. HiPPO: Highest Paid Person’s Opinion

38. 2. Improve Prioritisation

39. 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

40. 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”
M
H

41. Cost
Scope Schedule
Value!

42. 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?

43. 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

44. $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
CostofDelay/week
A small number
of features have
a very high Cost
of Delay
System A: Value distribution

45. System B: Value distribution
0
10000
20000
30000
40000
50000
60000
70000
80000
90000
100000
0
10
20
30
40
50
60
80:20
Pareto Principle
“the vital few”
Requirements sorted by Cost of Delay
CostofDelay/week

46. <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
Reduce batching to smooth flow

47. Before: Feast and Famine
The effect of creating large release batches upstream
Requirements
S Des Dev T
S Des Dev T
S Des Dev T
S Des Dev T
R22
R23
R24
R25
Jan
201
Dev Dev Dev Dev
…Vendor team had ~10,000 hours of idle time in 2010
Development
Perspective:
Time
13 wks

48. Next train: in 13 weeks

49. Next train 7 wks

50. <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
The end-to-end innovation process
Pull System
From Dynamic Priority List

52. Fund the capacity to deliver change
...and make small adjustments over time
Time
Throughput
Mobilise
(3 months?)
Learning curve
(9 months?)
Stop!
Go!

53. 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

54. T
Dev
Des
S
After: Smooth, sustainable flow
Reduce batching of requirements upstream
Requirements
Releases
Action:
Change batching
Time

55. Cost
Scope Schedule
Pull
System!
Flexible
scope!

56. Predicting scope using data
Refine
Clarify WHW Check
DPL:
Priority
Q: Dev
Buffer
RQ-XXX
Realise
Dev Demo Tests
Production
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.

57. 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

58. Refine
<1 week
Dynamic
Priority
List
Prioritise new
ideas quickly
Triage
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
Break down the work

59. 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 downduring Triage
Max. size
<2 weeks
#Requirements
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

60. <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
Constraining Work-in-Progress

61. DepartmentSlide no.
61
Streamline
impact
assessment
Improve error
tracing
Daily
feedback/
review
Actively Manage Work-in-Progress
WIP LIMIT of 8
(upstream of bottleneck)

62. 190
#Requirements*
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

63. <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
‘Quality’ requires feedback

64. Faster Feedback
Eight Standard Measures
Requirement
captured
Requirement
validated
Started
coding
Integrated
& built
Completed
coding
Accepted
for launch
Launched
in production
Feasible Demonstrated
Accepted
Launched
Code
complete
Feature complete
Require-
ments
Release
candidate
Code
Launchable

65. Faster Feedback
Comparing GCSS with the X-leap on the Eight Measures
All times are in days
Action:
HOAT Forward
Action:
Faster SPT

66. <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
What about the outcomes?

67. Faster Delivery
How do we know the changes are an improvement?
Half
the time60
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

68. 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%

69. 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)

70. 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

71. “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
de
eff
wo

72. 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…

73. 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..)

74. 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

75. 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

76. Bottom of the iceberg
It’s not just process…
Visible change
Hidden
Culture & Mindset
Change
on:
le’
Behaviours
Customs
Language
Values
Traditions
Beliefs
Stereotypes
Taboos
Org chart
Processes
Roles
Tools

77. 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

78. Drawing by Portia Tung

79. 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
“
”

80. Maersk Line Experience report and lots of other material
BLACK SWAN FARMING.COM
Want more?
ozlem@agileatheart.com
@OzzieYuce
Özlem Yüce