Upgrade to Pro — share decks privately, control downloads, hide ads and more …

I broke the WIP Limit TWICE, still on the team

6189cdb415d0b7cdbfac8ba2054b2fc1?s=47 Zsolt Fabok
November 01, 2013

I broke the WIP Limit TWICE, still on the team

History:
- updated after #lkuk13 (2013-11-01)
- first version after #lknl13 (2013-10-09)

Abstract:

Hi, my name is Zsolt, I broke the WIP limit several times, I'm still on the team and I'm happy about it. Most probably you've had a similar experience (except maybe you weren't happy at all) when you first started to work in a team that got hit by the Kanban method introduced by one of your fellow teammates. At first, it is hard to follow and understand all the principles and practices, especially when they "hit" us, and therefore we make mistakes. This is good and natural because this is how we live our lives: we fail, we recover and start over.

Starting over requires us to do at least two things: re-learn the principles and practices, and look for examples on how others recovered. I believe that understanding the pull system, the WIP limits, and the difference between manufacturing and software development will give us enough to recover faster from failures and accelerate the learning process. Moreover, I assume that I did more wrong than right during my journey in Kanban land, and it cost me a lot. I believe that if I share these stories with you, it will save you a great deal of trouble for yourself, and if not, at least you'll have some ideas on how to recover.

Clearly, this talk is not for advanced practicioners, but I think they are as rare as unicorns anyway. So, if you have doubts, or want to know why we do things in the Kanban method as we do now, and you are also interested in some practical ideas, this talk is the right place for you.

6189cdb415d0b7cdbfac8ba2054b2fc1?s=128

Zsolt Fabok

November 01, 2013
Tweet

Transcript

  1. by Zsolt Fabok I Broke the WIP limit TWICE Still

    on the team
  2. @ZsoltFabok and http://zsoltfabok.com/

  3. None
  4. lead time (minutes) moving (minutes) waiting (minutes) flow efficiency 46

    40 6 87%
  5. None
  6. lead time (minutes) moving (minutes) waiting (minutes) flow efficiency 46

    40 6 87% 44 40 4 91%
  7. None
  8. None
  9. None
  10. lead time (minutes) moving (minutes) waiting (minutes) flow efficiency 46

    40 6 87% 44 40 4 91% 35 31 4 89%
  11. lead time (minutes) moving (minutes) waiting (minutes) flow efficiency 46

    40 6 87% 44 40 4 91% 35 31 4 89% 38 26 12 68%
  12. Where is the Kanban Method in all this?

  13. It is in the deltas between the steps; the desire

    to improve continuously.
  14. Small incremental evolutionary changes (continuous improvement)

  15. The Pull System

  16. If you understand the purpose of small incremental evolutionary changes

    and the pull system, you’ll do fine with the Kanban Method, because you can easily deduce the rest. (helping questions: Am I improving? Am I pulling the work?)
  17. It is hard to improve the invisible, so we have

    to see what we have at our hands.
  18. Meet the team

  19. Value Stream Mapping Start with what you do now (possibly

    end to end)
  20. Car manufacturing vs software engineering “The gemba walk” (Unfortunately, you

    won’t see much at a software engineering workplace) (http://zsoltfabok.com/blog/2013/06/gemba-walk-has-low-value/)
  21. Value Stream Mapping

  22. Design Implementation Delivery Test information work item http://zsoltfabok.com/blog/2012/04/see-the-whole-flow-exercise/

  23. Design Implementation Delivery Test

  24. Ready Design Implementation Test Delivery Live

  25. This board was a “traditional” board, how about a less

    “traditional” one?
  26. Courtesy of Prezi.com

  27. We decided that we are going to discover our value

    stream (flow) on the go.
  28. Ready Design Implementation Test Delivery Live Flow (Stream) The flow

    ([value] stream) starts at the left side, and ends at the right side of the board.
  29. The Flow is different in a typical enterprise and start-up

    environment.
  30. Typical enterprise flow Flow (Stream)

  31. Typical start-up flow Flow Flow Flow

  32. Now we can see the previously unseen, but we need

    to start pulling work items otherwise they won’t get delivered.
  33. Ready Design Implementation Test Delivery Live # ~ ~ ~

    # ~ ~ ~ # ~ ~ ~ # ~ ~ ~ # ~ ~ ~
  34. Ready Design Implementation Test Delivery Live # ~ ~ ~

    # ~ ~ ~ # ~ ~ ~ # ~ ~ ~ # ~ ~ ~
  35. Ready Design Implementation Test Delivery Live # ~ ~ ~

    # ~ ~ ~ # ~ ~ ~ # ~ ~ ~ # ~ ~ ~
  36. Ready Design Implementation Test Delivery Live # ~ ~ ~

    # ~ ~ ~ # ~ ~ ~ # ~ ~ ~ # ~ ~ ~
  37. The pull system itself does not guarantee that work items

    get to be delivered.
  38. That’s when the Work In Progress (WIP) limit comes into

    the picture.
  39. Ready Design Implementation Test Delivery Live # ~ ~ ~

    1 2 1 3 # ~ ~ ~ # ~ ~ ~ # ~ ~ ~ # ~ ~ ~
  40. How to set the WIP limit at the beginning?

  41. # ~ ~ ~ # ~ ~ ~ # ~

    ~ ~ work done staff liquidity + internal queue
  42. Too low WIP limit creates unnecessary bottleneck, too high WIP

    limit encourages multitasking and/or longer lead time.
  43. Yes, the WIP limit can change over time.

  44. # ~ ~ ~ work done week 1 week 2

    week 3 week 4
  45. Car manufacturing vs software engineering “The inventory” (At Toyota the

    inventory is finite, however in software engineering it is infinite, therefore we cannot approach it with the same attitude)
  46. And now, back to the queues.

  47. There is another kind of queue: the infinite queue.

  48. 2 1 Visible Invisible 2 3 Infinite queues

  49. Now the work items are getting delivered, it is time

    to improve the system. Improvement requires measurement.
  50. The lead time Ready Design Implementation Test Delivery Live 1

    2 1 3 # ~ ~ ~ # ~ ~ ~ # ~ ~ ~ commitment
  51. Distribution of lead times days count 0 3 5 8

    10 13 15 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 22 28 33 56 average median* *Calculation of medians is a popular technique in summary statistics and summarizing statistical data, since it is simple to understand and easy to calculate, while also giving a measure that is more robust in the presence of outlier values Courtesy of Digital Natives
  52. Car manufacturing vs software engineering “The takt time” (In software

    engineering the demand is not quantitive, therefore it doesn’t matter how much time we spend between two features)
  53. Car manufacturing vs software engineering “The throughput” (In software engineering

    we don’t have to deliver 10 features, we have to deliver THE feature, therefore the number of delivered feature doesn’t help us, but it is a good “secondary” measure)
  54. Car manufacturing vs software engineering “The throughput” (In software engineering

    we don’t have to deliver 10 features, we have to deliver THE feature, therefore the number of delivered feature doesn’t help us, but it is a good “secondary” measure to see how we react to changes, or how good we are at forecasting)
  55. 0 2 4 5 7 week 1 week 2 week

    3 week 4 incoming outgoing The throughput
  56. The throughput (output) is helpful, if and only if it

    is compared to the demand (input).
  57. 1 2 1 3 # ~ ~ ~ # ~

    ~ ~ 0 2 4 5 7 w 1 w 2 w 3 w 4 6
  58. The goal is to have a stable system (first target)

    because improvement on a stable system will have a long term effect (second target).
  59. 1 2 1 3 # ~ ~ ~ # ~

    ~ ~ 0 2 4 5 7 w 1 w 2 w 3 w 4 7 It is Monday on Week 5... # ~ ~ ~ # ~ ~ ~ # ~ ~ ~ # ~ ~ ~ # ~ ~ ~ # ~ ~ ~ Aging item
  60. The aging items mess up your forecasting.

  61. 0 2 4 5 7 w 1 w 2 w

    3 w 4 throughput *This argument is so weak that a decent philosopher stops thinking about philosophy and looks for another profession every time one reads it up “We get N items a week” “We deliver N items a week” “Therefore we can deliver an item in a week” “We deliver an item in a week” Therefore our lead time is the length of the week which is 5 days)”*
  62. days count 0 3 5 8 10 13 15 1

    2 3 4 5 6 7 8 9 But in reality you are actually here: 5 != [6,9]
  63. Protect the bottleneck and don’t punish the phase before the

    bottleneck. (with Theory of Constraints)
  64. 3 3 4 2 # ~ ~ ~ # ~

    ~ ~ Bottleneck
  65. 3 3 4 2 # ~ ~ ~ It hurts

    here... ...because the work items queue up here. # ~ ~ ~ # ~ ~ ~ # ~ ~ ~ # ~ ~ ~
  66. 3 3 4 2 # ~ ~ ~ # ~

    ~ ~ 2 Now the bottleneck is better protected... # ~ ~ ~ # ~ ~ ~ # ~ ~ ~ ...and the phase before the bottleneck doesn’t suffer.
  67. Cost of delay flavored Kanban

  68. Courtesy of Prezi.com

  69. time impact Level 1 The original idea comes from Thomas

    Jeffrey: http://bit.ly/exBGNo
  70. time impact cost of delay Level 1

  71. time impact Level 2

  72. t1 cost of delay time impact Level 2

  73. time impact t2 Level 2 will eventually turn into Level

    1
  74. time impact Level 3

  75. time impact t1 no cost of delay Level 3

  76. time impact t2 Level 3 will eventually turn into Level

    2
  77. time impact And, Level 2 will turn into Level 1

  78. time impact Improvement, technical debts. You know those we always

    talk about, but never actually do
  79. Courtesy of Prezi.com

  80. 0 4 8 11 15 week 1 week 2 week

    3 week 4 incoming outgoing Real data will come after finishing this experiment!
  81. If you understand the purpose of small incremental evolutionary changes

    and the pull system, you’ll do fine in Kanban land, because you can easily deduce the rest. And be skeptical about the practices that come from the manufacturing world (context matters).
  82. Thank you very much for your attention! @ZsoltFabok http://zsoltfabok.com/