 Welcome everyone. Thank you everyone for joining this session with us. So this is the session which we are having today is Achieving Business Agility with Value Stream Management by Al Shadowway. Great. Well, it's glad to be here. You may have noticed this is not a PowerPoint slide. Hey, what's going on? So here I'll put this in the chat. This is a mirror board and for the last couple of months I've been starting to use this board. You can get in it yourself and look around or you can follow my presentations and this will stay live for a while where you can ask questions. You should have if you're going to navigate it yourself. It's good to get this on the left and this on the bottom. If you don't have that, it's easy to get. You should have actually gotten instructions when you came in. But sometimes it looks kind of like this and the way if you're here, you just click these double arrows here and click this and now you have a navigation method. And that's what I'm going to go through and do. And the link is down in the chat. Now, the reason I do this is because this enables you to look around as you want. I would prefer you pay attention to me, of course. But if you have questions, you could also put comments in here and I'll get to them later. And this is a live document. I now do all my training this way. As was mentioned, I'm now with Success Engineering, a new company I formed. I'm no longer with the PMI, but I still do discipline to agile value stream consultant training. I'm going to have a lot of quotes by Don Reinertson. If I mentioned his name, it came from this book. But here's another interesting quote that we sometimes seem to forget in the agile world. Everybody talks, excuse me, everybody talks about how we all need to do our best and we're all motivated and things of that nature but we also have to know what to do. I'm somewhat distressed to be candid that methods like Scrum are, in my mind, too simple and don't give a lot of information that people need to recreate. There's no reason to recreate things now. 20 years ago, we did not know a lot about how to do things. We know a lot now, but I go into many, many teams and they have no clue. People are reinventing much of the practices and thinking in agile. So that's an issue, I think, in this. The message, by the way, was in the chat. This is the last time I mentioned that and maybe some, Meghana, you could put in and answer those chat questions about how to get here. I've put it in the chat box again. Yeah, very good. Yeah, now I'm planning to go through this talk in about 30 to 35 minutes and have questions at the end, but you can be adding questions on the board itself. You can use here this on the bottom, rather, this is a way to add a comment. The easiest way to add comments is actually just right click where you want it to go and say add comment or you can put a chat in the mural chat. Anyway, if we're going to talk about business agility, let's get clear what we mean. It's the ability of an organization to deliver value quickly, sustainably, predictably and with high quality and it needs to be consumed by the customer, not merely delivered. There's an old phrase called shelfware where we delivered it but nobody used it. That's not, that's not sufficient. This focus on delivery is wrong. It has to be on consumption. All too often you see software go out that has not considered support has not considered marketing. And that's because the focus is on delivery instead of consumption. If I've got to go back software for since 1970 when I started college and when I became a professional in the 80s and 90s there was a focus on code complete. And then it became okay tested code and then it became delivered code and now it has to be consumed. That's what our focus needs to be. Let's let's consider something about what a system is because I want to give an overall view of things and what we have in creating products or what I just call knowledge work because sometimes we're doing, we're not really building a product so John Reinerson talks a lot about used as a phrase product development and and it's as applicable to what I'm talking about is my phrase knowledge work but sometimes they're not building products we're trying to solve particular problems or other things so I'm using a broader term. But a system is not a collection of components it's defined by the relation between the components. So the best parts of the best cars and put them together you'd have a pilot junk you wouldn't have a car systems live as a whole of all the pieces not as the pieces put together, and we tend to forget this because we started agile kind of at the team level. We're saying oh we can a time, we can put these pieces together, but we can. It's not a good system if we do that. And in fact we're at the end when I talk about how we actually do this we'll see this is actually bad thinking. And I suggest that moving to agile solved one of the main problems, which was go smaller, go faster, but it left the structure of the organization that does it in a simplistic way, and we have to take a next leap forward, which is what basically I'll be talking about here and what I'm doing at success engineering. Okay, so optimizing the components of the system literally destroy the end objectives of the system. In other words, let's say we optimize an engine on an airplane and made it have made it bigger and more capable. Well, it might make the engine too heavy, it might not be controllable, you cannot look at individual pieces you've got to look at the hall. And basically a system without must have an aim without any there is no system in other words the system aligns around it's not the individual pieces working together. It's everybody working toward the system. There's actually another way. If you do that that's kind of interesting I'm going to go into this mode it's called presentation mode gives a slightly bigger screen and now looks a little bit more slide like as well. Okay, so. And here's I'll just show you how to make a see I right clicked it add comment that's as easy as that. Okay, anyway, coming back. Let's start with the inherent problem we have our inherent problem is imagine we don't really have corn silos here but you know we have the customer and we do some requests and it goes into say marketing and then decides to go into portfolio management and then development or whatever. So this is kind of what we call the value stream all the steps of work from when we get the idea. Now the customer may not give us the idea that might be something somebody in the company figures out. It's on behalf of the customer so when we talk about it. An idea starting with a customer. We're saying that figuratively we're not saying it's exactly it's on their behalf however. So it goes across, and we're organized in silos. So what we want to consider is what's going on when this happens. When we're organizing silos we might be very efficient in the silo and very efficient than this silo and very efficient than this silo but work tends to accumulate between the silos because this silos done that's always busy working on something So what we have is we get these delays we get this work in the silos and this is an interesting quote by Reiner said he says in product development or knowledge work. Our greatest waste is not unproductive engineers but work products sitting island and process cues. See it's very busy inside here, no work the work is waiting between these two this is a big problem. And the big issue here is this as work waits here. It causes waste and the reason it causes waste is we lose knowledge. The knowledge gets old, and if the mistake is made here and it's got to go through all this and waiting in the silos, even though it's busy here and busy here and busy here. The slow feedback causes a lot of problems. In fact, I would suggest this feed this slow feedback is a bigger problem and complexity, because we make little mistakes but by the time they get here they're very big. So it's called a non linear event a little thing causes a big problem. The straw that broke the camel's back is like great example of it so this been around a long time. It's biblical. You know it's the idea that I make a small mistake now it gets big consequences later that's what I mean by a non linear event that's actually much worse the situation than complexity itself and we're actually set up to do this in many ways. So we have to somehow manage the system it doesn't manage itself left to themselves components become selfish independent profit centers and destroy the system. The secret is cooperation between components toward the aim of the organization I kind of like the outline here so I'm going to go back to this. So what we are set up for though is to optimize locally managing each of the pieces locally. When we need to look at the whole system because locally none of these pieces are going to optimize themselves. So this is our inherent problem we manage one way. We're not managing the system per se we're managing individual pieces of the system and this causes competition, which you see now I make a quote, I make a little note who Edwards Deming is. Deming is an American who helped the United States in the war effort World War Two, and he ensured were two key pieces on this improving quality and production capacity. And after Japan was taken over you know MacArthur was the commanding general of the occupying forces of in Japan. He brought Deming out to Japan to help build radios because the infrastructure was killed. And they basically the Japanese saw how good his methods where they brought him out later in the early 50s I think it was to help them just get better and that's how Deming became known in Japan. And Deming is somewhat qualified considered the person who taught the Japanese quality and he's slow to be adopted by the United States. But here's, here's the thing we're talking about I'm going to go back to this picture here and then see what we have is if we have the silos, consider what a silo looks like you have managers, managing the people in the silos and they're saying if they're productive if they're working on the right thing. If they're working with good quality, and lean actually suggests a big shift in agile from agile. And in that it actually from manufacturing everything is we shift our focus from people to the workflow, instead of looking at the people say in the silo and seeing where, where they are. In what they're doing, we have to shift to how is the work going it's natural to see if people are productive and working on the right things but this won't solve our problem because that's a local shift we must shift to productivity from productivity to speed of delivery. Again operating a product development process near full capacities and economic disaster this from Reinertson. So, we have a lot of shifts and at first this looks counter intuitive well you know you mean we're going to look at the work, we're not going to look at the people, but I thought our people are best. The best thing our best, you know, the important part in the company and it is true. Okay it is counter intuitive, but it's actually. When you think about it you can understand it a little better so I want to think about it just a little bit here. So, if we trust our people we shouldn't have to manage them. We want them to be in a great work environment dummy suggests 96% of our errors come from the system not the people. So focus on the system there's another way of saying this to otherwise a bad system will be that's supposed to be beat a good person every time. See this call I could actually should be able to but you know the the will be a good person every time. So, but also then there are a lot of reasons so 96% of our errors come from the system, almost all of our errors the reasons for the areas of deficiencies in the system, rather than the employee so this is the number of errors that actually occur and then they look at look at the number of reasons is so predominant. The role of management is to change the process. Rather than to change the system, or excuse me rather than to badger the employee, okay. Improve the process now we use the people as well have to think it's not that they mandated it's important that it's important that management works with the people. Okay. So we're going to trust people to do their best. That being said you still need to give them the information they need to make good decisions. And this notion of just delegating is insufficient it's one of the reasons agile gets themselves at people following agile, purely in the sense of oh their autonomous let himself organize. Well you know what maybe they don't know how, maybe they don't know how they fit into the rest of the organization. What information do they need to be able to do that. That's that's an important consideration, because an example is something Don Reinertson talks about in building the triple seven bowing when they built the triple seven. They had cost and weight trade offs, the heavier plane is the more expensive it is to fly so if you could actually lower the weight on an airplane that's a good thing. But how much how do you make that decision how much are you willing to do in a trade off so you. Know about how you had to give people the right information to make good decision so it's not simply defer the decisions, it or delegate the decisions, it's important to give people the information they need to make good decisions. Okay. Now I've talked about delays but that's only part of it. Okay, so see delays in the workflow are obviously bad because they delay the delivery of things. It's worse than that, because you delay feedback. Okay. Requirements are done but not used which means they get old. Okay, codes are written but not tested until after delay it's harder to find so it takes more time. If you're not a developer this is a funny phenomenon that you only get from being a developer I, I haven't seen people understand this if they've never written code. But if you write a bug and believe me the developers do write the bugs. They, they talk about it like somebody else put them in or testing broke their code but the developers are putting the bugs in. We don't mean to let it happens. If you write a code one day and you actually find it that day you'll fix it quickly. But if you don't find it for a week or two it could take you hours or days to find it even if nothing else change. But as you have delays between writing bugs and finding them it takes work at waste is work. Sometimes someone's needed but not available so these delays in workflow create much more waste and really the delay of the product. In other words delay of an hour could cause an extra hour or two of extra work. This all ripples through so you really have problems with delays and we need to recognize that this is our enemy as the delays. The side effect of delays is the fact that the work they create is never planned for so we have this unplanned work we didn't plan it we didn't think about it. It probably should be planned for but it isn't. And the more delays in the workflow the less certain are schedules and this in turn causes more delays, because we schedule things to be available they're not so we have to wait for people. We want to start attending to these delays between work steps, which is again like in a system it's really the relationships between the components that's the big thing. Okay. Now, how do we do this well one way first is at a global level I you know I should say, globals maybe the wrong word holistic level manage what goes into development. We don't give developers too much to do because then they won't be overloaded, you can also. You can look at how much is being done. Look at the big picture of the work being done. Now gold rat who is the creator of the theory constraints said, indicated how important this was by saying often reducing bad size is all it takes to bring a system back into control. Some people nowadays and agile talk about complexity and is it complex complicated simple etc etc. I actually think that's a little bit misgiven we're complex. Look, we're definitely complex system. If you have people you're complex it's as simple as that. No pun intended. What you want to know is what you deal with it you don't need to navigate it so much as know is what causes greater chaos or or complexity and the more things you have in the more things in play the harder it is to see what's going on. So one thing you can do is lower the number of things going in. Okay. So value streams haven't quite defined what they are is the work flowing across the organization we actually call these workflows. That's success engineering it's a better metaphor it's not a linear little narrow stream but I'm going to continue calling them value streams here because that's within the title. So they're not the people doing the work but rather the workflow itself, talking about value streams as people takes our focus off what we should be looking at this is one of the reasons I don't like talking about it that way although safe does I think it takes away some of their power. We want to avoid value streams crossing each other. This happens when people are in multiple value streams and if we talk about stable value streams. If we talk about stable value streams in this way. Then even I might have several people and several value streams but they're in their stable and says oh look I got these people and they're in the same value streams. But it's not a good way to talk about it think of the workflow and when they cross by having multiple people in them, then then that's not so good. Okay. So what goes into it this is kind of at an abstract level, the way to manage value streams conceptually anyway is what goes into it the size of the items. How many have is important how people are organized that's called the value creation structure. I'll add some references to this or take note of the of the mirror board and I'll add there's there's several good books now on this and I don't have a reference in this talk but I'll add it. Workflow methods are important in other words you do test first specification by example automated testing alignment is important you know can we see how how people are working together. We want also small items that people will work on an aligned manager so there's this question how do you get small items. And this is again or I think we've gone a little off off the rails. In that, in that MVPs are in vote which is good the minimum viable product Eric Reese is using that and it's good but it can be used. And it is used to determine if you have a product but MVPs are not intended to manage the enhancements of a large system MVPs should not be used with time boxing time blocking is when you're looking out ahead. And you're saying hey we've got this. What are we going to do well if you're trying to discover if you have a product you don't really know what you're going to do that's the whole idea of the thing. So, so we want to really look at. We want to really look at not MVPs for when we're enhancing on to meet something else and what we call this a minimum business increment. The heritage of MVIs comes from the minimum marketable feature, which by the way is not what is used in safe. I don't know why they re purposed mmf which isn't the new x either. But the minimum business increment is the idea of the smallest chunk of value that we can give to a customer where they, they consume it. Okay, and we should use both MVPs and MVIs when appropriate, we have other talks on this in detail. A lot of reference to this as well. I'm going to make a note, add reference to the MVIs and books easy to do so you can come back later and you'll see that. I have a question about Nick Kirsten stuff. Nick's work project to product is brilliant and his flow metrics. I mean, I got to give them a credit they're brilliant but they're really just a rebranding of lean metrics. So I don't mean that in a negative way, I think it's brilliant stuff project to product by Nick Kirsten is really good. MVIs are more though just about value increments. This is something that we have at it. This is a unique thing of MVIs say versus mmfs. And I've been trying to get for about a decade people to follow this and some people have I've had a lot of people come to me said you know we use the MVI concept and transformed our whole company off that one concept. Because it also is how what do we need what are all the people we need to get it out the door what's the marketing what's the documentation what's the support. And we can create them by saying how can we deliver this piece soonest so we do that to some extent market segments, language things of that sort, but it creates a way to implement an initiative by doing a little bit at a time and then also by saying, you know, these are the people that are needed so we can get basically a better team structure. I'm not saying reorganize things. Every time I'm not going back to project. But what are the people at least noted we may not reorganize but at least we know who we need to get the thing done. So what we want to do is step back, let's just do a quick summary and I'll get into this slide and we said we've got to look at the entire value stream. We've got to attend to delays. We want to look at small things we want to look at our team structure, but obviously if we have limited amount of work we're doing at any one time we're trying to deliver faster. This, the MBAs are about delivering quicker, not less we do quicker pieces. Okay, what's value. So the customer's value stream in other words we have our development value stream but we call the customer's value stream their operational value stream it's how they do their operations. By the way the customer could be an internal person or group, and then that's the internal operations of a company. So how the operational value stream the development value stream interact is called the customer journey in other words how do they, maybe not that's maybe worded poorly how that should be how the operational value stream and our system interact not the development value stream. In other words the journey is they do this they do this they do this on our system notice the, they do some things outside of the journey so the operational value stream is their full path. The customer journey is how they manage through our system. And we should look to see how the way we define the customer journey can positively impact the operational value stream, or sometimes you go just the opposite you look at what would make for an efficient effective operational value stream. And then we create our system to improve the customer journey. I give a quick example of this. This is funny for some reason but back in the 80s and 90s I used to work in the hair salon business I wrote software for hair salon I had written a system using touch screens this is all on DOS and it was really brilliant UX besides I will say so. In those days, a lot of people had never touched computers before, and hairstylists aren't rocket scientists when it comes to, to computers now I love here, I love the business I love the people in the business but they're very they are very artistic they're not necessarily that logical and we'd created a system where they could just took them 15 minutes and they were trained basically and how to use appointments and all sorts of stuff is brilliant. But part of it was because we considered how they work and one of the ways they work if you've ever been at a front desk of a major high end salon like in a beta they were one of our clients. It's crazy up there. And we looked at that craziness we observed how they work at their operational license and we came up with what are now known as function keys everybody has them but back in the 80s it wasn't the constant. Everybody use menus back then we had a system that use menus or function keys or option or commands and the function keys and became the customer journey but the way they use the customer journey was their operational value stream so this is a really powerful technique. This can be very powerful technique to step back and consider this. Okay. So what we want to do this a little repeat what goes in the size and how much and what the quality is the 10 to the way people organize the 10 to the workflow. This at a high level is what we want to look at. Now, agile is good. I mean I've been around an agile since 99 want to learn XP and I was at the second snowbird 10 I was not at the original snowbird. That's where the agile manifesto was created it called a snowboard because it was in the snowboard ski resort. I was at agile 10, which was 10 years later held in the same place. And there's no question we move forward but we move forward by working smaller teams and smaller pieces, but I would suggest we've got the wrong paradigm still because the argument should we start bottom up top down or both is based on hierarchies of management instead of do we attend to the value stream we want to get away from hierarchies. This is the point hierarchies are in silos blockages and values you're often caused upstream but really putting less into it doesn't work if you're using an effective methods behind, it will be useful. But here I'll jump back to this. See, if you we improve what goes in here that might help because you won't overload this but you've got to change this whole structure. So what we want to get to is this new way of thinking that we're going to look at the entire value string, because fixing a piece of it, and thinking in terms of hierarchies is the wrong mindset. So starting a portfolio management may help starting at the bottom they help with the relationship between the parts is what's really important so we need to start looking at values and this is a challenge we have because most everybody says start with scrum. And, and the problem is it doesn't include management, it actually teaches teams to self optimize locally optimize and then they have to unlearn that later when they have to learn how to work together. And once you've learned how to be fast and efficient you don't want to learn how to go slower, because you feel your team is more important than the whole and that's not true but that's how it feels. It often is done by creating cross functional teams I've seen this literally hurt the organization, because the people that make the cross functional teams to create the scrum teams are taken away from other people in the organization this is very done when it's a test is all it's creating a scrum team and will try things out, but they don't realize they're hurting the rest of the organization and it doesn't address the real issue of getting value delivered to the customer doesn't look at the whole picture. And it doesn't recognize it in truck team relationships are not the same as inner team relationships. So the pieces of the whole the teams need to fit, need to be structured in the context of the whole. Okay. The structure of an isolated autonomous team does not exist in a medium to large size company this is the big myth. Oh yeah let's create these isolated teams and then let's scatter them throughout the it doesn't work because you got ops you got sales you got all sorts of stuff. What you have to do is have the idea of smaller organizations, like to have entrepreneurial entrepreneurship entrepreneurial or microcosm microcosm so instead of having a thousand person company made up of, of like a 10 hundred person things have more smaller pieces where the people the teams are not maybe purely autonomous but the collection of small teams is. So there are other structures that are that are available. I'm going to try to wrap this up so we have time for questions I'm getting pretty close by about five minutes behind that's not so bad doing this in the talk. Starting at the team is not always ideal. I have seen that it's sometimes best to create a system like remember one of the ways I used to do safe I don't anymore because I think what I have is much better. But when I did safe, I would actually create the structure that multiple teams could work in it was a lot easier to teach them teams at that point system providing the proper work area to the teams how do they get what they're working on. You can't just start at the low level essential safe because you everybody needs portfolio management. So starting at the bottom does not provide that to people again a holistic needed. Now I would suggest the frameworks don't really work that they teach you learning the framework and they teach you if they're complicated or big than they teach you parts of it. And although there are similar issues, the value streams are unique so you they need to be contextualized. Now, value stream mapping creates visibility here was a simple value stream map I use in 2006 my very first writing us that this was the company my very first training of a lean software development workshop and we had sales development deployment. The, and it worked brilliantly actually we found the problem here we did five wise on this and I'll put the reference to the article. But five wise we found the problem wasn't in development this show that every now and then we had to loop back and fix something after it was deployed. The problem is actually in sales and when we asked why are we going back here it was things weren't being properly configured because sales hadn't told people that I won't tell you the whole story because they're running behind, but I will put this reference here so you can read it online, but the point is so I started out wow value streams awesome. But then after a while I found out that it was expensive and rarely done well because I'd go into a place, and they wouldn't take the time or have all the people they needed to do it. So what I was left with what I was left with was a poor value stream I came up with this concept of Kanban bars are like value stream apps. We have columns a set of boxes and arrows and that helped, but it wasn't enough and after struggling for a few years. And I'd interviewed literally hundreds of consultants and change agents so things that worked and didn't work what I noticed was that pretty much. There was a core set of things that everybody had to do and that, and that if you had FDA regulation federal drug administration in the US. You had you had hardware software there are some others, but that you could actually see what was needed. And what we came up with was a way to contrast what you've had to do conceptually. Am I doing like good portfolio management. So am I doing good intake process. So instead of looking at just delays which is what value stream management I looked at the objectives of what was going on and found this work as well with. Almost as well with significantly less effort. So it's kind of like the Pareto principle so in the discipline agile value stream consultant workshop that's actually what we do. We don't teach value stream mapping but we teach how to use this idealized value stream that see how you do against that. It gives you almost all the information you need at a fraction of the cost. Okay, I'm almost done. The way to start is identify value stream to improve. You look at small things. And this is some advice from Reinerson and I agree. You know, reduce bad size, it's cheaper management like saying oh we don't have to hire more people but it lowers the delay so it's a good starting point. Okay. That's actually it the. I think this. That's two slides I had were actually just a little bit more notes about this about company but let's just stop here. So I'm going to go through the q amp a and chat. I go through that actually quick. But if you need to get a hold of me. This is how success engineering works. That's my company. And you could click here I'm not going to do but you can learn more about our collaborative engagements we don't use PowerPoint we don't tell you what to do we actually work interactively with a company or with a team on on doing things. Okay. Okay, so I see something from Bob and how to implement systems value streams when you're a service provider different services to different customers or needs are different. Well, I guess I'm not totally clear on the question you would you would attend to each of those has to be a different capability have to consider how would I build a system that how would I build a system that and what people are needed for that so when you build the system that provides the services. You would look at it holistically again look at all the needs and then actually an MBI might be this is one kind of service I provide this is another kind of service I provide and things of that of that nature. Okay, I can look at the chat. And then I'll look at the board I didn't notice if anybody had actually entered something on the board. Okay, well are there questions please. Please ask questions I'm going to look to see if anybody's added something on the board as well. See this is cool, but I don't know. There's one more question. So, so they asked they're asking how do we try strategic. Very good. That's a great question. That's a really good question, because there's actually, you know, I wish I could say I knew it all. That'd be a lie. And the reason I'm laughing is because this question just nailed something that I realized about three months ago, and I don't have it in my materials but I will talk to it because it's such a great question. One of the things we tend to think about is that strategy is part of our value stream, and it isn't it's a separate. It's a separate value stream. And I want to pull this up and show that. So really great question. Thank you so much for it. See here, we're talking about the value stream of like I got the customers and we're working on it. And this is actually when something comes in and we decide if we're going to do it and all that. Now if you step back and think about it. That means we've already got our strategy. Well, the figuring the strategy is not in this value stream. We already have that. What we don't have is what we do have to put in here is how do we fit this in that strategy. So what you're asking for is how do we figure out that strategy that influences this, at least I think that's what you're asking. And you can confirm that in the Q&A if I got it right to stop me if I have it wrong. But then what that means is somewhere we need another value stream called let's calculate our strategy and the customer that value stream is actually the company. In other words, we have to have a strategic create the strategic value stream, create the strategy value stream that is used to create the context for this. Now how to do that is is something that I've done for quite some time and ironically I've never. Never totally documented it we talk a little bit about it in the discipline edge of value stream consultant workshop and we have a community of practice, and I'm planning to write it up but I'll tell you, I'll tell you quickly. The concept of strategies is what you want to have happen is that the people who are responsible for leadership executives, etc. You want them to consider what does it mean for the company to be successful. And we call the things to look at investment pillars in other words what are you going to invest in to make the company successful and an investment pillar for say a company that help people do finances. It could be like well what we want to do is lower costs we want to rather the first one might be we'll do whatever we can to retain customers because if we retain customers we retain assets, and we make more money based on how many assets we have so retain customers might be one retain assets might be another compliance with regulation could be a third lower our costs could be another one. So we look at these four or five you don't need more than five. Investment pillars we invest in and then you could rate these while retaining customers is twice as important as lowering your costs or whatever you decide on this. And now what you have is you have basically the reasons for investing and you have a measure of which ones are more important and then when you do portfolio management, you can look well this compared to that. Well how does it go to the investment pillars and you can literally do a comparison this way. We had years ago created an Excel sheet that did this. It's not being made available right now outside, but my company is going to rebuild that thing because it's, it's an old concept other people have used it, it can be used with, if you're familiar weighted shortest job first I'll add that as a reference. But that's a way of figuring out what to do based on delay thinking and value. You could literally use this balance of investment pillars as a way of seeing what's more valuable than the others. Okay, any other questions. Yes, there's one more question. So value stream is great for existing work, but what about completely new initiatives. How do you define the initial value stream for things which were never possible, like there are no existing operational value streams. Okay, that's great. So, so here you got an interesting issue because you're actually creating the operational value streams of the new product. So I would suggest there are two aspects wonderful question one thing is. You still should have this focus on on what value is this one right here you still want to look at this, except now we don't have a customer trying to make a customer. So what we want to look at is what do we think their value stream would look like how their operations would look like we should still be thinking from their perspective. So now you can say yeah but we've never built this before see what a development value stream can be reasonably stable even when it's different. Even when it's something new, however, consider this you can have different kinds of typical value stream so if I'm doing something that I've been doing for years and years I see my operational but I excuse me I see my development value stream I see how to I probably work in a different way than if I'm building a brand new product as you mentioned, but you will still have a value stream so you still know you need to do something. It's kind of like what would a value stream for building an MVP look like versus what would a value stream for an MBI look like and it's again an interesting question. In an MVP you're going to take smaller pieces you're probably going to have more of a flow model because you don't want to wait a week or two to get feedback. You don't want to go faster. So you still know a lot about past innovation. So another question, I can answer your question with a question. Yeah, I'm a consultant right. That's a joke, but I could say, what would be an effective value stream for creating new products. And then how do I create that I can say right now well we're going to incrementally build in a flow model to determine what's necessary. Okay, so hopefully that helps out a bit great question again. These are great question any other quite great questions, or even Aussie questions. It doesn't look like it but I'll use this last minute for something else. So look, this was a talk I have never given before, and notice what I did, we are right on time to add how did I do that. See agile talking about you can't do schedules and agile no I adjusted my space I just did my depth I was continuously adjusting to the deadline of now. So thank you for being here. Stay safe. I hope you learned something. Please ask continue to ask questions and make comments on the board it's a live board you can't change it but I will be adding things to it. I will look for more information about me and more information right so I did references. Thanks and take care.