Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
 	
  
Özlem Yüce
ozlem@agileatheart.com
@OzzieYuce
Improving Agility	
  
(Learning from Maersk Line’s journey)
Together > Σ(parts)
World’s largest container fleet
Turnover: $27 billion
Bookings/day: 23,000
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
V...
Outsourced Development
Design TestDevelop
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 b...
Introduction to Agile thinking
• Making progress visible
• Delivering working software
• Collaboration towards shared goal
• Acting as Scrum Master
• Var...
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
...
Lessons from the revolutionary approach
Manage
stakeholder
expectations
Don’t attempt
to scale until
you’re ready
Defer
ar...
0
100
200
300
400
500
600
30 
 60 
 90 
 120 
150 
180 
210 
240 
270 
300 
330 
360 
390 
420 
450 
480 
More
#Requiremen...
From Revolution to Evolution...
New
Project, Platform, Team

Revolutionary
Existing
Setup, Platform, Team

Evolutionary
Le...
The vision
More
Value
Faster
Flow
Better
Quality
Supported by an agile mindset:
Customer doesn’t really
know what they wan...
Mature practices they weren’t leveraging
Lean Product Development
Agile
SCRUM
Enterprise
Practices
Team
Practices
Project
...
Selected Lean Enterprise practices for Maersk Line
First steps in improving the whole...



Contains 8 practices selected ...
<1 week
Dynamic
Priority
List
Prioritise new
ideas quickly
Triage
 Refine
 Realise
 Release
Prioritise by
knowing the
Cost ...
0
100
200
300
400
500
600
30 
 60 
 90 
 120 
150 
180 
210 
240 
270 
300 
330 
360 
390 
420 
450 
480 
More
#Requiremen...
State # RQ
Idea! 729
New 897
Being Drafted 416
Ready for Review 422
Ready for Guesstimation 181
Ready for Prioritization A...
Go Live!
Dev & Test

(82 hrs)
Captured
PoC
(24 hrs)
18 weeks waiting
 9 weeks waiting
 
 11 weeks waiting
Wait waste = 38 ...
Focus the upstream process
1. Get to initial prioritisation faster 5. Get to point of writing code quickly
<1 week
 <2 wee...
Problem: Demand is unlimited
Consumerisation of I.T.
high expectations…
Most change is now
enabled by I.T. so they
need mo...
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...
Benefits of using Cost of Delay
•  ‘Less yelling and screaming’ data-driven, more visible
•  Enables better trade-off decis...
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 pr...
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 $...
 $0	
  	
  
	
  $200,000	
  	
  
	
  $400,000	
  	
  
	
  $600,000	
  	
  
	
  $800,000	
  	
  
	
  $1,000,000	
  	
  
	
 ...
System B: Value distribution
0
10000
20000
30000
40000
50000
60000
70000
80000
90000
100000
0
 10
 20
 30
 40
 50
 60
80:2...
<1 week
Dynamic
Priority
List
Prioritise new
ideas quickly
Triage
 Refine
 Realise
 Release
Prioritise by
knowing the
Cost ...
Before: Feast and Famine
The effect of creating large release batches upstream
Requirements
S Des Dev T
S Des Dev T
S Des ...
Next train: in 13 weeks
Next train 7 wks
<1 week
Dynamic
Priority
List
Prioritise new
ideas quickly
Triage
 Refine
 Realise
 Release
Prioritise by
knowing the
Cost ...
Fund the capacity to deliver change
...and make small adjustments over time
Time
Throughput
Mobilise
(3 months?)
Learning ...
Required flexible funding
3 potential models

Fund a given team size for a period of time

Fund small batches of requireme...
T
Dev
Des
S
After: Smooth, sustainable flow
Reduce batching of requirements upstream
Requirements
Releases
Action:
Change ...
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
Production
...
Variable	
   Typical	
  measures	
   Usual	
  outcomes	
   Lean-­‐Agile	
  alternaBves	
  
Time	
   Delivering	
  on	
  a	...
Refine
<1 week
Dynamic
Priority
List
Prioritise new
ideas quickly
Triage
 Realise
 Release
Prioritise by
knowing the
Cost o...
1	
   2	
   3	
   4	
   5	
   6	
   7	
   8	
   9	
   10	
   11	
   12	
   13	
   14	
   15	
   16	
   17	
   18	
   19	
 ...
<1 week
Dynamic
Priority
List
Prioritise new
ideas quickly
Triage
 Refine
 Realise
 Release
Prioritise by
knowing the
Cost ...
DepartmentSlide no.
61
Streamline
impact
assessment
Improve error
tracing
Daily
feedback/
review
Actively Manage Work-in-P...
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. Contro...
<1 week
Dynamic
Priority
List
Prioritise new
ideas quickly
Triage
 Refine
 Realise
 Release
Prioritise by
knowing the
Cost ...
Faster Feedback
Eight Standard Measures
Requirement
captured
Requirement
validated
Started
coding
Integrated
& built
Compl...
Faster Feedback
Comparing GCSS with the X-leap on the Eight Measures
All times are in days
Action: 
HOAT Forward
Action: 
...
<1 week
Dynamic
Priority
List
Prioritise new
ideas quickly
Triage
 Refine
 Realise
 Release
Prioritise by
knowing the
Cost ...
Faster Delivery
How do we know the changes are an improvement?
Half
the time60
104
168
208
FACT
GCSS
90
150
Target
All
App...
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 doll...
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
Th...
“Absolutely
worth it” 
People love it!
“Less yelling
& screaming” 
“Smaller and clear changes
delivered faster”
“Fewer def...
Learnings from an evolutionary approach
•  It’s possible to make a huge impact on cycle time
without changing engineering ...
What went well?
•  Enthusiastic portfolio managers make it easier to get buy-in
from the business partners
•  People with ...
What could have been better?
•  Organisational changes shifted the entire stakeholder map
•  We could have brought managem...
What still puzzles us?
•  Success with legacy changed the perception that ‘agile works
with greenfield’
•  How to predict t...
Bottom of the iceberg
It’s not just process…
Visible change
Hidden
Culture & Mindset
Change
on:
le’
Behaviours
Customs
Lan...
Final piece of advice
• Don’t give up
• Avoid Agile vs. Waterfall > Outcomes
• Look at the whole end to end
• Make the pro...
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 Welc...
Maersk Line Experience report and lots of other material
BLACK SWAN FARMING.COM
Want more?
ozlem@agileatheart.com
@OzzieYu...
Improving Agility (Learning from Maersk Line's Journey) | Özlem Yüce | Agile Greece Summit 2016
Improving Agility (Learning from Maersk Line's Journey) | Özlem Yüce | Agile Greece Summit 2016
Improving Agility (Learning from Maersk Line's Journey) | Özlem Yüce | Agile Greece Summit 2016
Improving Agility (Learning from Maersk Line's Journey) | Özlem Yüce | Agile Greece Summit 2016
Improving Agility (Learning from Maersk Line's Journey) | Özlem Yüce | Agile Greece Summit 2016
Improving Agility (Learning from Maersk Line's Journey) | Özlem Yüce | Agile Greece Summit 2016
Upcoming SlideShare
Loading in …5
×

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

1,582 views

Published on

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

Published in: Business
  • Be the first to comment

  • Be the first to like this

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

  1. 1.     Özlem Yüce ozlem@agileatheart.com @OzzieYuce Improving Agility   (Learning from Maersk Line’s journey)
  2. 2. Together > Σ(parts)
  3. 3. World’s largest container fleet
  4. 4. Turnover: $27 billion Bookings/day: 23,000
  5. 5. Truly global business Containers in circulation: 2.2 million
  6. 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. 7. Outsourced Development
  8. 8. Design TestDevelop Analyse
  9. 9. (2007)
  10. 10. Department (2007)
  11. 11. Department
  12. 12. Department
  13. 13. Department
  14. 14. 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 ” “
  15. 15. Introduction to Agile thinking
  16. 16. • 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
  17. 17. Working Software Beta Release of the new booking application
  18. 18. Customer Collaboration Focus on Customer and Innovation
  19. 19. 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
  20. 20. 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’...
  21. 21. 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
  22. 22. From Revolution to Evolution... New Project, Platform, Team Revolutionary Existing Setup, Platform, Team Evolutionary Lean  Product  Development  
  23. 23. 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) + +
  24. 24. Mature practices they weren’t leveraging Lean Product Development Agile SCRUM Enterprise Practices Team Practices Project Practices XP Engineering Practices
  25. 25. 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
  26. 26. <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
  27. 27. 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
  28. 28. 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)
  29. 29. 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
  30. 30. 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
  31. 31. Problem: Demand is unlimited Consumerisation of I.T. high expectations… Most change is now enabled by I.T. so they need more
  32. 32. HiPPO: Highest Paid Person’s Opinion
  33. 33. 2. Improve Prioritisation
  34. 34. 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
  35. 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… Cutting I.T. costs Delivering value quickly Delivering “on time” M H
  36. 36. Cost Scope Schedule Value!
  37. 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. 38. 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
  39. 39.  $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
  40. 40. 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
  41. 41. <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
  42. 42. 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
  43. 43. Next train: in 13 weeks
  44. 44. Next train 7 wks
  45. 45. <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
  46. 46. Fund the capacity to deliver change ...and make small adjustments over time Time Throughput Mobilise (3 months?) Learning curve (9 months?) Stop! Go!
  47. 47. 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
  48. 48. T Dev Des S After: Smooth, sustainable flow Reduce batching of requirements upstream Requirements Releases Action: Change batching Time
  49. 49. Cost Scope Schedule Pull System! Flexible scope!
  50. 50. 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.
  51. 51. 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
  52. 52. 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
  53. 53. 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
  54. 54. <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
  55. 55. DepartmentSlide no. 61 Streamline impact assessment Improve error tracing Daily feedback/ review Actively Manage Work-in-Progress WIP LIMIT of 8 (upstream of bottleneck)
  56. 56. 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
  57. 57. <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
  58. 58. 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
  59. 59. Faster Feedback Comparing GCSS with the X-leap on the Eight Measures All times are in days Action: HOAT Forward Action: Faster SPT
  60. 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 What about the outcomes?
  61. 61. 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
  62. 62. 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%
  63. 63. 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)
  64. 64. 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
  65. 65. “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
  66. 66. 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…
  67. 67. 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..)
  68. 68. 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
  69. 69. 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
  70. 70. 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
  71. 71. 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
  72. 72. Drawing by Portia Tung
  73. 73. 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 “ ”
  74. 74. Maersk Line Experience report and lots of other material BLACK SWAN FARMING.COM Want more? ozlem@agileatheart.com @OzzieYuce Özlem Yüce

×