David: Okay. Hello everybody. Dave Rubinstein, again, here with an SD Times live micro webinar. This is the third in a series of micro webinars we've been doing with a value stream management solution provider ConnectALL. We have talked about the difference between value stream management and a value stream. We've talked about how to make your value streams flow and how you can start to see your value stream today. We're going to be taking on the topic of the surprising reality about bottlenecks and where you can find them. And we'll give you a couple of different perspectives on it. So, with us here today is Lance Knight. He is President and COO of ConnectALL and Andrew Fuqua, who's Senior Vice President of Products. So Lance, why don't you kick it off?

Lance: Yeah. Hey, you know, we decided to do these micro webinars and we were struggling with maybe doing something bigger on metrics, and we decided to kind of go into some specific metrics that Andrew has set up. We're going to go through how important those are. So I'm just going to show you the bottleneck metric that we look at, and we're going to have a five minute discussion on how you can use it to, you know,  remove those bottlenecks or to figure out how to improve your value stream.

Andrew: Cool. so while I start sharing my screen, Lance, can you like, from a manufacturing perspective, how do you spot a bottleneck and a manufacturing environment? How does it show up?

Lance: Well, it shows up in a lot of different ways. Mostly it's going to be in the beginning of a cell where you'll see inventory stacking up, that's there to be pulled, right? So when things are moving through the value stream in manufacturing, you'll see where, you know, from my example, a lot of turbine blade would stack up in the front of a cell where they had to go through a process or, in that process was slowing down the value stream or the flow of those parts through manufacturing,

Andrew: Or maybe work, downstream activities may be starved for work. Kind of depends on somebody using takt time and you've got everything balanced or whether you have a pull system or drum buffer rope or all that kind of stuff.

Lance: Yeah. So if you're moving through and you're taking those things through these different cells, you'll notice that one cell isn't working right or producing right. Or there's not enough stuff coming into that cell for them to pull against,

Andrew: But in software you don't have piles of physical stuff. You might have piles of story, particularly like if you have scrum, the QA people might be idle at the beginning of the sprint and overloaded at the end where the developers might be idle. So that's the problem. One of the problems with cycle time and software development is, as you like to say, it's a feckless metric because the bottleneck moves around or cycle times move around, the world is not all the same size.

Lance: Yeah. And my other point of view is that unlike manufacturing, you're not pushing the same thing through,

Andrew: Right.

Lance: It's all different work. And what then tends to happen is the stuff that's of higher priority gets an executive or somebody to push it through or a sales thing. So some of those lower priority things get pushed down into the, into the backlog and they sit there and prioritized, even if they have greater business value. So that's why I look at, you know, if you look at cycle time, end to end in a particular deployment, value stream, it seems not to give me any value because of the way things get pushed and prioritized through.

Andrew: Nevertheless, there is still that kind of concept in software of things, might go through a particular stage too slow or take too long and a particular step in a process. And so this kind of notion or concept of a bottleneck or a cycle time in a state can still be useful to dig into your value stream or to a process and look for improvements. Well, what you, I think I'm sharing my screen here. What you normally see in multiple tools is a chart like this. It's basically just the average cycle time for each state. And so Lance, if I showed, you know, a typical person is what, what might the typical person think the problem is? where's their eye going to be drawn to?

Lance: You're putting me right on the spot here. I love it.

Andrew: I put you on the spot.

Lance: So, of course it's going to be testing and deferred.

Andrew: It’s going to be the big red bars. These graphs are designed to draw your eye to the big red bar. Right? Well, the problem with this, and that's kind of the point of this webinar, is that this is really misleading. And I'll tell you why. The same data I have graphed in another way, let me show it to you right here. That testing deferred is 2.2 weeks. So it's about 15 days and in this next chart, I've got the count of tickets on the Y axis and the duration on the x-axis. So if I find that 15 days and I look, and I see worst testing deferred, well, testing deferred is right here, 15 days, but it's only eight tickets,

Lance: Eight

Andrew: Tickets out of hundreds. The real problem might be up here at the top, approved. 14 days, 192 are in progress. Four days 164, tickets are QA, 159 tickets, three days. So this other chart is really, really misleading. And that's, the flaw of metrics is that when you're using averages, you lose a lot of information. So this visualization is much more helpful than the one above. Now, what you could do is instead of showing the average time in state, you could show the total time and state that's a little bit better, but it's still, it can still be misleading for similar reasons. You're still hiding information. So, you know, a lot of tools do this, but it's, but it's a failure mode. That's why I wanted to highlight it today. Another thing that I like to show in my tool, the way I have them set up is, this box plot. It's the same data, but I can actually see the range of these states.

And I can see that some of these tapes have a really big range and a lot of outliers. So I might want to go dig into the outliers and see, is this the same set of outliers in all of these states? Are they different? And I might want to take a look at the state that has the biggest variation and try to knock off some of that common cause variation. The next thing I want to do, and I'm just being brief for the interest of time, is from there I would go dig into my cumulative flow diagram. I would look at each of these states over time and see, well, here's the big fat bar. What's the cause of that? Why did it get narrow? That's good, but what was the cause of that? Can, can we learn from that? And is this approved? Is that a problem or is the process working appropriately? So, bottlenecks in these kinds of graphs are, are useful, and much better than an over-simplistic kind of chart that you often see, which could be misleading. So that was my spill on bottlenecks.

Lance: Well, I kind of drove a little bit of my, or supported, a little bit of my point of view, the way you make for me, the way you make cycle time effective as you reduce whip in your backlog.

Andrew: That's right.

Lance: And you deliver it in chunks and make sure that they're prioritized right.

Andrew: Yeah. Deliver often small batches.

Lance: Yep. So I think that, that was a great understanding. I know more about that now, Dave, don't you?

David: I absolutely know more about that. And that's really interesting. We had talked about the hidden data that you're not seeing in the bar graphs. But then when you drill down, it may not be as things appear. So Yeah, I think those are  really excellent points.

Lance: Yeah. Well, that's some good takeaway as you're, as people are looking at these metrics and graphs to improve their value stream, you know, there's some good feedback there of understanding, you know, it's easy to go map your value stream is what I say a lot, but it's understanding what you're mapping and how to improve it by using the right information to affect change in your transformations.

David: Right. So when you talk about seeing the value stream, this is one of the things that you're talking about, being able to drill down and actually see what's happening, beyond what some, feckless metrics may be showing you?

Lance: Absolutely. Yes. You know,  it absolutely is that. It's like, I can see the data that's flowing. I can see the tools, I can see the value stream and then I can find and remove waste. Like, apparently I would go right after understanding why does it take, you know, all that much time to get something approved. And then you look at that and then you say, is there a way we can automate that, and use the value stream management platform to do that. And in lean, there's actually a word for automating and I forgot what it is. Do you remember it, Andrew? It begins with a J U, I believe.

Andrew: Not high heijunka. I don't remember that one.

Lance: Nope. See, I tried to put you on the spot for that. 

Andrew: You did put me on the spot,

Lance: But it's a jidoka, or something like that. I'm sorry if I don't remember the word, but, you know, and then, you know, go to figure it out. So it's a Gemba thing. Right? So, anyway, hopefully everybody will learn a little bit from that. I don't know if there's any questions or not Dave, but actually we're about all the time.

David: Yes, we were right up against it. It's the beauty of a micro webinar. So thanks for being with us today, folks. I hope you learned a little bit, I know I did. Again, thank you, Lance Knight and Andrew Fuqua of ConnectALL for sharing that with us. And until next time again, I'm Dave Rubinstein. Editor-in-chief, SD Times. So long for now.