What is ”waste” in software development? With Steve Pereira

Episode 278 · Mon, 18 Dec 2023 08:38:00 +0100 · 51:47 · SRT · archive.org · all Tanzu Talk

Well, you write a lot about value streams and the old software process and things like that. And I was, as I was reading through a lot of your systems, your systems, as I was reading through a lot of your stuff, I was thinking, this is going to be a great opportunity to get someone to extensively discuss the concept of waste, which I think is just like, it's just like a very, like, it seems, you know, to do the very short version, it seems like even to try to be overly clever, it seems like activities that people don't want to do that don't really add very much value to whatever goal they have. That's very vague and whatever. But like, I feel like, especially when it comes to using software to do whatever, right? Like, like more so, more so than just like developing the software. Zoom further out, Coté. Yeah, yeah, yeah, exactly. You know, not, you need to specific, not, not just like, not just like writing the software or deploying the software, but like any process that you have that depends on your own software to operate, right? Like, it seems like there's a lot to be said about what waste is. And, and then before, before I hand it over to ask you, you know, what waste is, it seems like, I know this isn't accurate, but it seems like if there was like one to three things you would choose to focus on to make things better, waste would be one of them. I don't know what the other two potentially are, but it seems like, it seems like the thing, you know, you could, I, I always like to discard software must work. Like that's always, it's, it's actually needs to function. So there's that. Uh, but like, as far as other things, like it seems, uh, I don't know, it seems very high up there. So all of that said, what, what exactly is waste in this concept? Well, it's, it's interesting. Cause like, yes, it, it certainly encompasses stuff that you don't want to do if that stuff

doesn't add value, because a lot of things that are really valuable, we still don't want to do them. Yeah. As I was saying that I was thinking that's not the right criteria. The other thing is like, one of the things I will say, like my first encounter with, I think the most consequential waste is when I was an engineer and I was working on stuff that I thought was super important and I'm struggling away in, you know, in isolation, cause I didn't want to share the fact that I hadn't made progress and I was struggling. And this is like, I'm trying to, I'm trying to stand up like configuration management in a, in a fast moving startup. And, um, and I, you know, I didn't realize that I was just wasting all of my time and I wasn't doing anything that was ultimately delivering values of the organization. Cause the engineers that I was building this automation for were fine with the thing that they were doing. They knew it, it was comfortable. They knew the failure modes. They knew how to fix it when it broke. And I was trying to build this new shiny gold plated system that would remove all the, you know, from my perspective, waste and toil in the system and build something that was more resilient and scalable. And no, the delay between picking that goal and going to work and delivering, ultimately delivering something to the organization meant that I'd like departed from any kind of customer value from, from the organization's perspective. Right. My customer was the developers in, in the company.

And so I had this like reconciliation moment where I was like, here's what I've got. It's not perfect, but it does X, Y, Z. And at no point had I talked to one of these engineers. I hadn't sat shoulder to shoulder with them. I hadn't presented a plan. I just kind of went to work. Cause I was like, I know what's valuable. I know what everybody needs. I know what I need. And so the waste in that context was just doing the wrong thing. And I could have been doing it the right way, but I was like running in the wrong direction. And, you know, my, my lack of success was actually. Like less consequential than if I delivered exactly what I wanted, I would have built a gold plated brick that would serve as a doorstop, you know? Sure. So at some point I was like, here's this thing. It's not quite working, but they're like, well, that's good. Cause we're throwing it away. It's, it's completely useless. We're going to be doing this thing over here. Yeah. Yeah. You know, it's making me think. So, so tell me what you think of this. If we were to try to break down waste again, in this context, into a couple of things, a couple of few things, if that's a phrase, uh, that's, that's, that's, that seems like a, some medieval talk for like two or three score. That's right. Say like, I don't know what, what would that be? 40 or 60. I forget what a score is. Uh, but. Score 14, isn't it? I don't know. Yeah. We should look this up. I have no idea. Maybe I'm thinking of a fortnight. Oh, fortnight is definitely 14, two weeks. Yes. I don't know where that came from. Uh, the word. Agile estimation. Oh, there you go. So it's, there's one type of waste, which, and this type of waste is one of the more interesting. And, and that is what you built was not useful.

And, and there's a new, there's, there's a, there's a further subdivision in there of it, it didn't function. It did. It wasn't good enough to be useful. Like it didn't fit the problem that you had. And then there's the one that you were kind of describing, which is like, it was fantastic, but you solved the wrong problem. Right. And so like, that's like, that's like this waste of like, good, genuine labor, right? As, as you were describing the golden doorstop. Right. And then, and then there's also the waste of like, and I think this is, this is the one that I think we were most familiar with. There's just like, this could have been automated. Right. Like, like that, that should have just been taken care of. And then, and then I guess there's like, there's like malicious waste where like, I'm not going to do that. Like, I'm, I'm going to go like, you know, do something else instead of this. So like, I'm kind of like, and I guess there's even a variation there where there's like, and maybe this gets, I don't mean to be the one like lecturing here. I was just excited to like, uh, talk about this, this waste stuff. There's, there's, there's like this, the negative part of product productivity is this weird phrase nowadays, but I think there's a type of waste from management's perspective, which is this worker gave me what I wanted, but they only had to do it in half the time that I thought they did. And then they went home and it's like, oh, I should have gotten more. Right. Yeah, exactly. Versus just like, just like, versus just like the worker just being like, I'm not, I'm going to leave work early. Who cares? Right. Like, it's kind of like, I don't know, but those are the things that like run around in my head as far as like types of waste. That is tough. I mean, yeah. So there's kind of like, I guess, slack in the system you can think of as waste, but you have to think about utilization in that case. Right. I mean, slack, there's a certain degree of slack that's very helpful and associated with resilience, right. Especially over a long period of time.

You know, if you flip a coin and it comes up heads every single time, then, you know, then you bet your house on the fact that it's going to come up heads. Like, that's not a, it's a very poor strategy. So like to a degree, uh, uh, waste can be valuable and it's very difficult to say that any particular usage of time is wasteful. Right. I mean, if the best ideas come in the shower, then, you know, listening to a podcast while you're in the shower so that you maximize utilization of your time, maybe, you know, maybe entirely wasteful. Right. So like, I guess, I guess one of the most important things to mention here is that just like value is subjective, like waste is also subjective. subjective and it's subject to like a temporal dimension. Like it's the period of time matters. Like, like how long are we talking when we're talking about something? Cause something might pay off in the long run. Right. And this idea of like full utilization is just like a symptom. Well, it's a, it's a, it's a leading cause of fragility in a lot of cases because a slack allows you to pivot, allows you to make up time if anything goes wrong. So I think, you know, the engineer who finishes something in half the time, you know, if they, if they hand over the work early and there's an understanding in the organization that we're going to use the extra time to make sure that it's great. And maybe there's changes that we can make, you know, if you're kind of using an SLA to its fullest extent and saying, I'm going to use all the time, uh, because every time I highlight slack, it gets eliminated.

That's kind of like a pathological response to like available capacity where, you know, you could use that capacity for much more valuable purposes. Like let's, let's go further. Let's test this under circumstances that we wouldn't ordinarily test it. Uh, let's send it to customers early and get some early feedback and maybe have a chance to, uh, improve it. Like, I think there's a lot of those things that that engineer would agree with and they might rather do than go home and do nothing. Like for sure, we kind of, we like, we like to work. We like to be productive. We're not always trying to like finish everything and go home and, and do, do something else. Yeah. Yeah. I like that you brought up, uh, you know, slack, which, which is a, uh, an old, you know, it, it means something entirely different nowadays chatting and stuff, but like wait, but before that time it was a, uh, I don't know. I forget, I forget which, which one of the, the, uh, you know, the ancient, the elders of agile wrote that slack book, but it was one of, uh, it was one of those concepts that like kind of was seemed really nice and sort of, well, of course it seemed nice for an individual, but it kind of went by the wayside and, and like, I've, I've been thinking, I've been thinking a lot recently among many other things in my life, but every now and then in the shower as it were, like of, of trying to draw, figure out this distinction between, between like productive output and having a reliable capability, even if you're doing nothing with that. capability. Right. And, and, and, and, and, you know, you were kind of, we've, we've kind of brought up a few things, but it's sort of like, like the example I was thinking about the other day is like, uh, you know, I had to renew some medicine I had and, and I was thinking like, I don't

really know if my pharmacy like needs to update their software every week. Like, of course, if there's a problem or like there's some regulation or all those things, right? Like, you know, if, if the screws in your building are rotting out, you got to go replace those. No problem. Right. Just to be metaphoric, but like, they probably don't actually need to do that much. However, if some new log gets passed and they have like 30 days to do it, which would be unrealistic, but whatever, you know, they have 90 days to do it. Then they're going to need the capability. Right. And so like, it's, you know, so it's, it's almost like, I don't know, I don't really know what to do that with that in the software world. Cause we were so focused on like productivity and like getting value and all of that, that the idea of just like, yeah, but we don't need to do anything right now, but we will sometime like it's, I don't know how you account for that, so to speak. Yeah, I mean, there's, there is a, you know, there's the dimension of urgency that kind of adds, adds color to this. Like cost of delay is something that's very real and almost not understood by anyone. Right. I mean, we're very, very bad about pulling the future forward and quantifying it in any way, like quantifying the difference between doing something now and doing something later. One of the lean principles is, is like decide as late as possible. Right. And that's kind of very compatible with the agile world of like, let's do things when we have, you know, sufficient information and capability and availability, capacity, all these things. There is, you know, I think it's very, I think it's very important to think about your ability to respond. Right. So like in the pharmacy sense, the fact that you don't need under normal circumstances to

adjust to any kind of eventuality that might arise, uh, is one, you know, is, is one thing that's one, that's one condition to optimize for. But if you pull too far in that, that kind of, uh, common cause variation, um, to, to talk, you know, in Deming speak, which we probably shouldn't, but like if you're optimizing for like ideal circumstances or even the status quo, ignoring the fact that there are disruptive occurrences that happen periodically, you're going to have a bad time. Right. It's just a matter of when that coin flip comes up against you. So I think it is really, really important, but then there's, there's also like, consider the fact that a lot of places will have, well, they used to more than now have like fully duplicated capacity. And like a secondary data center that's just running, waiting all day for like something to happen. And then what happens is it's waiting and sitting around for so long that all the staff who know how it works and all the documentation gets stale or, you know, moves on to something else or just becomes incoherent. And at the moment you have to leverage that capacity or capability, like nobody can actually do it. Right. So like, that's, that's like double waste, right? It's like, not only are you paying for the thing, but you, you're relying on it and you can't use it in their time of need. So you've, you've kind of have to have this capability and capacity, but, uh, it can't just be like a checkbox. It has to be something that you, you know, you've kind of, um, that's available to you to utilize if you need.

Yeah. Yeah. You're making me, I, I, I like, I like the, the, the way you're going with that, that coin flip thing, like in, in, in the sense of it, it, it is kind of a vivid way to imagine, like you assume the future will be like the past and, and you make big plans on that. And so, you know, and, and this capacity thing is kind of like, it's like, ah, we haven't had to update our app in three years. Right. Like it, people call in, they renew their, their, uh, their drugs, they get them done. Right. And so there, and so therefore we can make plans based on that instead of like, uh, but you know, the, the, uh, the coin flip makes it more, uh, but we like, we, we, we both work with banks and large, like financial institutions. We work with a lot of these companies that have these regulations that come down the pipe. And, you know, you were saying it's not going to be 30 days or whatever, but even when it's 18 months, the, the banks are always like, should we just pay the penalty? Like 18 months, that's pretty tight. Like, because it's not just 18 months, right? It's 18 months. That's already allocated an account. Yeah. They're already at full capacity. So I think that adds a really interesting dimension to this is like you, you know, this, this utilization and capacity challenge is something that really, um, really bites us because we don't like to have Slack, you know, and Slack doesn't work for the books. And so, so, you know, I want to get to the, the other side of waste, which, which is value, but why don't you introduce yourself first? How, how are you able to, uh, to opine for some 20 minutes about what waste is? Uh, well, I mean, it, it, it really comes from that initial experience of, of wasting a lot of time and effort. Um, you know, I really developed a visceral sense of waste. I, you know, buying, by producing it a lot and then being confronted with the fact that I'd,

I produced a lot of waste and so I kind of, that, that kind of brought me to, um, the world of process and flow and, and value streams. Um, partially also because I, I'm, I'm a very non-systematic person. Like I find myself, I love Slack. I love to think in the shower. I love long walks. Uh, and I'm, I'm a very non, I would say very non type a person. So I've always kind of been fascinated with systems and, you know, the trains running on time and how all that works. So I, I kind of, um, got into systems and build and release engineering, uh, very, very long time ago, coming out of it and tech support. And, um, so this is like over, over more than two decades found my way to kind of running, uh, uh, B2B enterprise SAS company and having to, you know, lead teams and lead an organization, uh, and deal with the fact that we were always over capacity. So I, I, I kind of stumbled into value streams and value stream mapping as a way of improving performance, increasing capacity, reducing waste, um, helping my team like get unblocked and, you know, through conversations with other leaders and, and folks all over organizations just found that that that's something that we all know we have to do. Um, and, and there's very, there's no time to do it and there's not a lot of guidance on, on doing it efficient, efficiently and effectively. Um, so, so I've kind of spent a lot of time in that, in that domain for the purpose of making

an easy to kind of unblock flow in organizations. Hmm. Yeah. And, and you've, uh, you, you named your, uh, like consultancy after value streams or something, right? What's, what's the name of it? Yeah. It's called visible value stream consulting because I think the visibility is, is really the first thing that unlocks people's understanding of like what's happening, what's where the waste is, where the issues are, where the opportunities are. So, uh, I'm a big fan of visibility. So like, here's, here's like, uh, you know, I was thinking we could go over basic definitions of things, but, but when, as you're going over that, you've got, I think you've got a great perspective on a few things that always like, uh, consternate me in the shower or out when I'm thinking, uh, you know, I, uh, similar, just like a idle mind of, uh, productivity, so to speak. Uh, but like, it seems like, and, and, and, and, and it'd be great to like, know your thinking on this stuff with all of the various companies you work with. So it seems like if you go over, we'd like what, one of the great things about like value stream mapping and making them visible to your point. I mean, that's often, I think, I think it's great to use that word because that's your first problem is just awareness or visibility of this stuff. But it seems like when you go over what that is kind of intuitively, everyone is like, yep, that sounds fantastic. Right. And then, and then you hit up against that problem of, we don't have time to do it or something. Right. And like, it is like, there's that old saying that like, you know, the most uncommon thing is common sense or whatever. And like, oftentimes someone like you would be brought in because someone is having an issue doing a value stream. Right. Like, but like, why does it seem so difficult to do what seems like a great idea?

I mean, that's, it seems kind of like a naive question, but I don't know if I've ever come across an answer. Well, I think it's pretty timeless, right? It's not a business thing because the same thing applies to like diet and exercise and, you know, everything in life, I think goes back to that earlier point about pulling the future forward, right? If we could sort of, you know, think about the Christmas carol where we have kind of the ghost of Christmas future and we could see, okay, well, if we carry on the way that we're carrying on, here's how it ends up, then it's much easier the next day to wake up and say like, I'm, we're changing everything, right? Like you there, buy me a turkey or however the story goes. I don't know what it is, but the, that, that, you know, that, that visibility of the future on our current trajectory is what catalyzes the change in the present moment, right? And there's, some people are better at that than others, right? Some people spend a lot of their time in the future. There's even, I think cultures and languages that spend more time in the future than in the present or the past, right? That's weird. And it's, that's different, different territory, but the fundamental problem is we're very bad at sort of looking ahead and saying, if we carry on the way that we're carrying on, this is not going well and we should probably, you know, correct course today. And that's a really, that's a very real problem that I think affects every kind of change initiative and effort. And I'm not aiming to solve that because I'm, I'm, I'm, it's not my place to solve it. So what I've done in kind of response to that is shrink value stream mapping and shrink all

of this stuff to fit into the slack that we have. So what I wanted to do to account for that is remove the time objection and requirement to say, if you have 60 minutes or an extended lunch meeting, or, you know, if you have time for a retrospective fit value stream mapping into that time box, and now you've removed that like common hurdle of we'd love to do it, but we don't at the time. So I think, you know, rather than say, well, you're just going to have to block out two days and, and that's the cost of entry. You know, my approach has always been, how do I make this accessible? How do I meet people where they are? How do I make it fit into the time that's available? And I think it's also helpful because, you know, the Parkinson's law is something that I reference all the time, or I think about all the time. The idea that like everything will happen in the space that's available for it to happen, right? You'll, you'll finish everything right before the deadline, 99% of the time, or, you know, the, the pessimistic version of Parkinson's law is just that like, if you have something that takes five minutes, it's going to take an hour. If you have an hour to take, but I kind of, I like to think about the inverse of that of saying that if you time box something, if you shrink it and you make it possible to fit it into that time box, then, you know, there's a, there's a, there's a, a very motivating factor in that deadline, that end of the time box that can work in your favor and kind of act as a forcing function, like an enabling constraint.

Yeah, no, that makes sense. And, and, and, and I think what you, uh, what you laid out there, like it's, it's, uh, it's useful, you know, there's, you start with this principle of like, I, I don't know a, uh, uh, I mean, you, you said it well enough, but to try to say it, you know, in another way, like people don't really value optimizing for the future too much, like, like are changing things they're doing. Right. Like the example I always use is like flossing, like we all know we should be doing that multiple times a day. And I'm pretty sure we don't, I don't know. Well, the other thing that, you know, that we touched on earlier was this idea that if you can do something in half the time in the wrong organization, that's usually used to your disadvantage, right? It's not usually celebrated and, you know, you're not rewarded for taking less time or doing something more efficiently. The, the, the end result is usually that you get less budget. Your expectations are raised. Um, slack is driven out of the system. So in, you know, in a lot of organizations, I think that the common management paradigm, uh, actually works against improvement because there's, there's not a positive response to improvement. So what do you, do you think, do you think that, you know, going on with kind of like the, the, the default disposition of people in a, uh, a large enterprise, the, the kind of people that we work with, it seems like most people, I don't mean that in a judgmental way, but collectively, like there's not a lot of thought put into like engineering how the work is done. You sort of like move into a steady state. And that seems to be like that. And, and I say that because it seems like when you, you know, when you first encounter and re-encounter like actual, like lean manufacturing and assembly line things, like one of the

things that's, well, maybe it's not easy to overlook, but one of the things that stands out is like, wow, everyone's always figuring out if they should change stuff to do it better. Right. Like, and to me, that's a very, like, I mean, I'm not an engineer, but that feels like what an engineer does like versus a scientist, right. Who's trying to discover like the one thing, but an engineer is just like, I don't know. Let's see if this works better. Right. Right. You know? And, and so, but you know, when I've, when I've worked with people in the past, like it's really hard to introduce this idea of like, whether it's in work life or personal life, it's just like, we should engineer what we do as much as possible, not to make golden doorstops, but like, you know, maybe we should change the way we do things. I think that it's very rare. And that, you know, that engineering as problem solving is very much the, you know, the framing that I was thinking of when I came up with the term flow engineering for like the, the work that I do, um, because it really is about, you know, solving flow problems with, you know, classical engineering methodology. But, um, you know, it's, it's not often that you hear about things like, like Satyala Nadella, uh, I think in 2002 or three or something said that if you have a choice between developing new features and improving developer productivity, improve developer productivity, like that was, that was a very profound and rare statement at the time. And I, I don't think it's actually taken hold elsewhere and maybe not even across Microsoft as a, you know, as a fundamental principle, but I think that it's, it's pretty profound. And I think it's very consequential to think in that direction.

Like if you can, if you have a choice between doing something and doing what you do better, you should invest in doing what you do better. Um, that's, that, that I think is a very rare sentiment and it might be rare because of those things, those kinds of organizational antibodies or culture that says that we're going to drive out slack. Um, we're going to capitalize on efficiency gains and most of this is not going to work in the favor of the contributors. Yeah. Yeah. And, and, you know, it does seem like, well, well, here's a question. Well, we will see that it's a question when I ask it, but like, do you, you know, if, if you've ever done work with large government organizations, do they operate, do they, does it, is it similar like the issues they deal with? And I asked that to do my old question than a statement thing, because it seems like a lot of, you know, we were, a lot of the pressures you have in a commercial business are just like, we would like to make as much money as possible or, you know, either through growth or through spending less, whatever it may be, but like, we want more money. Right. Whereas the government, that's not really what they do. Right. Well, they kind of, I think they have the opposite. Uh, they typically have the opposite paradigm, like their budgets get reduced and then they have to kind of respond. Whereas in the, in, in an enterprise organization, you kind of deliver the opportunity to reduce the budget. And then the budget gets reduced to kind of capitalize on that opportunity to increase margin. Right. And I don't think margin and growth are the same, you know, you're kind of flipping them

in government. Everything is constantly trying to be minimized. Um, so I, yeah, I do see a fundamental difference there, but they're not any, you know, they're not any more or less efficient as a result. I would say that, you know, they're, they are less efficient, uh, because it's very, very wasteful to just like cut budget and then see what, you know, see what happens, what happens. Right. Like, let's just cut the budget and they'll figure it out. Like that's not, that's a very, I think a very counterproductive way to drive performance improvement. Yeah. Yeah. Yeah. No. So, so then, you know, we've, uh, uh, been very abstract here. Thanks to my meandering, but like, like what, what is, what is, let's go over like what value is in this context. Right. And, you know, you mentioned, we've mentioned a few things here and there, you know, top and bottom line revenue and making money, blah, blah, blah, those things. But like, what's a, what do you think about and what has been the practical meaning of value in, in the work that you've done over the years? I think that, you know, value is one of the least understood things in the, in the technical world, but even in the business world, you know, we kind of abstract it. Well, maybe, maybe we don't abstract it, but we kind of proxy it behind metrics. Right. Um, but I think it's helpful to think about a couple of things. First of all, like you don't ever define value, right? Like value is, uh, evaluated by the recipient. So this, I think is one of the fundamental things behind like deliver fast, give fast feedback because everything up to the point of delivery is expected value, like an assumption of value. Um, and that reconciliation of like post delivery utilization, um, and then feedback is ultimately,

you know, the opening the Schrodinger's box and finding out if the cat's alive or dead. So the, I love conversations like this, cause I will go like, I'll go really abstract, but I'll, I'll, I'll try to reign it in. So the, the, the thing that was really helpful to me was thinking about it across three dimensions, like value to customers is one thing, probably the most important thing to the business. Um, but there's, um, but there's also value to the organization in terms of longevity, resiliency, sustainability, capability, scalability, all these things that enable the business are also valuable. Right. Um, because they enable that customer value or they support it. And then there's value to contributors, which is, you know, an understanding that you can't do any of that stuff. If you're not providing value to the folks who are actually doing all the work and that's, you know, that goes beyond monetary compensation. Right. It's, it has to do with personal development and positive feedback or constructive feedback, useful feedback, uh, meaningful work, all that stuff. So thinking about, you know, one of the things that I did soon after starting to map value streams was I started mapping out outcomes, like trying to understand what are we actually trying to do? Um, because a lot of cases would go in and we'd start to map a value stream and then it's very hard to decide what to do if you don't know the ultimate purpose of the goal of doing the, doing the work. So after divine defining a target outcome, we look at like, what are the benefits of this?

What's, what is this actually going to do for customers, for the business and for individual contributors? And that's really clarifying. It's really helpful because just having a target outcome doesn't necessarily help you make the decisions as you're navigating towards it, as much as understanding the value from these three different dimensions, because they kind of act as guardrails for you to stay on course. As you can consider, as you can consider, well, okay, if we do this, yes, it's valuable to customers, but we'd be significantly sacrificing margin, which is unsustainable, or this is going to be great for customers, but we're, we're going to hate doing it. So ultimately that's going to work against us. Yeah, yeah, you know, I, those are, I like the idea of like, it starts with whoever the user, customer, whatever it is, right? And like, that does seem, that, that, that is, that does get confused a bit in talking about value and software. And then, yeah, and then rightly so, like, that's why you want to get it in front of them as soon as possible, because you kind of have no idea what's going on until, well, that's, that's not accurate. Right. You need feedback. You need to test out what, what, what people like or not. And it, and it also does seem like with those, with those three angles, you can, or those three perspectives, you can also like there, you can kind of get over one, one of my least favorite things in all this kind of work is like, is like constantly asking why, why are we doing that? Like, what's the goal of this? The why? And, and let's, I, I even, you know, there's this phrase that like puts my, uh, the back, the hair on the back of my neck, like on edge where someone's like, let's take a step back and ask why we're doing it. It's just that every time I hear, take this, take a step back. I'm like, oh, this is going to take a long time. Right. But like, it, it, it's like, it's a different approach to answering this why question. Right. And I think maybe what, what irks me so much about people asking why is I feel like they're just trying to come up with an excuse that I create to not help me.

Right. Like, and, and versus, well, let's make sure we're doing something valuable. Right. Like you do want to do something, but I'm not questioning if you should be doing that thing in the first place. Instead, we need to figure out like across these three to use another loaded term stakeholders. Right. Like, is this going to be good? Right. And, uh, so it's, it's, it's better than just one single metric of value. I guess, I think, and it's, this is a tough, it's a tough domain because, you know, the, the dominant narrative I think is really confusing. You know, a lot of people think about direction and purpose, uh, and they think about, um, you know, start with why, right. They start with what's the, what's the big idea or what's the reason for, all this stuff. But I don't think you can even get to that unless you have a vision, like, unless you have a, what, unless you have something that you're actually heading towards, then you can't really measure. Like, is this the right thing? Is this like, one of the things that we did with outcome mapping was we changed wise to benefits because why is just, you know, it's, it can be very abstract and very difficult for people to think about, but benefits is a lot clearer. Right. And so if you think about benefits to these stakeholders, um, you're framing it at a positive, but also like more concrete and tangible dimension that's much, much easier to talk about. And I think that's, that's, that's, that's something that's really powerful. Like, cause, cause value is, you know, it's, it's very difficult for people to talk about, you know, it has this temporality to it.

It has subjectivity to it, uh, is not very helpful. So if you're, if you're thinking about a target outcome and then the benefits of that target outcome, um, then I think you're way ahead. And it's much easier to meet people where they are rather than hope that they understand value before you can have a constructive conversation. Yeah. I mean, it's almost like, it's almost like the, uh, in, in, in the, the Ted talk version of what why means that, that why is like what you discover. It's like the last thing that actually comes up on the table and you kind of reverse engineer it. It doesn't seem like, you know, many people at the start of their enterprise, so to speak, have sort of like a mission in mind. It's more as, as you're kind of were saying, they have, they have benefits or a product or an outcome or, or, you know, to, to, to borrow the term, like they have sort of like this flow in mind that they want to establish. Like, you know, I want to own a coffee shop. The why is because I like it. Right. You're right. I think, I think you're right. I think, you know, over time what you, you need, you need the why to be increasingly powerful. It's like more like a reminder, maybe. I don't know. Yeah. As a, you know, as a guard, as, as a, like as guardrails, but also I think as a pull mechanism, right? Like as something that is motivating to people and, and catalyzing and, and kind of like inspiring to people, but like, you know, Apple computer didn't start with think different, you know, like Nike didn't start with its like marketing strategy. And, you know, the difference between a marketing strategy and what you're actually doing is usually pretty, pretty dramatic. Uh, and if you're lucky, you can narrow the gap over time, right.

Between aspiration and actual achievement. But I don't think it's very helpful to kind of hold people to these abstract terms to try and figure out whether they're, they're going in the right direction. But I do think that, you know, the, the, the, why benefits can be really good as a test. Like I think of them as a test for the target outcome. It's like, Oh, we want to do X. So, okay. What is, why is that important essentially? And if you can answer that well, from all those different perspectives, then you might have something. So, so let, let's, let's, let's, you know, wrap up hopefully with, with a very practical thing. So, you know, using your time box inspiration, let's, let's say, uh, let's say I person in an organization, I've got an, I've got an hour, right. And, uh, I don't know, I found a, a, a, an empty whiteboard and some markers and, you know, just me alone or this person alone. Like what, what could I do that would kind of get me like a value stream up on the board. Right. And, and, you know, using again, that word, like, because this will get like visibility into like, what is going on. Right. Like, like what, what's, what's something like, how would someone get started with that such that they did the end of this hour. So they'd be like, ah, now I can do something like not to complete something, but like, I'm left with more action about actionality. I don't know what that means. Yeah. I'm left with more cape, you know, capability to do something than I was earlier. I would say, you know, I, I used to go right to the value stream map and I think you can do that if you have clarity amongst everyone involved on why you want to, what the purpose of mapping the value stream is, right.

What are you hoping to get, are you hoping to increase quality or are you hoping to increase throughput, um, value added time? Like you can use a value stream map for a lot of different things, but there's no real value in just mapping a value stream. Sure. Uh, compared to, you know, having a purpose for doing it because, you know, if you sure you'll find stuff, but it might not be the most important. Thing and you might get distracted by what you find and you could have a completely more valuable target, um, that you're not serving by being distracted by what you find in the value stream map. So I would suggest doing an outcome at first, which is why I start, you know, I, I always start everything with mapping an outcome because it's, that's actually quite actionable. So if you, uh, the basic structure of an outcome app, the way that I do it is, um, this acronym OBON. So outcome benefits, obstacles, next steps. And if you zero in on a target outcome, like we want to go faster or we want to eliminate waste very simply, those are, you know, not super specific, but they're specific enough. And then you think about the benefit. I think they're also well-known and understood. Yeah. Most people know what that looks like roughly. Um, so that can be a great starting point. The obstacles is another thing that we don't think about very often. Right. Um, but they increase that action ability by understanding, you know, what are we going to trip over if we just start running in this direction? Um, and then next steps can be anything from value stream mapping to a survey, to interviewing people. Um, so that kind of creates options, but also focuses those options on action, like on actually doing something.

Uh, and you could take that in and go and map a value stream or do any number of other things. Um, but it's, you know, it's probably not true that you know exactly what to use a value stream map for, unless you've kind of thought about those things first. Yeah, no, that makes sense. And then also, as you were, as you were mentioning, right, it seems like, I mean, you, you know, much better than I do with much more firsthand experience, but like one, one of the great values of a value stream is all of the people involved and just sort of like having them share in that moment. And, and, and, and, you know, kind of the, the, the, seeing what's going on there. Whereas like, you know, if only one person knows the value stream, that's of limited utility, unless it's a one person organization. Right, exactly. But I mean, to, to, to, you know, to really address your question, if you're a one person, you could probably very quickly do that outcome mapping stage. And then to, to speak to the, the value stream mapping itself, the fastest way is to actually work backwards from the delivered value. In a case that has already been delivered. So think about something that happens pretty often in your organization. Like you don't want to take a one-off occurrence and try to map a value stream because there's probably not much of a stream there. But if you're talking about a release process, for instance, go from customers are using the new feature that we just released and then work backwards from, okay, what happened to make that happen? And what happened to make that happen and you get the, the structure and then you add timing to that structure. So you say, how long did each of these stages take and how long were, were we waiting between the stages? And that's kind of the simplest representation that gives you a lot of information and you probably have something pop out.

That's, that's very clear and very actionable. Right. And, but, you know, and, and then, I mean, as you were rightly saying, you don't want to have a gratuitous optimization, right? Like you need to have a reason to be doing that. But, but now I, I think that that's exactly what, what that that's perfect in the sense of it's to boil it down, just do a value stream of something that already happened. And instead of like, because you can also just do a theoretic one, right? Like what would it take to do this or, you know, whatever, but just like, think back on some process that already happened and just map that out. And then that's what you can do for your hour break, right? Like, yeah, you can do that really quickly. And it's, you know, it is this kind of very comfortable retrospective activity. Um, and it's a very productive way to run a retrospective. So like you could do it in your next, your next retrospective. Like you can work backwards from, okay, well, we delivered these things in the sprint. How did it happen? And then you can find, okay, well, where was, where did it feel really difficult? And where do we feel like we spent the most time and that can be super productive. Yeah. All right. Well, great. Well, this, this was, uh, this is fun. I think, I think I have a, uh, uh, slightly more precise and delightfully confused notion of waste and value and all these things. Like, I think, I think that, you know, to, to use the old silly joke, right? Like the, the, the, the, the more confused I feel about things, the more I feel like I understand them, but just because you have all the angles and nuance. So, so that was great. But like, so if people are interested in, uh, looking into more of this stuff, seeing what you're up to, where, where would you send them? Uh, well, I spent a lot of time on LinkedIn, so you could find me on, on LinkedIn, uh, or if you, you know, if you search value streams anywhere, hopefully I come up. Um, I do have, uh, I just wouldn't put, putting the finishing touches on a book called flow engineering. That's going to come out through it revolution.

So you can take a look at that on their website and, um, yeah, I'd love to talk to anybody about waste and value and flow in, in big complicated environments. That's my favorite thing to talk about. Yeah, no, clearly it's yeah, no, it's, it's a good topic. The, uh, figuring out how big systems work and don't work is always, uh, fascinating as you were kind of alluding to earlier. Well, well, great. Well, if you've listened this far, you've been listening or watching to another Tanzu talk episode. If you go to Tanzu talk.com, you can hunt down the show notes, or if you're watching a video, I'll put some links down below to things mentioned. And with that, we'll see everyone next time. Bye bye. Thanks.

Tanzu Talk · 🍕 Get more pizza.