1 00:00:06,870 --> 00:00:09,703 - [Instructor] SAFe lean agile principle number six. 2 00:00:09,703 --> 00:00:11,261 Visualize and limit WIP. 3 00:00:11,261 --> 00:00:13,995 Reduce bad batch sizes and manage queue lengths. 4 00:00:13,995 --> 00:00:16,732 Wow, that's a pretty power-packed principle. 5 00:00:16,732 --> 00:00:17,615 Let's start at the back. 6 00:00:17,615 --> 00:00:19,307 Let's start with queues. 7 00:00:19,307 --> 00:00:20,672 Let's start with an assumption. 8 00:00:20,672 --> 00:00:23,342 Long queues are bad, okay? 9 00:00:23,342 --> 00:00:24,504 Think about it for a second. 10 00:00:24,504 --> 00:00:26,387 When was the last time you were in a queue? 11 00:00:26,387 --> 00:00:28,023 The small queue at Starbucks this morning, 12 00:00:28,023 --> 00:00:29,249 that wasn't bad. 13 00:00:29,249 --> 00:00:32,137 There was a long queue checking in last night at the hotel, 14 00:00:32,137 --> 00:00:33,741 that was bad, okay? 15 00:00:33,741 --> 00:00:38,333 So, long queues suffer from very common effects. 16 00:00:38,333 --> 00:00:40,067 Longer cycle times, why? 17 00:00:40,067 --> 00:00:41,699 Takes longer to get through the queue. 18 00:00:41,699 --> 00:00:43,448 Increased risk, why? 19 00:00:43,448 --> 00:00:44,835 Because things can decay. 20 00:00:44,835 --> 00:00:46,749 I can decide to leave that queue. 21 00:00:46,749 --> 00:00:49,799 Or in the case of my requirements proxy, 22 00:00:49,799 --> 00:00:51,576 I've got a big batch of requirements, 23 00:00:51,576 --> 00:00:54,190 but they're gonna evolve, right? 24 00:00:54,190 --> 00:00:55,366 More variability, why? 25 00:00:55,366 --> 00:00:57,225 Let me just give you an example. 26 00:00:57,225 --> 00:01:00,193 If I go to Starbucks before a PI planning session, 27 00:01:00,193 --> 00:01:02,690 which I used to do for a team in Chicago, 28 00:01:02,690 --> 00:01:05,493 a big team, I would go to Starbucks and 29 00:01:05,493 --> 00:01:07,976 how quickly I got out of there depended on the queue. 30 00:01:07,976 --> 00:01:08,956 But guess what. 31 00:01:08,956 --> 00:01:11,885 It was more variable the higher the length of the queue was. 32 00:01:11,885 --> 00:01:13,825 If I went there and there were only three people 33 00:01:13,825 --> 00:01:15,870 and one ordered a heated bagel and the other two 34 00:01:15,870 --> 00:01:18,532 just got Venti coffees I was out of there pretty quick. 35 00:01:18,532 --> 00:01:20,622 Basically, equaled the heated bagel time. 36 00:01:20,622 --> 00:01:22,705 If I went in there and there were 15 people 37 00:01:22,705 --> 00:01:25,288 and they all ordered Venti coffees I got 38 00:01:25,288 --> 00:01:26,885 out of there really quick too. 39 00:01:26,885 --> 00:01:29,218 But if I went in there where there are 15 people, 40 00:01:29,218 --> 00:01:31,952 and nine of them ordered heated bagels I'm late for work. 41 00:01:31,952 --> 00:01:33,360 And I don't control that. 42 00:01:33,360 --> 00:01:36,292 Every long queue has more variability than a short queue. 43 00:01:36,292 --> 00:01:38,477 So we think about our work coming our way. 44 00:01:38,477 --> 00:01:40,303 If it's a really long queue, I'm gonna have more 45 00:01:40,303 --> 00:01:42,889 variability in my ability to process that work. 46 00:01:42,889 --> 00:01:44,969 Lower quality, requirements decay, 47 00:01:44,969 --> 00:01:46,618 people get rushed, et cetera, et cetera. 48 00:01:46,618 --> 00:01:49,117 And by the way, how motivated are you at the 49 00:01:49,117 --> 00:01:49,950 end of a long queue? 50 00:01:49,950 --> 00:01:53,416 Whether it be one year, two year product lifecycle, 51 00:01:53,416 --> 00:01:56,854 where nothing's gonna be shown until maybe nine months in? 52 00:01:56,854 --> 00:01:59,550 Or a much shorter queue that says we're gonna take 53 00:01:59,550 --> 00:02:02,900 these requirements and do this very briefly? 54 00:02:02,900 --> 00:02:06,139 And I received this email from one of my clients 55 00:02:06,139 --> 00:02:09,950 a few years back right when I was teaching about lien, 56 00:02:09,950 --> 00:02:12,018 and said thank you for contacting us we're 57 00:02:12,018 --> 00:02:14,262 experiencing increased volumes and apologized in 58 00:02:14,262 --> 00:02:15,514 advance for the the delay. 59 00:02:15,514 --> 00:02:17,039 Our goal is to contact you within-- 60 00:02:17,039 --> 00:02:19,178 Okay, I'm not sure if they do or 61 00:02:19,178 --> 00:02:20,400 don't understand queuing theory, 62 00:02:20,400 --> 00:02:22,829 but very clearly that's not an email I wanna get. 63 00:02:22,829 --> 00:02:24,324 Long queues all bad. 64 00:02:24,324 --> 00:02:25,411 We wanna manage those queue lengths. 65 00:02:25,411 --> 00:02:26,955 Lots of ways to do that. 66 00:02:26,955 --> 00:02:29,936 Way to the shortest job first is gonna help us with that. 67 00:02:29,936 --> 00:02:30,950 How do we reduce queue lengths? 68 00:02:30,950 --> 00:02:32,361 Well we have to understand the fundamental 69 00:02:32,361 --> 00:02:33,507 law of queuing theory. 70 00:02:33,507 --> 00:02:35,566 That sounds kinda complex because it's got lambda in it. 71 00:02:35,566 --> 00:02:37,837 So all your algebra brains are gonna start either 72 00:02:37,837 --> 00:02:39,844 really being happy with this or start freaking out. 73 00:02:39,844 --> 00:02:41,454 But let's make it very simple. 74 00:02:41,454 --> 00:02:44,475 The average wait time for a thing in the queue 75 00:02:44,475 --> 00:02:46,850 is equal to the average queue length 76 00:02:46,850 --> 00:02:48,939 divided by the average processing rate. 77 00:02:48,939 --> 00:02:49,925 It's just a fact. 78 00:02:49,925 --> 00:02:52,012 It's a theory that has associated proof. 79 00:02:52,012 --> 00:02:54,284 That says that the average time for me to wait 80 00:02:54,284 --> 00:02:57,671 at Starbucks is equal to the average length of the queue, 81 00:02:57,671 --> 00:02:58,902 the number of people in front of me, 82 00:02:58,902 --> 00:03:00,265 and the average processing rate. 83 00:03:00,265 --> 00:03:02,359 And the average processing rate is where 84 00:03:02,359 --> 00:03:04,733 all that variability stops in, okay? 85 00:03:04,733 --> 00:03:06,586 So, when you understand that we start thinking 86 00:03:06,586 --> 00:03:09,367 a little bit differently about the work in front of us, 87 00:03:09,367 --> 00:03:11,004 and the work that's headed our way. 88 00:03:11,004 --> 00:03:13,569 Now obviously, if I can increase lambda, 89 00:03:13,569 --> 00:03:15,233 faster processing time increases wait. 90 00:03:15,233 --> 00:03:18,901 So if you can code faster, yes the wait time can be shorter. 91 00:03:18,901 --> 00:03:20,416 But it's really hard to code faster. 92 00:03:20,416 --> 00:03:23,988 Now you can test automation and better practices 93 00:03:23,988 --> 00:03:25,895 to allow you to decrease lambda in terms 94 00:03:25,895 --> 00:03:27,773 of your ability to turn that software around, 95 00:03:27,773 --> 00:03:28,958 but if you wanna shorten the wait time you 96 00:03:28,958 --> 00:03:30,838 gotta have less of a queue, okay? 97 00:03:30,838 --> 00:03:32,774 And you control the wait times by controlling queue lengths. 98 00:03:32,774 --> 00:03:34,602 Now let's look at the impact on that. 99 00:03:34,602 --> 00:03:36,737 Let's just say that for example, 100 00:03:36,737 --> 00:03:40,242 we process ten features per quarter. 101 00:03:40,242 --> 00:03:42,470 On 12 week PIs we deliver 10 features. 102 00:03:42,470 --> 00:03:44,905 And commit a set of 30 features. 103 00:03:44,905 --> 00:03:46,468 That says a new feature will experience 104 00:03:46,468 --> 00:03:49,233 approximate wait time of 30 items divided by 105 00:03:49,233 --> 00:03:51,493 10 items in the queue or three-quarters. 106 00:03:51,493 --> 00:03:53,263 So I thought it was pretty fast. 107 00:03:53,263 --> 00:03:54,912 Now let's double that. 108 00:03:54,912 --> 00:03:58,352 Let's just say I've committed 60 features, 109 00:03:58,352 --> 00:03:59,814 how long do I have to wait now? 110 00:03:59,814 --> 00:04:02,279 For the 60th feature, I have to wait twice as long. 111 00:04:02,279 --> 00:04:06,477 So all of a sudden this is six quarters, a year and a half. 112 00:04:06,477 --> 00:04:08,342 And I had to wait that long only because I 113 00:04:08,342 --> 00:04:10,132 doubled the length of the queue. 114 00:04:10,132 --> 00:04:12,957 If I withheld that request or simply not 115 00:04:12,957 --> 00:04:15,211 let that end through work in process limit, 116 00:04:15,211 --> 00:04:16,509 I wouldn't have achieved that. 117 00:04:16,509 --> 00:04:19,691 So Little's Law never lies, it's always true. 118 00:04:19,691 --> 00:04:22,522 The average wait time for an item in the queue is 119 00:04:22,522 --> 00:04:24,438 equal to the average length of the queue divided 120 00:04:24,438 --> 00:04:26,643 by lambda the average processing rate. 121 00:04:26,643 --> 00:04:28,255 Now here's a question, is your 122 00:04:28,255 --> 00:04:31,793 program seemingly delivering slow? 123 00:04:31,793 --> 00:04:33,037 If your stakeholders feel like you're 124 00:04:33,037 --> 00:04:36,019 slow in delivering your result, 125 00:04:36,019 --> 00:04:40,908 is there a lot of work stacked up they're waiting on? 126 00:04:40,908 --> 00:04:43,337 Then by definition you're slow. 127 00:04:43,337 --> 00:04:44,858 And even if you were lightening fast, 128 00:04:44,858 --> 00:04:46,385 if we double the queue length you're now 129 00:04:46,385 --> 00:04:48,514 half as fast as you were delivered value. 130 00:04:48,514 --> 00:04:50,862 So if you want to deliver more quickly, 131 00:04:50,862 --> 00:04:52,895 we have to keep our backlog short. 132 00:04:52,895 --> 00:04:55,468 Now is a backlog a queue? 133 00:04:55,468 --> 00:04:57,408 Not necessarily, because a thing can 134 00:04:57,408 --> 00:05:00,363 jump the queue in a backlog. 135 00:05:00,363 --> 00:05:02,463 But if all the items in a backlog are 136 00:05:02,463 --> 00:05:04,931 committed it behaves exactly like a queue. 137 00:05:04,931 --> 00:05:06,731 So if you have a really long backlog 138 00:05:06,731 --> 00:05:09,169 of committed items you're slow. 139 00:05:09,169 --> 00:05:10,915 It's nothing you're doing about lambda, 140 00:05:10,915 --> 00:05:13,462 it's not your fault, other than maybe not understanding 141 00:05:13,462 --> 00:05:16,287 queuing theory and how that works. 142 00:05:16,287 --> 00:05:18,977 Visualize and limit work in process to control queues. 143 00:05:18,977 --> 00:05:20,346 I'm gonna tell ya a true story and 144 00:05:20,346 --> 00:05:21,848 add a little bit of theory to it. 145 00:05:21,848 --> 00:05:24,317 So I was in Chicago a few years back helping 146 00:05:24,317 --> 00:05:26,556 a fairly agile enterprise. 147 00:05:26,556 --> 00:05:29,018 Now this wasn't a particularly disciplined approach 148 00:05:29,018 --> 00:05:29,980 I will tell you that. 149 00:05:29,980 --> 00:05:33,226 There were 20 or 30 people, two or three small agile teams. 150 00:05:33,226 --> 00:05:35,725 And they frankly weren't getting the job done. 151 00:05:35,725 --> 00:05:37,967 But they believed they were agile and for good reason. 152 00:05:37,967 --> 00:05:39,447 They had a lot of basic practices. 153 00:05:39,447 --> 00:05:42,049 And I went in and visited them, 154 00:05:42,049 --> 00:05:43,756 probably Wednesday of that week, 155 00:05:43,756 --> 00:05:45,736 they had a story board, which I liked. 156 00:05:45,736 --> 00:05:48,064 I like story boards better than pass boardS, 157 00:05:48,064 --> 00:05:50,060 because I'm more worried about the progress of 158 00:05:50,060 --> 00:05:52,137 the story through the system than I am about 159 00:05:52,137 --> 00:05:53,397 whether or not you did your task. 160 00:05:53,397 --> 00:05:56,998 So I think when we use story boards for our 161 00:05:56,998 --> 00:05:59,567 scrum boards or for our kanban boards we're 162 00:05:59,567 --> 00:06:01,377 a lot better than when we think about task. 163 00:06:01,377 --> 00:06:04,438 Just the wrong level of attention to detail. 164 00:06:04,438 --> 00:06:06,298 We wanna think about the value moving 165 00:06:06,298 --> 00:06:09,223 through the system not the tasks I do to do that. 166 00:06:09,223 --> 00:06:10,129 They didn't have two things. 167 00:06:10,129 --> 00:06:12,616 They didn't have this, right? 168 00:06:12,616 --> 00:06:13,835 Whatever this thing is. 169 00:06:13,835 --> 00:06:15,328 So I went in and looked at their board, 170 00:06:15,328 --> 00:06:17,024 and they were in a two week sprint. 171 00:06:17,024 --> 00:06:19,544 And you can kinda tell where I was. 172 00:06:19,544 --> 00:06:20,616 First thing I did was I printed these 173 00:06:20,616 --> 00:06:22,419 dates out and I went and put them on top, 174 00:06:22,419 --> 00:06:24,639 and then I said does anybody have a rope or something, 175 00:06:24,639 --> 00:06:26,818 or a set of headphones, anything vertical? 176 00:06:26,818 --> 00:06:28,405 And somebody had a set of headphones, 177 00:06:28,405 --> 00:06:30,189 they said well these are broken. 178 00:06:30,189 --> 00:06:31,812 They thought I was a crazy man anyway. 179 00:06:31,812 --> 00:06:32,910 Might of been right. 180 00:06:32,910 --> 00:06:35,876 So I went in and I stapled them up there. 181 00:06:35,876 --> 00:06:39,015 And I asked the team to look at the board. 182 00:06:39,015 --> 00:06:40,743 I'll ask you this question. 183 00:06:40,743 --> 00:06:43,896 How are they doing on this sprint? 184 00:06:43,896 --> 00:06:45,841 What do you think? 185 00:06:45,841 --> 00:06:47,772 Gonna pull it off? 186 00:06:47,772 --> 00:06:49,300 Doesn't' look like it. 187 00:06:49,300 --> 00:06:51,540 All other things being equal, 188 00:06:51,540 --> 00:06:53,569 they have things they haven't even started 189 00:06:53,569 --> 00:06:55,294 that are supposed to be delivered Tuesday. 190 00:06:55,294 --> 00:06:58,399 They have five items stacked up in development. 191 00:06:58,399 --> 00:06:59,404 They only have three stories. 192 00:06:59,404 --> 00:07:01,260 So on Thursday of that week there's only 193 00:07:01,260 --> 00:07:02,603 one story that's been accepted. 194 00:07:02,603 --> 00:07:04,191 This is not linear flow. 195 00:07:04,191 --> 00:07:06,986 It may be agile, it may be scrum, maybe even 196 00:07:06,986 --> 00:07:09,924 good XP practice, but it is not linear flow. 197 00:07:09,924 --> 00:07:11,984 So, we had a quick talk about that. 198 00:07:11,984 --> 00:07:14,125 We had a talk about work in process lineaments 199 00:07:14,125 --> 00:07:16,393 and I made a supposition, okay? 200 00:07:16,393 --> 00:07:19,456 And that supposition ends up being in this exercise, 201 00:07:19,456 --> 00:07:20,974 which we'll just talk through together. 202 00:07:20,974 --> 00:07:24,767 So, what if Dean was there that day and he said I'm 203 00:07:24,767 --> 00:07:28,934 gonna put a pre-story limit on this stage and this stage? 204 00:07:31,933 --> 00:07:33,845 Why would he do that? 205 00:07:33,845 --> 00:07:35,168 You're gonna limit our work? 206 00:07:35,168 --> 00:07:37,477 We're behind the eight ball, we're not delivering on time, 207 00:07:37,477 --> 00:07:40,931 and you wanna limit the work we're doing? 208 00:07:40,931 --> 00:07:42,323 Yeah, I do. 209 00:07:42,323 --> 00:07:44,598 And why would I do that? 210 00:07:44,598 --> 00:07:45,964 So let's do a simple scenario. 211 00:07:45,964 --> 00:07:48,512 Let's say that Dean isn't there and I'm a 212 00:07:48,512 --> 00:07:50,753 developer and I finish story five. 213 00:07:50,753 --> 00:07:52,338 What am I gonna do as the developer? 214 00:07:52,338 --> 00:07:54,038 I'm gonna go get another story. 215 00:07:54,038 --> 00:07:55,391 But I can't get another story, 216 00:07:55,391 --> 00:07:57,041 and the reason is that there's now a work in 217 00:07:57,041 --> 00:08:01,413 process limit that says I can only have three. 218 00:08:01,413 --> 00:08:02,762 So not only can I not get another 219 00:08:02,762 --> 00:08:04,369 story I have to do something else. 220 00:08:04,369 --> 00:08:05,688 What do I have to do? 221 00:08:05,688 --> 00:08:06,891 You tell me. 222 00:08:06,891 --> 00:08:09,793 I have to figure how to get some stories tested. 223 00:08:09,793 --> 00:08:13,069 All of a sudden T skills, cross functional skills, 224 00:08:13,069 --> 00:08:14,999 the accountability for actually delivering value 225 00:08:14,999 --> 00:08:16,465 starts to kick in. 226 00:08:16,465 --> 00:08:18,840 And I had one individual kick back at that. 227 00:08:18,840 --> 00:08:21,297 He said you know, I'm a JAVA dev. 228 00:08:21,297 --> 00:08:23,922 I'm not very good at running quality center here, 229 00:08:23,922 --> 00:08:25,561 and those scripts and stuff. 230 00:08:25,561 --> 00:08:27,058 But I'm really good Java dev. 231 00:08:27,058 --> 00:08:31,662 And he said, I was hired here to do this work. 232 00:08:31,662 --> 00:08:33,166 And we had a very frank conversation. 233 00:08:33,166 --> 00:08:36,293 And said what were you hired here to do? 234 00:08:36,293 --> 00:08:38,552 Well, to deliver value. 235 00:08:38,552 --> 00:08:40,811 But that value can't be purely coding, 236 00:08:40,811 --> 00:08:44,978 because clearly we have more code than we can test. 237 00:08:45,829 --> 00:08:47,263 So one of two things has to happen, 238 00:08:47,263 --> 00:08:48,725 we have to add one of three. 239 00:08:48,725 --> 00:08:53,255 More testers, more test automation, or better you can test. 240 00:08:53,255 --> 00:08:56,108 And I've had many situations where people come 241 00:08:56,108 --> 00:08:59,520 to the conclusion that yeah, indeed I'm a developer 242 00:08:59,520 --> 00:09:00,711 and I can test. 243 00:09:00,711 --> 00:09:03,220 I've had certain circumstances where at a point of 244 00:09:03,220 --> 00:09:05,722 frustration and agile transformation, 245 00:09:05,722 --> 00:09:07,911 the management team just said we're 246 00:09:07,911 --> 00:09:09,364 hiring no further testers. 247 00:09:09,364 --> 00:09:11,546 What you have is what you have period. 248 00:09:11,546 --> 00:09:14,167 And then basically, all of a sudden the developers 249 00:09:14,167 --> 00:09:16,294 moved into test and test automation, 250 00:09:16,294 --> 00:09:18,896 because they don't wanna run the same test more than once. 251 00:09:18,896 --> 00:09:22,123 So lots of ways to get there, but clearly the T skills, 252 00:09:22,123 --> 00:09:23,859 I'm a developer and I can test. 253 00:09:23,859 --> 00:09:27,912 That's one form of a T skill is really critical to flow. 254 00:09:27,912 --> 00:09:31,556 And visualizing the flow makes those bottlenecks clear, 255 00:09:31,556 --> 00:09:33,717 and made the problem clear here. 256 00:09:33,717 --> 00:09:35,775 Insufficient testing resources, 257 00:09:35,775 --> 00:09:37,458 insufficient test automation, 258 00:09:37,458 --> 00:09:39,814 insufficient number of developers who would do the tests. 259 00:09:39,814 --> 00:09:43,492 It wasn't obvious before we put the three on the board. 260 00:09:43,492 --> 00:09:45,563 So that's the effect of work in process constraints. 261 00:09:45,563 --> 00:09:47,392 And they are invaluable. 262 00:09:47,392 --> 00:09:50,344 I don't think I ever see a system now as I've evolved 263 00:09:50,344 --> 00:09:54,526 my own thinking and abilities around being what Toyota 264 00:09:54,526 --> 00:09:57,154 would call a lean thinking manager, teacher. 265 00:09:57,154 --> 00:09:58,833 I see work in process now. 266 00:09:58,833 --> 00:10:00,522 And I recently just put up a kanban board for a 267 00:10:00,522 --> 00:10:03,651 certain activity site that said look at all this WIP. 268 00:10:03,651 --> 00:10:06,036 It's like we wanna be a honey badger on WIP, 269 00:10:06,036 --> 00:10:07,364 you wanna eat that WIP and get that out of 270 00:10:07,364 --> 00:10:09,548 there so we can get flow going away. 271 00:10:09,548 --> 00:10:10,833 So we'll see WIP again. 272 00:10:10,833 --> 00:10:12,924 We'll see it in particular dev ops 273 00:10:12,924 --> 00:10:14,661 and continuous delivery WIP constraints. 274 00:10:14,661 --> 00:10:17,176 WIP constraints improve flow and increase through put. 275 00:10:17,176 --> 00:10:19,019 So it might seem counterproductive to 276 00:10:19,019 --> 00:10:20,611 somebody who doesn't understand it. 277 00:10:20,611 --> 00:10:22,583 Do I wanna limit work in process? 278 00:10:22,583 --> 00:10:24,859 Only if you wanna increase the amount of 279 00:10:24,859 --> 00:10:27,501 actual result for work in process. 280 00:10:27,501 --> 00:10:29,330 Here's an exercise that I'm gonna ask you to do. 281 00:10:29,330 --> 00:10:30,677 And I'm just gonna kinda give you 282 00:10:30,677 --> 00:10:31,952 the result of the exercise. 283 00:10:31,952 --> 00:10:34,556 In class we always run the penny exercise. 284 00:10:34,556 --> 00:10:37,319 And this is the simplest lean flow exercise 285 00:10:37,319 --> 00:10:38,152 that I'm familiar with. 286 00:10:38,152 --> 00:10:39,415 And it takes some time to do it. 287 00:10:39,415 --> 00:10:40,709 It takes some people to do it. 288 00:10:40,709 --> 00:10:43,320 I'll set it up and then I'll kinda show you the results. 289 00:10:43,320 --> 00:10:46,340 So, we'll take five groups of people at a table. 290 00:10:46,340 --> 00:10:47,624 Ten coins per group. 291 00:10:47,624 --> 00:10:49,398 One person is timekeeper. 292 00:10:49,398 --> 00:10:51,700 The remaining four people process the coins. 293 00:10:51,700 --> 00:10:53,446 In order to process the coins they flip 294 00:10:53,446 --> 00:10:55,731 the coins one at a time and they record their own results. 295 00:10:55,731 --> 00:10:58,479 That's important, they have to record the results. 296 00:10:58,479 --> 00:11:00,568 Then when they're done with their ten pennies they 297 00:11:00,568 --> 00:11:03,338 push all the coins to the next position, 298 00:11:03,338 --> 00:11:05,787 and then that person does the same thing. 299 00:11:05,787 --> 00:11:10,307 This doesn't seem like horrifically inefficient process. 300 00:11:10,307 --> 00:11:12,259 I have 10 pennies, I'm flipping the pennies, 301 00:11:12,259 --> 00:11:14,372 I get it, I move it next door, boom boom. 302 00:11:14,372 --> 00:11:16,753 And we record the time from the start of the 303 00:11:16,753 --> 00:11:19,950 first flip to the completion of the last flip for the group. 304 00:11:19,950 --> 00:11:21,409 And that's one exercise. 305 00:11:21,409 --> 00:11:23,055 We record those times. 306 00:11:23,055 --> 00:11:25,303 So we might say some teams here, 307 00:11:25,303 --> 00:11:27,803 three, four, five, six, seven. 308 00:11:29,694 --> 00:11:31,646 And this is the ten penny batch. 309 00:11:31,646 --> 00:11:32,563 This is 10. 310 00:11:33,511 --> 00:11:34,673 And this is well, we'll get to this 311 00:11:34,673 --> 00:11:35,819 in a second it's gonna be one. 312 00:11:35,819 --> 00:11:38,571 We might see times that vary from two minutes 313 00:11:38,571 --> 00:11:42,012 and 47 seconds, 38 seconds, and you ask a question, 314 00:11:42,012 --> 00:11:43,837 you ask them to show them your results and they 315 00:11:43,837 --> 00:11:46,430 didn't record the results so that's not really true. 316 00:11:46,430 --> 00:11:48,263 A minute 15, three 15. 317 00:11:49,458 --> 00:11:50,887 Somebody dropped four pennies and 318 00:11:50,887 --> 00:11:54,726 they went down the vent, so four minutes. 319 00:11:54,726 --> 00:11:57,411 And two fifty, et cetera. 320 00:11:57,411 --> 00:11:59,306 And you analyze that data, and you look at the data 321 00:11:59,306 --> 00:12:00,880 and you say what do you see here? 322 00:12:00,880 --> 00:12:02,377 We'll throw that guy out and maybe we'll throw 323 00:12:02,377 --> 00:12:05,203 that guy out and still see tremendous variability. 324 00:12:05,203 --> 00:12:08,700 This is basically three, three, one, two forty-seven, 325 00:12:08,700 --> 00:12:09,844 and that's like three. 326 00:12:09,844 --> 00:12:13,532 So it varies from one to three minutes. 327 00:12:13,532 --> 00:12:17,962 Wow, that's a lot of process variability in that exercise. 328 00:12:17,962 --> 00:12:19,659 And you think, you know how I process 329 00:12:19,659 --> 00:12:20,909 the pennies really matter. 330 00:12:20,909 --> 00:12:25,076 So we may favor for sure people over process and tools, 331 00:12:26,377 --> 00:12:27,513 but process does matter. 332 00:12:27,513 --> 00:12:29,879 Because somebodies figured out a way without much 333 00:12:29,879 --> 00:12:32,012 instruction to get those pennies through quicker. 334 00:12:32,012 --> 00:12:34,332 Somebody else is much slower. 335 00:12:34,332 --> 00:12:35,874 And somebody else cheated by not understanding 336 00:12:35,874 --> 00:12:37,678 the requirements really well, okay? 337 00:12:37,678 --> 00:12:38,511 That's what you'll see. 338 00:12:38,511 --> 00:12:40,340 Well then we'll run the other half of the exercise. 339 00:12:40,340 --> 00:12:42,464 We'll take the same four person process, 340 00:12:42,464 --> 00:12:44,659 and each person flips the coin one at a time 341 00:12:44,659 --> 00:12:46,774 and records the result, there's a hand off. 342 00:12:46,774 --> 00:12:47,797 Pass the coin as flipped, 343 00:12:47,797 --> 00:12:50,018 or if you don't mind getting in the persons 344 00:12:50,018 --> 00:12:52,329 workspace you can pull the coin in. 345 00:12:52,329 --> 00:12:53,811 Now typically people will push it across because 346 00:12:53,811 --> 00:12:55,826 nobody likes their hands in their workspace. 347 00:12:55,826 --> 00:12:58,305 So one penny gets flipped, I write down the result, 348 00:12:58,305 --> 00:13:01,146 I push to the next person. 349 00:13:01,146 --> 00:13:03,488 Guess what the times come out? 350 00:13:03,488 --> 00:13:06,782 Well I hope you'll do this at some point and experience it. 351 00:13:06,782 --> 00:13:09,351 But here's the way the times typically come out. 352 00:13:09,351 --> 00:13:11,851 37, 30, 45, 46, 39, et cetera. 353 00:13:17,429 --> 00:13:18,512 Wow, amazing! 354 00:13:23,181 --> 00:13:26,939 Look at that, three X improvement in processing 355 00:13:26,939 --> 00:13:30,668 the jobs because I reduced the batch size to one, okay? 356 00:13:30,668 --> 00:13:33,201 And one of the most important things about this, 357 00:13:33,201 --> 00:13:35,578 if you look at the statistics and the math, 358 00:13:35,578 --> 00:13:38,122 and compare the 10 versus the one, 359 00:13:38,122 --> 00:13:40,014 the interesting question is when was the first 360 00:13:40,014 --> 00:13:42,224 penny completed at the final station? 361 00:13:42,224 --> 00:13:44,314 Cause that's your first delivery right? 362 00:13:44,314 --> 00:13:47,010 That's the first time one gets delivered. 363 00:13:47,010 --> 00:13:49,826 And it's not this because that was for the last. 364 00:13:49,826 --> 00:13:51,516 So what you typically find is something 365 00:13:51,516 --> 00:13:53,349 on the order of six X. 366 00:13:54,245 --> 00:13:58,399 In other words, the first release, the first penny, 367 00:13:58,399 --> 00:14:00,899 the first item in the batch was received 368 00:14:00,899 --> 00:14:03,609 five to six times earlier than the last one. 369 00:14:03,609 --> 00:14:04,844 That's huge. 370 00:14:04,844 --> 00:14:07,732 This is incremental development at work. 371 00:14:07,732 --> 00:14:10,043 All because of managing batch size. 372 00:14:10,043 --> 00:14:13,191 So batch size is another important thought. 373 00:14:13,191 --> 00:14:16,801 And when you start to see queues and WIP 374 00:14:16,801 --> 00:14:19,145 and batch sizes you're gonna start to get it, 375 00:14:19,145 --> 00:14:21,070 and you're gonna start to go I think I 376 00:14:21,070 --> 00:14:24,096 can make this system work faster without working harder. 377 00:14:24,096 --> 00:14:26,658 I have a mental model to do that. 378 00:14:26,658 --> 00:14:29,934 There's another really critical figure here 379 00:14:29,934 --> 00:14:32,635 in Poppendieck's work that helps us understand 380 00:14:32,635 --> 00:14:35,118 the problem even better. 381 00:14:35,118 --> 00:14:37,635 And what Poppendieck reports, and it's traditional 382 00:14:37,635 --> 00:14:40,919 discovery from manufacturing is that so long 383 00:14:40,919 --> 00:14:44,752 as we're not overly busy we have time to flex. 384 00:14:45,678 --> 00:14:49,845 Batch size doesn't change cycle time variability very much. 385 00:14:51,157 --> 00:14:53,026 We can get them through there, they're pretty quick. 386 00:14:53,026 --> 00:14:56,579 As soon utilization's get high, batch size 387 00:14:56,579 --> 00:14:58,410 starts to have a tremendous effect. 388 00:14:58,410 --> 00:15:01,174 And when utilization's get very high and the 389 00:15:01,174 --> 00:15:04,799 batch size gets very high you have incredibly 390 00:15:04,799 --> 00:15:06,639 high variability and outcomes. 391 00:15:06,639 --> 00:15:07,994 Here's a question. 392 00:15:07,994 --> 00:15:10,125 You're involved in delivering a large system, 393 00:15:10,125 --> 00:15:12,570 what is your utilization? 394 00:15:12,570 --> 00:15:14,548 Are you working half time? 395 00:15:14,548 --> 00:15:17,287 No you're already working full time, hundred percent. 396 00:15:17,287 --> 00:15:18,620 So you are here. 397 00:15:19,615 --> 00:15:21,425 What is the batch size? 398 00:15:21,425 --> 00:15:25,160 The entire set of requirements for my system. 399 00:15:25,160 --> 00:15:26,410 One PDCA cycle. 400 00:15:28,966 --> 00:15:31,647 Once giant batch of highly utilized systems 401 00:15:31,647 --> 00:15:34,861 says that I'm gonna have highly variable cycle time. 402 00:15:34,861 --> 00:15:36,229 And it's not variable on the low side, 403 00:15:36,229 --> 00:15:37,871 it's not gonna get done sooner, 404 00:15:37,871 --> 00:15:39,616 I get done later. 405 00:15:39,616 --> 00:15:42,783 So, if your projects are feeling late, 406 00:15:43,970 --> 00:15:47,128 if your stakeholders feel your slow, 407 00:15:47,128 --> 00:15:49,706 you are, but it's not because you're dogging it 408 00:15:49,706 --> 00:15:50,914 and you're not willing to do the work, 409 00:15:50,914 --> 00:15:53,007 and you're not putting the energy in. 410 00:15:53,007 --> 00:15:54,352 You're doing your best already. 411 00:15:54,352 --> 00:15:56,295 It's because the system is broken. 412 00:15:56,295 --> 00:15:58,407 The system is feeding you really large 413 00:15:58,407 --> 00:16:01,033 batches into fully utilized systems. 414 00:16:01,033 --> 00:16:02,956 And the statistics and the economics 415 00:16:02,956 --> 00:16:04,576 and the principles themselves say 416 00:16:04,576 --> 00:16:06,564 you're gonna get a terrible result. 417 00:16:06,564 --> 00:16:07,733 So what do we know? 418 00:16:07,733 --> 00:16:09,577 We know that large batch sizes-- 419 00:16:09,577 --> 00:16:11,530 Look at my big fat requirements documents and 420 00:16:11,530 --> 00:16:13,831 design documents increase variability. 421 00:16:13,831 --> 00:16:16,102 High utilization increases variability. 422 00:16:16,102 --> 00:16:19,360 Severe project slippage is the most likely result. 423 00:16:19,360 --> 00:16:22,580 So lean economics tell you that the waterfall 424 00:16:22,580 --> 00:16:25,427 is gonna have severe project slippage. 425 00:16:25,427 --> 00:16:26,260 It predicts that. 426 00:16:26,260 --> 00:16:27,579 It says it doesn't matter who's working on it, 427 00:16:27,579 --> 00:16:29,711 what country they're in, what their skills are, 428 00:16:29,711 --> 00:16:31,477 how fast they are, how hard they work, 429 00:16:31,477 --> 00:16:34,624 if this is a big project with a big batch size 430 00:16:34,624 --> 00:16:36,551 and people are heavily utilized you're gonna 431 00:16:36,551 --> 00:16:37,999 have a terrible result. 432 00:16:37,999 --> 00:16:41,780 Most important batch is the transport, the handoff batch. 433 00:16:41,780 --> 00:16:42,693 What's that mean? 434 00:16:42,693 --> 00:16:45,315 It means that the handoff of the ten pennies. 435 00:16:45,315 --> 00:16:47,726 It means the handoff from the developer to a tester. 436 00:16:47,726 --> 00:16:51,787 So if we can reduce that cost with proximity 437 00:16:51,787 --> 00:16:53,572 we can have smaller batches. 438 00:16:53,572 --> 00:16:56,931 So if the developers are on floor two and 439 00:16:56,931 --> 00:17:00,390 have a testing capability that's on floor four 440 00:17:00,390 --> 00:17:02,262 I'm gonna have to have a really large batch 441 00:17:02,262 --> 00:17:04,406 to communicate with to make that efficient. 442 00:17:04,406 --> 00:17:05,591 Cause I don't wanna go up to the fourth floor 443 00:17:05,591 --> 00:17:07,510 and talk to those people and say oh be sure 444 00:17:07,510 --> 00:17:08,601 and test this one thing. 445 00:17:08,601 --> 00:17:09,985 I'm gonna take them a big batch. 446 00:17:09,985 --> 00:17:12,163 If that developer is sitting right next to 447 00:17:12,163 --> 00:17:15,082 the tester the batch size is my story. 448 00:17:15,082 --> 00:17:18,121 And they're done, there's no further batching required. 449 00:17:18,121 --> 00:17:20,649 And good infrastructure enables small batches. 450 00:17:20,649 --> 00:17:22,185 Continuous innovation environment. 451 00:17:22,185 --> 00:17:24,466 So I can't get feedback, I have to have good batch. 452 00:17:24,466 --> 00:17:25,881 And that's gonna bring us to another 453 00:17:25,881 --> 00:17:29,124 key thought about optimizing batch sizes. 454 00:17:29,124 --> 00:17:31,791 And that is, like a lot of other things, 455 00:17:31,791 --> 00:17:34,123 optimizing batch size is an example of a 456 00:17:34,123 --> 00:17:35,569 U curve optimization. 457 00:17:35,569 --> 00:17:36,475 What do we mean by that? 458 00:17:36,475 --> 00:17:40,849 We mean that here's the items for batch down below. 459 00:17:40,849 --> 00:17:44,726 Now, if I have lots of items per batch 460 00:17:44,726 --> 00:17:46,831 I don't have to have very many transactions. 461 00:17:46,831 --> 00:17:48,376 Let me use a physical example. 462 00:17:48,376 --> 00:17:51,871 I'm kitting fenders for a manufacturing plant. 463 00:17:51,871 --> 00:17:54,657 Fenders for a whatever, an SUV. 464 00:17:54,657 --> 00:17:59,542 If I kit a big blob of them I only have to count them once. 465 00:17:59,542 --> 00:18:01,577 And I only have to move them on the pallets once. 466 00:18:01,577 --> 00:18:04,759 If I kit a small blob of them well, 467 00:18:04,759 --> 00:18:05,741 I have to count them five times. 468 00:18:05,741 --> 00:18:07,105 So I have five transactions. 469 00:18:07,105 --> 00:18:09,817 So what happens is the transaction cost goes down 470 00:18:09,817 --> 00:18:10,935 as the items per batch goes up. 471 00:18:10,935 --> 00:18:12,696 Kinda makes sense. 472 00:18:12,696 --> 00:18:15,804 However, the other side of that right? 473 00:18:15,804 --> 00:18:18,154 Which is the holding cost goes the other way. 474 00:18:18,154 --> 00:18:20,266 Because if I put a hundred fenders out there 475 00:18:20,266 --> 00:18:21,203 it's quite a holding cost. 476 00:18:21,203 --> 00:18:24,364 I have to move them around, if I decide I need a 477 00:18:24,364 --> 00:18:26,548 different type of fender I have to get them out of there, 478 00:18:26,548 --> 00:18:27,959 I have to get them in and out of the paint shop. 479 00:18:27,959 --> 00:18:29,086 The holding cost is really high. 480 00:18:29,086 --> 00:18:32,320 Now the same is true for our software features. 481 00:18:32,320 --> 00:18:34,278 If I have a really big batch of software features 482 00:18:34,278 --> 00:18:36,819 like requirements holding cost goes up with batch size. 483 00:18:36,819 --> 00:18:38,713 But it goes down as the batch sizes gets smaller. 484 00:18:38,713 --> 00:18:40,050 So it's problem. 485 00:18:40,050 --> 00:18:41,653 There's two counter veiling trends. 486 00:18:41,653 --> 00:18:44,097 So the answer occurs in the middle. 487 00:18:44,097 --> 00:18:46,037 We want the optimum batch size. 488 00:18:46,037 --> 00:18:49,326 Not one penny or ten necessarily, we want the right number. 489 00:18:49,326 --> 00:18:50,159 This can vary. 490 00:18:50,159 --> 00:18:52,917 For example, if we're reviewing articles, 491 00:18:52,917 --> 00:18:55,973 we've got a tech editor going through articles, 492 00:18:55,973 --> 00:19:00,586 and the resource to review the article has limited 493 00:19:00,586 --> 00:19:04,737 capacity then a single article is a really tough batch 494 00:19:04,737 --> 00:19:05,739 because there's overhead. 495 00:19:05,739 --> 00:19:07,297 So let's just same I'm that reviewer. 496 00:19:07,297 --> 00:19:09,357 So the tech editor produces an article, 497 00:19:09,357 --> 00:19:10,753 and they go this article is ready. 498 00:19:10,753 --> 00:19:12,471 Okay I have to stop and contact switch 499 00:19:12,471 --> 00:19:14,745 and I have to go fix the article. 500 00:19:14,745 --> 00:19:16,456 So it's not necessarily one. 501 00:19:16,456 --> 00:19:18,470 But if the tech editor said I have finished 502 00:19:18,470 --> 00:19:22,156 three articles then I could do a contact switch 503 00:19:22,156 --> 00:19:23,806 and spend maybe a couple of hours instead of 504 00:19:23,806 --> 00:19:25,586 twenty minutes each and that's more efficient. 505 00:19:25,586 --> 00:19:28,199 So the optimum batch size is not one, 506 00:19:28,199 --> 00:19:31,114 it's some number determined by your process. 507 00:19:31,114 --> 00:19:35,329 Now as we start to think about releaseability of solutions, 508 00:19:35,329 --> 00:19:37,711 what we want to think about is that transaction cost. 509 00:19:37,711 --> 00:19:39,723 That transaction cost is a killer. 510 00:19:39,723 --> 00:19:41,866 So let's assume that I'm in a traditional kind 511 00:19:41,866 --> 00:19:44,556 of stage gated development model or even an 512 00:19:44,556 --> 00:19:48,598 agile model that hits a high transaction cost deployment. 513 00:19:48,598 --> 00:19:50,050 Before we put this into production 514 00:19:50,050 --> 00:19:51,721 it's gonna affect 600,000 users, 515 00:19:51,721 --> 00:19:53,899 the data schemas have to be proven, 516 00:19:53,899 --> 00:19:56,011 all the security protocols have to be checked, 517 00:19:56,011 --> 00:19:57,420 we have to rebuild all the servers, 518 00:19:57,420 --> 00:19:58,655 we have to deploy the software, 519 00:19:58,655 --> 00:20:00,613 we have run rep-- 520 00:20:00,613 --> 00:20:01,446 You've seen it. 521 00:20:01,446 --> 00:20:03,874 I've seen a 300 page, literally, a 300 page book 522 00:20:03,874 --> 00:20:06,066 of here's what it takes to release a new 523 00:20:06,066 --> 00:20:07,805 piece of code into production. 524 00:20:07,805 --> 00:20:11,403 So long as that exists I'm gonna have to have a big batch. 525 00:20:11,403 --> 00:20:13,435 But if I could reduce the cost of that, 526 00:20:13,435 --> 00:20:15,145 I could have a much smaller batch. 527 00:20:15,145 --> 00:20:16,502 Because I could then efficiently 528 00:20:16,502 --> 00:20:18,228 move through a smaller batch. 529 00:20:18,228 --> 00:20:19,949 So if you just look at this and say 530 00:20:19,949 --> 00:20:22,211 what happens if I can reduce the batch cost 531 00:20:22,211 --> 00:20:23,507 even if the holding cost doesn't change? 532 00:20:23,507 --> 00:20:24,673 Well guess what? 533 00:20:24,673 --> 00:20:26,799 I can reduce the batch size. 534 00:20:26,799 --> 00:20:29,895 And smaller batches go through the system faster. 535 00:20:29,895 --> 00:20:31,384 Increased predictability, faster 536 00:20:31,384 --> 00:20:33,383 feedback and lowers the cost. 537 00:20:33,383 --> 00:20:35,804 So I need to reduce the transaction cost of 538 00:20:35,804 --> 00:20:38,763 deployment to reduce the batch size that 539 00:20:38,763 --> 00:20:40,497 I'm sending through to deploy. 540 00:20:40,497 --> 00:20:43,220 Awe, that's continuous delivery in dev ops 101. 541 00:20:43,220 --> 00:20:45,090 And we're gonna talk about that a little bit later. 542 00:20:45,090 --> 00:20:47,342 But we're ironing some points out again and again, 543 00:20:47,342 --> 00:20:50,522 and I couldn't' agree more, the batch size reduction 544 00:20:50,522 --> 00:20:53,107 probably saves twice what you think. 545 00:20:53,107 --> 00:20:56,687 If I was reviewing 15 articles way too many, 546 00:20:56,687 --> 00:20:58,200 I reduce it to seven it's probably 547 00:20:58,200 --> 00:20:59,645 gonna save even more than I thought. 548 00:20:59,645 --> 00:21:03,014 When I get to one the transaction costs kick up 549 00:21:03,014 --> 00:21:05,718 because I have to open the document and do that each time. 550 00:21:05,718 --> 00:21:07,176 So thinking about batch size is not 551 00:21:07,176 --> 00:21:10,009 identically equal to single piece flow. 552 00:21:10,009 --> 00:21:11,326 That's kind of an ideal goal. 553 00:21:11,326 --> 00:21:12,685 And you can do that if there are no 554 00:21:12,685 --> 00:21:14,723 switching contacts or no transaction costs. 555 00:21:14,723 --> 00:21:17,263 Batch size reduction probably saves twice what you think. 556 00:21:17,263 --> 00:21:18,824 And if you wanna see a fun video, 557 00:21:18,824 --> 00:21:21,015 take a quick second here, watch this little 558 00:21:21,015 --> 00:21:23,962 formula one video and see about transaction costs 559 00:21:23,962 --> 00:21:25,425 for formula one racing. 560 00:21:25,425 --> 00:21:27,298 As a matter of fact, stop and do that now, 561 00:21:27,298 --> 00:21:30,846 cause I wanna talk to you about that a little bit. 562 00:21:30,846 --> 00:21:32,821 Wasn't that cool? 563 00:21:32,821 --> 00:21:36,101 Now I have a question, do you think that car was 564 00:21:36,101 --> 00:21:40,268 optimized to reduce that transaction cost of the pit stop? 565 00:21:41,354 --> 00:21:42,490 Absolutely. 566 00:21:42,490 --> 00:21:46,088 So the car was designed in such a way that they 567 00:21:46,088 --> 00:21:47,551 could reduce that transaction cost. 568 00:21:47,551 --> 00:21:49,907 What does that tell us about our systems, 569 00:21:49,907 --> 00:21:52,110 our releases on our solutions? 570 00:21:52,110 --> 00:21:53,974 They're gonna have to be designed in such a way 571 00:21:53,974 --> 00:21:56,676 as to reduce that transaction cost.