Kanban Overview And Experience Report Export
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Kanban Overview And Experience Report Export

on

  • 6,656 views

David Joyce of the BBC presents a Kanban experience report at Valtech's Agile Edge March 2010.

David Joyce of the BBC presents a Kanban experience report at Valtech's Agile Edge March 2010.

Statistics

Views

Total Views
6,656
Views on SlideShare
6,626
Embed Views
30

Actions

Likes
22
Downloads
427
Comments
0

3 Embeds 30

http://www.slideshare.net 26
http://blog.valtech.co.uk 3
http://a0.twimg.com 1

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

Kanban Overview And Experience Report Export Presentation Transcript

  • 1. Kanban Overview and Experience Report David Joyce BBC Worldwide 1
  • 2. Kanban Overview Kanban is a transparent, work-limited, value pulling system. Eric Willeke - Kanbandev Yahoo! group 2
  • 3. 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 bottlenecks, waste and Stop Starting - Start Finishing! variability that affect performance David Anderson 3
  • 4. Work in Process Because we want to deliver new value quickly, we want to limit the amount of work that we take on at one time We want to finish items before starting others 4
  • 5. Pull Work not Push There is a queue of work, which goes through a number of stages until its done. 5
  • 6. Kanban Pull Backlog Step 1 Step 2 Step n Done In In In Process Process Process Flow 6
  • 7. Kanban Pull With Limits That looks very like a typical Agile Task Board. However, there is one more important element which really defines a Kanban system - limits.  There are two basic limits WIP limits and Queue limits 7
  • 8. WIP Limits Governs the maximum number of work items that can be in that state at any instant 8
  • 9. Queues and Queue Limits A queue distinguishes work that is eligible to be pulled, from work that is still in process. The queue allows for slack 9
  • 10. Queues and Limits Backlog Step 1 Step 2 … Step n Done Queue In In In Process Queue Process Queue Process (3) (2) … 10
  • 11. Leading Indicators Agile development has long rallied around “inspect and adapt”. Early agile methods built their feedback around velocity. This is a trailing indicator. With the regulating power of limits, it tells you about problems in your process, while you are experiencing the problem! 11
  • 12. Bottlenecks - Stall 12
  • 13. Bottlenecks - Vacant Space 13
  • 14. Kanban Workflow We ensure the right work is done at the right time, rather than who is doing the work. 14
  • 15. New Kind of Standup 15
  • 16. A New Kind of Planning Planning can be ‘de-coupled’ 16
  • 17. Releasing Releasing can be ‘de-coupled’ 17
  • 18. Iterations Iterative Development Without Iterations tim gth e len 18
  • 19. Retrospectives We have more choice on when and how to reflect and improve 19
  • 20. De-Coupling 20
  • 21. Metrics Metrics are a tool for everybody The team is responsible for its metrics Metrics allow for continuous improvement Red, Amber, Green is not enough. 21
  • 22. Cumulative Flow 22
  • 23. Work Breakdown 23
  • 24. Kanban for Everyone 24
  • 25. Lean Decision Filter 1. Value trumps flow  Expedite at the expense of flow to maximise value 2. Flow trumps waste elimination Increase WIP, if required to maintain flow, even though it may add waste 3. Eliminate waste to improve efficiency  25
  • 26. Kanban Usage 26
  • 27. Kanban Summary John Seddon - Freedom from Command & Control 27
  • 28. Experience Report Eric Willeke - Kanbandev Yahoo! group 28
  • 29. Kanban began in one product team in mid 2008 Continually evolving... 29
  • 30. Kanban began in one product team in mid 2008 Continually evolving... 30
  • 31. The Kanban “flu” soon spreads to other teams Application Support
  • 32. The Kanban “flu” soon spreads to other teams Application Support Pro duct Teams 32
  • 33. The Kanban “flu” soon spreads to other teams Application Support Pro duct Teams Design Team 33
  • 34. The Kanban “flu” soon spreads to other teams Application Support Pro duct Teams Design Team CO TS Team 34
  • 35. 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 35
  • 36. Future Media & Technology! 36
  • 37. 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 37
  • 38. 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. 38 Data split at financial year end and in July
  • 39. 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. 39 Data split at financial year end and in July
  • 40. 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. 40 Data split at end and in July
  • 41. 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. 41 Data split at financial year end and in July
  • 42. Upward trend. Rising to almost every working day. Throughput Expected as code base is decoupled, work items broken into MMFs, and cycle time reduces.
  • 43. 43 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.
  • 44. Kanban Summary John Seddon - Freedom from Command & Control
  • 45. Scrumban Scrumban is useful for existing Scrum teams, who are looking to improve their scale or capability 45
  • 46. 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 46
  • 47. Thank you Questions? John Seddon - Freedom from Command & Control