19. “Make it as simple 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
22.
Customer
Collabora-on
Focus
on
Customer
and
Innova-on
23.
24. Responding to change
Taking on 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 a revolutionary 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 Practices we weren’t leveraging
Lean Product
Enterprise
Development
Practices
Agile
Project
Practices
SCRUM
Team
Practices
XP*
Engineering
Practices
* Extreme Programming
30. Selected LPD 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. Problem: Demand is unlimited
Consumerisation I.T.
high expectations…
Most change is enabled by I.T.
so they need more
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 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…
Delivering
“on time”
Delivering
value quickly
Cutting
I.T. costs
37. 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?
38. Selected 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
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
43. Fund the capacity to deliver change
Make small adjustments over time
Throughput
Learning curve
(18 months?)
Go!
Stop Time
Mobilise
(3mo?)
44.
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
Reduce batching of requirements upstream
:
Ac tion ching
at
ge b
Requirements
C han
S Des Dev T
Releases
48. Predicting scope based on 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 at home…
Consider what impact your funding and approval
process has downstream:
What would be the
optimum batch size for
smoothing the flow of
work?
51. Key Performance Measures for 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 at home…
What are your key success measures?
What is the impact of
your success measures
on value, speed and
quality?
53. Selected 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
54. Faster Delivery
How do we 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 do we 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 do we 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
Not what 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
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
