GA 418 | Value Stream Management in Software Delivery with Lance Knight

So map it, understand your flow and remove waste. It's that simple. You don't have to go so far into solving the whole thing. Map it, find an area and solve the problem and remove that waste, and you'll start to get momentum around it.

Today, I'm excited to welcome Lance Knight to the show. Now, Lance works for an organization called Connect all, and they are a value stream management software company that is focused in the software world, software delivery. And so today, what we talk about was sort of the way that value stream management kind of works in their world and their approach to it. And what's interesting is Lance does have some background in manufacturing and understands kind of traditional value stream management from a manufacturing perspective. And so he's able to sort of kind of bounce back and forth between software and manufacturing. So it was a really interesting conversation. So even if you aren't in the software world, I think it's important that we listen to how other folks in other industries and other spaces are going about making things better. In fact, towards the end of the podcast, we talked about that very thing, you know, about how we can all learn from one another even if we don't do the exact same thing. So I think you're gonna find some value in this no matter what kind of work you do. All right, show notes can be found over@gembapodcast.com this is episode 418, so go to gembapodcast.com look for episode 4 18. Okay, enough from me. Let's get to the show. Lance, welcome to the show. How are you?

I am great. So great to be here with you. And I appreciate all the great work you've done.

Yeah.

Here with your academy.

Well, I appreciate that. I appreciate that. All right. I'm excited to have you on. So, as you know, Lance, we do like to get things going with our guests sharing a quote. So do you have one?

You know, I have so many, but I think the one I talk a lot about is a Peter Drucker quote that says the best way to predict the future is to create it.

I like it. I like it. Especially in these crazy times, man. You know, we just got to go out there and get after it. So.

Yeah, absolutely.

Wonderful.

I have more of his quotes I like a lot, too. Like, you can't measure. You're not managing something if you're not measuring it.

Yep, yep, exactly. Good stuff. Well, hey, man, before we talk about the company that you work at, Connect all, tell us a little bit about yourself. Tell us about your background and how you first got involved in all this kind of work and then maybe lead into what you guys are up to at Connect All.

Well, you know, I always say it like this, you know, how did I get into software development delivery? You know, as a young man I started programming Commodore 64 in the early 80s and it's kind of led from there. And leaving college I went right into manufacturing in upstate New York for a company called Utica Drop Forge and they made turbine blades and I worked with them for a while, heat treat. And that's where I started learning about Lean and systems thinking and all of those different principles that we're going to talk a little bit about today. And a lot of my mission lately over the last years has been how do I help implement those principles into software development delivery and how do we really transform them the right way? I know a lot of companies have tried but they miss out some fundamentals that, that you understand. And I have an understanding of from walking a shop floor, you know, actually going and doing a Kaizen and understanding what that's all about. And I see as, you know, so anyway, that's my background is a lot of software development, delivery, requirements management. And now today I run a leading value stream management company.

Got it, got it. So you do have sort of a traditional lean background as well, in addition to software or.

Okay, yeah, yeah, I started it on the shop floor, you know, putting in computers as part of IT is and setting up emails and doing databases and coding in those languages. And a lot of times I include the IT guy, IT person in those types of events because you know, there's always data entry.

Yeah.

I've got so many great stories I've talked about back then around trying to improve something happening in a cell, but an old corrective action gets in the way.

Yeah.

So I'm like, well, let's change the corrective action. Right. So I got all those great stories from back then.

Very cool, very cool. So, so obviously you guys are focused on value stream management in the software world. So we talk about software delivery. I mean real basic question, but like what do you, what do we mean when we say software delivery? You know, like, let's start there.

Well, I mean software delivery is pretty straightforward. It's, you know, we put everything together, we put it on a server so people can use it and there's a lot of steps into place. We put it into a package and you download it and you install it. That's high level software delivery. And there's other pieces that go along with it, like the quality steps and the different pieces that you go through it. And software development is that process of requirements gathering, putting all that together, breaking that down into things like agile software delivery, which is really, you know, all of this, all of this is really doing things in a lean way and adopting some lean principles. But software delivery really is just that. It's taking the code that somebody's written, putting it in a package, compiling it, doing what we need to do to give it to you.

Got it.

I'll take one of your terms to the waiting arms of the customer.

Yeah. Nice. I like it, I like it. Well, talk a little bit about a typical value stream in the software delivery world. Like what does that look like?

Well, man, that's an interesting thing to come and talk to me about because I have an opinion on this and it's, it's kind of fascinating when you think about a software delivery value stream, they're not like value streams in manufacturing. You know, when I, when I was in manufacturing, value streams are designed, right. I know the cells I need and I know what goes into that cell. And every time it's the same thing. And I move through those. Software development. These value streams are very similar in each company and of course they're interweave weaving and all of that. But it's usually the same thing idea to cash the same steps, both value added and non value added steps. But what's interesting is they've grown up more organically in most organizations than they have been designed. Right. So when I wrote software for manufacturing, there wasn't really a value stream. Somebody said I wanted this software and I done it. Well, it is a value stream in a way. But I would start coding. Yeah. And I'd report to the CFO and I wasn't so thought of. You know, it was important, but it was more of a cost center, not such an important aspect to an organization today as it is as everybody's going through digital transformations. So a typical value stream is some type of work intake which can come from any varied pieces of the business that go through a portfolio planning exercise. Sometimes that gets broken down into different delivery teams and then it comes back together to go through a dev and operational team that takes all that, puts it together and then puts it into the hands of the customer, either through a SaaS offering or something you download.

Got it, got it. So talk about. So obviously you've got an understanding of what when a traditional lean thinker that's running around a factory and they're creating current state, future state, value Stream maps and material and information flow diagrams, that sort of thing. Talk about the differences and perhaps even the similarities between that and what you guys are doing in the software world.

Well, so let's think about it like this. Let's talk about how it happens in a manufacturing world. And I think you've got a great more breadth than I do on this, so. But it's pretty straightforward. When I was in making turbine blades, I always talk about that raw material, titanium, Titanium rods came in one door, went through their various cells, they got extruded it it then that would then go on to the different cells. And of course sometimes that would wait in the inventory and be pulled out and pushed through. Right. You'd have grind and different test points and all of that. That was pretty constant. And out the other side, whatever ran whatever batch of size turbine blades we needed to for whatever order we got from either aircraft or power generation. And that's typically how, you know, soft. I'm sorry, that's how manufacturing happens.

Right.

And so it's designed like you're designing your value stream, you're designing your cells, you're understanding how you're going to push and pull, mostly push. And even the word kanban is different, I think in between manufacturing compared to software delivery. Unless you've walked the shop floor before, you don't really know. Right. Right now, software, software development delivery, the batch size is never the same. It's a project, it's a product, it's an enhancement, it's a feature, something somebody has to do. That batch size that comes in, whatever that is of things are not always the same. That same size, you know, one might be something that takes a requirement or an enhancement that takes two seconds to do. The next one might take hours to do and require different types of cells to deliver against it. So as the world is trying to transform some of these lean principles in the software development delivery, they're getting mixed up. I think on this point it's not the same. Right. When I was in manufacturing titanium in one door, went around the shop floor, went out as turbine blades on the other end. This is an idea comes in an initiative, an enhancement goes in one place, is well vetted out by a team of portfolio people might take four different teams against two different values, two different connected value streams, let's say, to deliver. So as we're starting to adopt these principles, we're using words like cycle time. And I like cycle time. But how do you really understand cycle time when your batch sizes are always different and the things at the top are always prioritized up and down. So in Agile there's something called a backlog and the backlog is prioritized up and down. So the things that are important always make it to the top. But those things that have been sitting in your backlog forever never get prioritized. That makes the whole thought of trying to say that I have a measurable cycle time not really effective, or even that wait time has such level of variability. It's really an interesting point of view I have. I always say that cycle time is kind of a feckless metric in software delivery. What can I learn from it if I'm including the wait time and the backlog?

Right, right, right. So like in manufacturing, you know, really good lean thinking companies are obsessed with like just flow, right. Making sure material and information is flowing smoothly and consistently and into a certain rhythm or cadence. Tact. Tact time in most cases. Right. In a manufacturing environment. So what's the relationship with say something like the concept of flow in the software delivery kind of world? Are you still, are you thinking about that as well?

Yeah, I mean that there, this market we're in, Value stream management is all about that word flow. And I, I think it's really, I think it's something to embrace, but it's not the same as you would think in manufacturing because of the time. I understand what flow is in manufacturing. Right. It's, it's different.

Right.

A project or something comes. So you, you can't measure one piece going through the shop and saying this is my time.

Right, right.

And you could do that a little bit in manufacturing. Do want to do a couple. Right. Just to understand. But you can't do that in software delivery. How do you do that?

Right.

It's like, it's all different and what I break down may be different. And at the end of the day in manufacturing, it's usually a repetitive thing. I'm putting the same thing out. Yeah, that's not true in software.

When you think about your, your product connect all like, like what problem are you trying to solve with your value stream management approach? Your, your product, your software. And I don't mean for like a sales pitch perspective, but, but like, like what, what problem are you trying to solve by value stream management in the software world?

Well, first let me frame this up and this is kind of our credo in this world compared to others. And I know you're going to agree with what I'm about to say. Value stream management, it's a human thing to do. There's no software that does it. Right. We have to go out to the shop floor. We have to go look, we have to go see where things are flowing. We have to look at the flow of things and try to figure out how I can remove waste, how I can automate, how I can do all of those other Japanese words in the house of lean that I can't stay half the time. Right, Right. That's a human thing to do. Software is not going to do that for you. Our software is a value stream management platform to help humans as they're doing these exercises and understanding how they can improve flow to see, measure and automate their software delivery. Value stream, unlike the shaft floor, also in software development, I can't go to Gemba. Did I say that right? I think I said that right.

Yeah.

I can't go to the shop floor. Right. I can't do that because it's all in somebody's computer or servers or somewhere in the cloud. So I have to be able to map it. You have to be able to map it. You have to map it without seeing it. You have to ask questions and drive connections and talk about the tools you're using. Right. The concept of cells aren't the same. You know, using cells and managing material through cells. Right. You don't do that in software development, delivery. So what does our software do? I answer that question for you. Well, we help customers see, measure and automate. We help them map the value stream from a software perspective. We capture the analytics and metrics in averages and so on to help them understand their flow through that. And we use more averages because it's really difficult. Even though we can capture the data. How accurate is that number? Right. So we have a suite of flow metrics that people can capture with our software, harvest information from the solutions they use. Then we help companies automate either by integrating the tools to remove waste. I think it's more like transportation waste in manufacturing, where I'm taking information from one computer and then keying it over into another.

Right.

See their movement or transfer, maybe that's movement waste, I don't know which one, but it's one of those. And so we help remove that and then also automation. So as you're looking at moving parts that you've put together in the delivery process or so on, we can trigger systems to do things so that people don't have to do that. And that's removing, I call that moving non value added activities. It's not valuable for somebody to copy tickets around. Yeah, right. You know, it's not a value added activity. And then we help with feedback loops too through the development process. Right. So say we've got feedback loops in production where there's a tool monitoring security. That feedback loop can come right back to the person that needs to not sit and wait for somebody to rekey it. So automating, triggering bills, triggering tests, trying to move more of the testing and all of that into the development phase in the guise of removing defects, removing defect, waste. So that's what we do. C measure and automate and that's what our value stream management platform does.

Got it, got it.

Kind of like the railroad control center of everything, you know.

I know you have some folks in your organization with a lot of agile background and experience. So what's the connection, if any, to say, I don't know, Scrum, Kanban, Agile, Kanban, that world.

Yeah. So there's a big connection. And here's where I differ from I think some of my competitors and people also in the space. I look at those things as design things you put in place to improve your value Stream. The value Stream to me is the first thing. So when you think about it, I'm laying out my value stream and I'm making decide, okay, this team's going to work in a Kanban way and this is why, because it gives me better flow. Right. This team is going to work in a two week sprint Agile way. We'll put Scrum in here. That's more important. So when you're designing your value stream, develop software, you think about it in that way. So to me, from my perspective, I think of those of things that are service to a design value stream.

Yeah. And I tend to agree. I would say your value stream is your scoreboard, if you will and Scrum and come on and just do it, whatever. You know, that's how we're playing the game. Right. We're trying to get better and win. Right. And we win by yeah, monitoring our value stream. So yeah, yeah, good.

Whatever technique you need. Like in, in cells. Right. So you know this, this is my Kanban cell. I'm trying to go probably too far over to manufacturing. I get in trouble by that a lot of ways. I don't want you manufacturing people telling us how to do this. So I get that every once in a while. But I really think that software development delivery can really use the techniques of systems thinking and lean thinking because they have an organic thing that they have to organize now.

Right, right. Hey, do you have any examples? I'd be Curious to hear maybe a story of, of a transformation that you've, you've seen or maybe you've been a part of. Like, almost like, what was it like at the beginning? What did you do? What did you mess up along the way and what did you learn and then, and then how did it turn out in the end?

Well, I've messed up a lot along the way, so I'll mention the box. Yeah. So, you know, I worked for a consulting company. We were implementing Agile and Lean practices before I came to connect all and connect all. You know, we support a lot of those agile transformations and digital transformations with our consulting partners. Now, one of the things I notice when trying to transform an organization to think more lean and system thinking is there's always this thing that's in the way and how do you move that rock? Right. It's not always people, it's not always process. It's always something. One thing. So back when I was in manufacturing, we were redeploying an ERP system and it didn't have the F4 key to run the printer. Now this is aging me, right? The dot matrix printer that printed out the checks, right? Yeah. And they said, well, I want my F4 key. Well, no, you use your mouse, you click the button now and it's those things. And then also a lot of the, a lot of lack of understanding is understanding little's law a little bit from the people who are trying to transform. What do you mean? If I give them less, they'll get more done. You've heard that, right?

Yeah. Right.

If I remove wip, I'll get more done. Yep, I've seen that a lot too. So those are the things I've seen. But then when they start to realize that if I put things in smaller batch sizes, I remove wip, I do this, I have higher quality, less change velocity and all of that. That's something that transforms software development delivery very well. But it's just the thought of having to adopt these things and really understanding from an executive perspective that removing this waste is important. Each company's different. When I've done these, I just love that one of if I do less, I'll get more. If I remove what they need to do, I'll get more done. Yeah, you will, because they'll get it. It's an interesting point of view. And also the other one too is when you start to transform an organization around Lean, you're creating different units of things to do. That also makes them more efficient and effective. Rather than having teams that can be interrupted in their work by other things. I'm relaying to the fact that you can have a backlog of things and if you're kind of half done with something, you start something new in broken up teams that can create all these different issues when they're not focused on done. The word is done that I'm getting to anyway. I know I jumbled around on that a little bit because it's those main concepts that are always challenging. Little's law, organizing around products and teams rather than being project based for it.

Right, right, got it, got it.

Manufacturing is not project based. Right. It's this is the product we're going to make and we're going to organize our value streams around it.

Hey, I'm wondering if maybe as we wrap things up, maybe you give some practical advice for folks that are in that software world or it'd be interesting to even hear. You know, you're obviously borrowing from the manufacturing space whenever it makes sense. But like maybe what advice do you have for the manufacturers listening that the software community has kind of figured out that the manufacturing folks haven't. You know what I'm saying? Like that might be some interesting.

I've never spun that. Yeah, yeah. I've never spun that.

Like what are you guys doing that manufacturing folks aren't?

Yeah. So but first on the, on the software side of getting going with this, you know, it's like anything in software and I've been on a couple speaking slots on this and it's. My point of view is a little contrarian but value stream management in software development delivery forever is. Listening to this is not this complicated. It's not. I don't need to create a community. I don't need to. It's not part of my agile processes. Right? It is. Your value stream is. It's always there. It's just. And you're managing it now even if you don't call it that. So map it, understand your flow and remove waste. It's that simple. You don't have to go so far into solving the whole thing. Map it, find an area and solve the problem and remove that waste and you'll start to get momentum around it. You don't need to add it to your scrums. It's not. You don't really talk too much about it in your daily stand ups a little bit. Unless that's what the standup's about. Mm, just get to it is. Guess what I'm trying to say, right? Yeah. Map it, look at it, understand it. Find waste and remove it. Yep. And measure, Right?

Yeah.

Because like I said earlier, you can't manage something till you've measured it. Now on the other side, for going from software development to manufacturing, that's a tough one because here's why. This stuff we're talking about, Lean, Kanban, all of those things have been around for so long and we're still in software development delivery trying to figure out how we apply these principles. Systems thinking isn't so hard, but it's really the how do I apply these principles? How do I design a software delivery value stream to remove the most waste and be more efficient so I really don't have one that I can push back. That's a great thought for me to go ponder on for the next day.

Well, I'll throw one out there like my perception, you know, I'm not an expert in the software space by any means, but even just listening to you, I mean one thing that I sense within the manufacturing community, sometimes we feel like, you know, we've got it all figured out, you know, and we know what to do and leave us alone kind of thing. And I think that sometimes I see this a lot with say healthcare. You know, people in, within manufacturing will go into healthcare and then they'll, they'll take a lot of the same things but then it might be like in healthier they might be doing, showing more empathy or something like that. Right. Like that might be more natural. Whereas in manufacturing is like empathy, man, we got time for empathy, you know? You know what I mean? So I feel like within the software world, well you in particular, you know, you seem super open and, and humble, you know, to, to learn. And so that's my advice for everyone whether you're manufacturing or not is just don't act like you know it all man, you know, and keep learning and keep exploring and see how other and try to truly understand, hey, what are these software folks up to? You, what are they doing? Because there might be just some little nuggets in there that you might be able to borrow. Air quoting borrow. Right. You know, and, and, and, and make your own, your own process better. So I don't know, just I think we should all learn from one another and you know, and I think the world would be a lot better if we did that and we had that attitude.

Well, I agree with that wholeheartedly. Right. I mean the older I get and the more I realize, I know to realize I don't know anything.

Yeah.

So when you think about it, even managing things in this Way from a manufacturing process like they do in software, you may be able to bring some of those practices to the front office. How? Some of the practices of working in Kanbans. Right. Kanban on manufacturing is different than a software Kanban.

Yeah. Right.

And most people don't realize, oh, we're managing with Kanbans. Well, that's not the same. Right, right, right, right, right. I'm not looking for parts in my Kanban, so. And it's not just in time Kanbans. Right. I don't know. So, yeah, I completely agree that there's. There's all places to apply Lean and Systems thinking.

Yeah.

Even in your family life. I mean, I experimented one day with a Kanban board here at home and tasks for the, for the kids to do is funny. One son took all the like, took like five tasks that were really small and did them. I got these.

Yeah.

Like, no, no, this is how it works. You got to finish one first.

Yeah. Done means it's done, son. Yeah.

Yeah. Right. I gave him a lot of. Because he was like 10.

Okay. So, yeah. That's awesome. That's awesome. Well, good stuff, man. Well, hey, what's the best way for folks to. To connect with you, Lance? And then. And then also for connect all.

Hey, you know, I'm, I'm al knight@connectall.com and I'm all over LinkedIn. You can find me there. And at Connect all, it's, you know, send a note to salesconnectall.com we'd be happy to talk about how we can empower humans to be better at value stream management.

Got it. And we'll Link your. Your LinkedIn and everything else in the show notes. So this is episode 418. So gembapodcast.com look for episode 418. But hey, man, Lance, this has been fun. I appreciate you coming on. And it's always fun to just talk about, you know, continuous improvement in different spaces and sounds like you guys are doing some great work, so. So keep it it up.

Well, I appreciate all of the stuff that you do with the videos. I mean, I learned a lot from those through the years. Great as well.

Thank you. All right, well, take care. Thanks for listening. Whether you've been on the continuous improvement journey for many years or perhaps you're just getting started, Gemba Academy is here to support you. And while we're best known for our more than 1500 lean and 6 Sigma teaching and virtual tour videos, we also have a team of experienced Lean and Six Sigma practitioners available for one on one coaching, as well as a variety of Lean and Six Sigma certification options. To learn more and to schedule a demo, head on over to gembaacademy.com.