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.

Transcript

1. by Zsolt Fabok I Broke the WIP limit TWICE Still on the team
2. @ZsoltFabok and http://zsoltfabok.com/
4. lead time (minutes) moving (minutes) waiting (minutes) flow efficiency 46 40 6 87%
6. lead time (minutes) moving (minutes) waiting (minutes) flow efficiency 46 40 6 87% 44 40 4 91%
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/