• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Journey To Systemic Improvement
 

Journey To Systemic Improvement

on

  • 1,069 views

David Joyce - Presentation To AgileYorkshire

David Joyce - Presentation To AgileYorkshire

Statistics

Views

Total Views
1,069
Views on SlideShare
1,069
Embed Views
0

Actions

Likes
1
Downloads
37
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Journey To Systemic Improvement Journey To Systemic Improvement Presentation Transcript

    • A Journey to Systemic Improvement David Joyce BBC Worldwide 1
    • Kanban Kanban is a transparent, work-limited, value pulling system. Eric Willeke - Kanbandev Yahoo! group 2
    • Start with what you do now. Modify it slightly to implement pull Use a transparent method for viewing work, and organising the team Limit WIP and pull work when the team has capacity. Evolve from there by recognising Stop Starting - Start Finishing! bottlenecks, waste and variability that affect performance David Anderson 3
    • Kanban began in one product team in mid 2008 Continually evolving... 4
    • Kanban began in one product team in mid 2008 Continually evolving... 4
    • Kanban began Dev limits in one product team in mid 2008 Continually evolving... 4
    • Kanban began in one product team in mid 2008 Handoff Continually evolving... 4
    • Kanban began in one product team in mid 2008 Continually evolving... 5
    • Kanban began Engineering Done one product in team in mid 2008 Continually evolving... 5
    • Kanban began in one product team in mid 2008 Batched Releases Continually evolving... 5
    • Kanban began MMFs in one product team in mid 2008 Continually evolving... 5
    • Kanban began in one product team in mid 2008 Ideation Board Continually evolving... 5
    • Kanban began in one product team in mid 2008 Goals & Objectives Continually evolving... 5
    • Kanban began in one product team in mid 2008 Express Lane Continually evolving... 5
    • Kanban began in one product team in mid 2008 Hidden Work Continually evolving... 5
    • Kanban began in one product team in mid 2008 Dependencies Continually evolving... 5
    • Kanban began in one product team in mid 2008 Systest Constraint Continually evolving... 5
    • The Kanban “flu” soon spreads to other teams Application Support 6
    • The Kanban “flu” soon spreads to Classes of service other teams Application Support 6
    • The Kanban “flu” soon spreads to Estimation other teams Application Support 6
    • The Kanban “flu” soon spreads to other teams Application Support T-Shirt Sizing 6
    • Standard Work The Kanban “flu” soon spreads to other teams Application Support 6
    • The Kanban “flu” soon spreads to other teams Application Support Order point 6
    • The Kanban “flu” soon spreads to other teams Large Standup Application Support 6
    • The Kanban “flu” soon spreads to other teams Application Support Pro duct Teams 7
    • The Kanban “flu” soon spreads to other teams 2nd Product Team Application Support Pro duct Teams 7
    • The Kanban “flu” soon spreads to other teams Application Support MMF Breakdown Pro duct Teams 7
    • The Kanban “flu” soon spreads to other teams Application Support Pro duct Teams MMF Queue 7
    • The Kanban “flu” soon spreads to other teams Application Support Pro duct Teams Reduced Board Size 7
    • The Kanban “flu” soon spreads to other teams Application Support Pro duct Teams Design Team 8
    • The Kanban “flu” soon spreads to other teams Application Support Pro duct Teams Design Team Design Board 1 8
    • The Kanban “flu” soon spreads to other teams Application Support Pro duct Teams Design Team Design Board 2 8
    • The Kanban “flu” soon spreads to other teams Application Support Pro duct Teams Design Team Design Board 3 8
    • The Kanban “flu” soon spreads to other teams Application Support Pro duct Teams Design Team CO TS Team 9
    • The Kanban “flu” soon spreads to other teams Application Support Pro duct Teams Design Team CO TS Team COTS Main Board 9
    • The Kanban “flu” soon spreads to other teams Application Support Pro duct Teams Design Team CO TS Team 3rd Party Board 9
    • Now entering new territory Had looked at Agile before small team sizes didn’t fit specialisation constant mix of new development & support irregular release cadence 10
    • Now entering new territory Excel Board Had looked at Agile before small team sizes didn’t fit specialisation constant mix of new development & support irregular release cadence 10
    • Now entering new territory First Board Had looked at Agile before small team sizes didn’t fit specialisation constant mix of new development & support irregular release cadence 10
    • 11
    • Programme Board WIP Board 11
    • Blockers Future Media & Technology! 11
    • Kaizen Board Future Media & Technology! 11
    • Winter Olympics Board Future Media & Technology! 11
    • No Single Solution Recipe for success Focus on Quality Based on a set of Reduce WIP, Deliver principles Often Better practice NOT Balance Demand against best practice Throughput Prioritise Coupled with sound Reduce variability engineering practices and a team willing to Let the data tel l yo u, reflect, adapt and what to do w ith the data improve Control Statistical David Anderson 12
    • Mean reduced from 22 to 14 days (33%) Lead Time 50% drop in the spread in variation. Each of the outliers were proved to be special cause. Data split at financial year end and in July 13
    • Mean reduced from 9 to 3 days (67%) 77% drop in the spread in variation. Development Time The major reduction factor has been to limit work in process. Data split at financial year end and in July 14
    • Reduction in lead and cycle times, and increase in throughput are not at the expense of quality. # Live Defects Number of live bugs is within statistical control, and seeing a reduction since July. Data split at end and in July 15
    • Mean reduced from 25 to 5 days (81%) Large drop in the spread in variation. # Days Blocked The outliers was proved to be special cause, waiting for a 3rd party. # blockers actually increased. Data split at financial year end and in July 16
    • Scrum to Kanban Data split at end and in July Mean reduced from 10 to 4 days (60%) Engineering Time 64% drop in the spread in variation. 17
    • Systems Thinking The means to obtain knowledge, and act with prediction and confidence of improvement. John Seddon - Freedom from Command & Control 18
    • Kanban encourages a whole Are we just building “system” view rather than a he wrong th ing righter? t locally optimised IT view Often IT develop solutions based on sub optimised status quo are Softw t Projec Projects often focus on the needs of a single business unit If we build an IT system around a wasteful process, then we are locking in that process for longer David Anderson & Dr. Peter Middleton 19
    • Sales Marketing Finance HR Upper Management IT 20
    • Sales Marketing Finance HR Upper Management IT 20
    • Upper Management Marketing Finance Sales HR IT Hidden costs 20
    • Upper Management .T. S I ED Marketing N E Finance Sales HR IT Hidden costs 20
    • Upper Management Flow Marketing Outside Finance Sales HR IT in Hidden costs 20
    • There is little merit in a well Since IT “can” executed project that no one sho uld it? wants the output from. Focus on customer needs, and the organisation as a system Many of the previous problems, that apparently required software projects, may well have been ‘dissolved’ The improvement effort can be targeted to where it has most benefit. Dr. Peter Middleton 21
    • The thing that makes technology work is not the technology Does this mean the end of IT? There is a better way to approach the use of IT. Understand and improve, then ask if IT can further improve. Larger gains can be achieved through better thinking around the design and management of work. Then pulling IT into the work as needed. Tripp Babbitt 22
    • Un derstan d Purpose - look outside in Learn about nature of demands (in customer terms) response to demand causes of failure demand capability and predictability flow - end to end 23
    • Impro ve Improve performance without using IT If the current work uses IT then leave it in place, work with it, or treat it as a constraint Don’t do anything to change the IT Value demand Clean flow Design System Set work clean aro un d these Failure demand Act on the system Eliminate Causes conditions impeding flow John Seddon 24
    • Can IT further impro ve this process or system? Now we can see potential benefits, from a position of knowledge, about the work. We can therefore predict the The result is always less investment in IT, and much more benefits IT solutions will bring value from it IT is pulled into the work, rather than dictating the way work works John Seddon 25
    • Measure improvement results Use o perationa l perfor mance d ata Split data after a change 26
    • A better m etho d for IT System Un de rstan d Me asure Pull IT Improve the work 27
    • A better m etho d for IT System Un de rstan d Me asure Pull IT Improve the work 27
    • To be continued... Toyota say they still have 70% waste in their system 28
    • More information on Kanban My blog http://leanandkanban.wordpress.com/ Kanban community site http://www.limitedwipsociety.org Kanban for Software Engineering http://bit.ly/hz9Ju Soon to be published academic paper on BBCW and Kanban case study More information on Systems Thinking Understanding variety of demand http://bit.ly/tnnmI Freedom from Command and Control http://bit.ly/1OUCnS Economies of Flow http://bit.ly/tGw3U 29
    • Any Questions ? I must understand the system, improve the work, THEN pull IT I must understand the system, improve the work, THEN pull IT I must understand the system, improve the work, THEN pull IT I must understand the system, improve the work, THEN pull IT I must understand the system, improve the work, THEN pull IT 30