 Hi, my name is Kent McDonald, real quick background about me. I am what I refer to as a product person. So my background is in business analysis. I currently serve as the product owner for the Agile Alliance. So work on their website and the submission system. I also help other product people, so product owners, product managers, business analysts, figure out the right things to deliver. So the particular topic for today has a lot of interest for me, because I think from an agility and a mindset perspective, while we might have the right things going as far as how we're doing practices and everything, we're often not able to see the true benefits of having agility because we end up not doing the right thing. So I'm going to talk about what I mean when I say it's better to be effective, beneficial. Before I go on though, I'd like to get to know you a little bit more. So if you would, trying to get a feel for the room here. So how many of you would consider yourselves like a product owner, business analyst, that sort? Raise your hands, okay? Few of you. How many of you would consider yourselves developers, okay? A little bit more. About testers, how many testers do we have in the room? Couple, project managers. Wow, all right, that's awesome. Okay, I'll have to tone down the project management jokes then. How about managers, just in general managers? Okay, a few of those. Did I forget anybody? Coaches, how many coaches do we have in the room? That's, yep, that's okay. Did I forget anybody now? All right, good. Thank you very much, that helps. I've got a nice broad swath of different types of roles. So be equal opportunity ribbing when I talk about those things. So how many of you have heard this phrase in relation to, we're going agile because we want to be, or your team needs to do this, sound familiar? Better, faster, cheaper? What's your experience been when you say better, faster, cheaper? Which part of the better, faster, cheaper gets left by the wayside? Cheaper. Okay, my experience has been it's better. But so in order to get faster, the cheaper goes by the wayside, because we just keep throwing more people on it, right? What happens is that, and a big tendency is that a lot of people think, hey, if we adopt agile, it's gonna allow us to do this. And it could, but there's a lot of it's and a lot of assumptions that are going into that to make sure that happens. What really ends up happening is that we get focused super tightly on the idea of efficiency. The faster becomes the prime leading thing that we're trying to do, to the exclusion almost of everything else. My background is, I mentioned I was a business analyst, so I've worked a lot in IT settings. And a friend of mine, Jeffrey Davidson, once we were just kind of having a conversation. And he made this comment and I thought that is perfect description of what's going on. Because what happens is that we're facing this issue for folks that are in an IT situation. But to some extent, we've done it to ourselves. We've done it to ourselves because in a lot of times, it's before we started adapting agile was in order for us to solve your problem, we want to know all the very specific details down to the nth degree. And we can't start until we know that stuff, right? Now, we don't do that anymore, hopefully. But we've trained our business partners that they have to tell us exactly what they want. Even though we all know that when we deliver it, that isn't what they need, right? The other thing is, is that we have found a way to avoid saying, no. To our detriment, right? We always will find a way. We're gonna be heroes. We're gonna make this happen. Yeah, but we won't. We'll find some way to reset expectations along the way. But what we're not doing is really saying, are we focusing on the right things? So when I talk about effectiveness, I think this quote sums it up best. From Peter Drucker, he's a guy that a lot of people look to as one of the fathers of modern management. And what he's effectively saying here is, is that it's one thing to be efficient, but if you're efficiently doing something you shouldn't be doing, it's a big waste of time. You might be going real fast, but you might be careening off the cliff. That's not a good idea, generally speaking. So what we wanna be doing is we wanna be effective. We wanna be making sure we're doing the right things. So, and where this comes into mindset, if you are at the keynote this morning, Joshua mentioned the whole idea of being focused on outcome. To me, outcome is really understanding what problem is it we're trying to solve and doing the right things to make sure we're solving it and only those things. So, a big part about being efficient is not only deciding what we're going to do, but also deciding what we're not going to do, okay? So, in order to talk about mindset and make it useful, I wanna kinda talk through three different, or actually four different techniques I've found to be very useful. They're very simple, but they're very powerful that you can help lead this mindset to say let's be more effective. And it basically comes to these three things right here, which I have found to be a pretty good description of what product people should be doing. And I'll talk about these in a more detail, but this is gonna be the structure of the talk. One thing before I go on is that if you notice on the front slide there is that I did have a URL. It's also been the last slide. The slides are also already in the app. So there's a page on my website that has a great deal of information, has these slides, and has a lot more supporting info as well. So feel free to take pictures of the slides as long as I'm not standing in front of them, even though I'm being videotaped, but the slides are already up there actually, as well as a bunch of blog posts that are supporting this stuff. So let's get in it. The first thing that's very important is building that shared understanding, okay? And this relies at a variety of different angles and levels, but really what I'm concerned about here is do we all understand what problem it is we're trying to solve? We can't determine whether or not we're building the right thing unless we know that, okay? So a technique that I have found to be very useful for doing that is what's known as the problem statement. And I got this, originally found out about this from a book called The Requirements Memory Jogger by Ellen Goddistiner, and what it is, it's a similar to Jeffrey Moore's elevator statement. But what you're doing here is you're trying to talk through, you have a template basically for describing a specific problem you're trying to solve. So the four bits are the problem of, so this is just blatantly out there trying to get people to describe what problem it is we're trying to solve. Who does it affect? So who are the stakeholders that are most likely to be impacted by this? What is that impact so that we have an understanding of why it's important for us to be solving this problem? And then a successful solution would. Now it's important on this last one. This is not saying this is what the solution is. What this is saying is what are some characteristics that would tell us we've got the right solution? You can think of those as your criteria for success. So what I do for this, do with this in order to help build a shared understanding is I take a collaborative approach to uncovering what the problem statement is going to be for the team I'm working with. So what I do is I put up four flip charts around a room and get all of the relevant folks together. So generally it's whomever actually started off whatever effort you're looking at. Both the people that are delivering the solution and the people who are getting the solution delivered to them. You give each of them four sticky notes and you ask them on one post-it note, they write what their thought is about the problem. The next one it's who does it affect? The next one is impact of which is? The final one is a successful solution would. So everybody does this on their own individually and then I have folks come up one by one, read them off and put them up there. So the first time I did this exercise is working with a project team of 11 people that had been working on a commission. This was for an insurance company in the States. They had been working on this project for about six to eight weeks. 11 people, I had them do this exercise and so they were working on a commission system. How many different perspectives do you think we had? 11. Some people often say 12 as if they're one of the people had a split personality, but yeah. We had 11 different perspectives ranging from and you could almost tell where they came from. Ranging from we're just gonna make the existing commission system easier to maintain. All the way over to we're gonna completely overhaul the way that we're paying our agents. These folks have been working on this project for six to eight weeks. You think there might be a problem there that they had that wide of a range of understanding about what it is they were working on? So after we had them put these up and that in and of itself was a great eye-opener to the project team. Now to be honest with you, I didn't necessarily intend to come out with that result when I started this. I was doing it more selfishly to figure out what the project was about and I figured this was a good way to do it. But the minute we saw that, it was immediately apparent like okay, we need to dig into this. So the next step is that you have the entire group start at this first sheet and talk through and not leave it until they have a consistent understanding of what the problem is. Then they move to the next one and then the next one and the next one. Now I have no clue. I cannot remember what the actual problem statement that they ended up with from that exercise and that honestly isn't that important. What is important is that that team had that conversation with everybody there because what they were able to do at that point is they were able to hear what was going on in each other's heads and they were able to come up to a conclusion as far as what is it we're really trying to do with this thing? And that in and of itself was invaluable. Now I believe they did take that problem statement and posted up on a wall where they were working so they could always refer back to it. Because it's always a good reminder and I'll talk about that here in a couple of minutes to always go back to that when you have decisions along the way that you need to make. So again the problem statement, the real value of it is, is the conversations you're having and these various pieces provide some additional information. So again the problem of it helps you clearly state what problem is it we're trying to solve. This is gonna identify who your stakeholders might be and oftentimes what comes out, especially if you have a large group of people doing this, is that you end up listing everybody in the company and your customers here. Which is fine as a starting point because maybe yeah we like to believe the thing we're working on impacts everybody. But really there's probably some people that are more important that we need to worry about first. And so that's an important discussion to have here. The conversation that comes out on this one is why is this not a problem that's actually worth solving? So another aspect about are we doing the right thing is saying you know what, you probably shouldn't bother with this. It's not an important, yeah it's a problem but we've got much bigger problems we gotta worry about right now. And then finally this one as I mentioned before it's a great way to get some ideas on what some success criteria might be for what it is you're trying to do. Okay, make sense? Problem statement. The next thing is is provide a guardrails for decision making. And one of the things that's one of the assumptions that's underlying this is I'm a big believer that the most effective way to do decision making is to distribute it out into the organization. The people that are best situated to make the decisions are the ones that are closest to the information that you need in order to decide. And that usually isn't the person that's sitting back three levels back from the team that's working on something because there's filters that get in the way of the information going back to them. But in order for that to be effective is those folks need to have some kind of guardrails to stay within to make sure they don't completely veer off course when they're making those decisions. So one of the things that I like to use is an idea called the decision filter. And I got this from my friend Neil Nicolaiason who's been a CIO at several different companies. And he uses this to help convey what the strategy of his organization is to the people working on teams so they can figure out are we moving in the right direction or not. And I have what I refer to as a technique brief about decision filters on my website so you can read more about those. But the idea here is that it's a very simple question that you ask to help you determine should we do this or not. So the formulation is basically will this help us do X? So if you go through the exercise of doing the problem statement, that might be what you fill in for the X. So will this help us do this particular thing? If yes, great, keep moving on, we're gonna act on that. If no, throw it in the trash. Stop worrying about it, don't deal with it anymore. This is a good way to make sure we're focusing on the right things and not spending our time on stuff that does not matter. So as an example, I mentioned I do product ownership for the Agile Alliance. One of the things we did a couple of years ago now was we did the Agile Alliance website. And there is a lot of things we could have done and we tried to do with the website. But it was important for us to focus on what were the more important things? Because I have found, regardless of how many people you have working on something, you never have enough. Does anybody else experience that problem or you never quite have enough people working on something? So you always have to decide what do we need to focus on? What should we do first? And so decision filters can come in handy. One of the big things we were wanting to do is how can we encourage people to engage more with the Agile Alliance, right? So what are some things we can do on the website that would enable that to happen more? So that was one of our big decision filters. How can we encourage practitioners to engage more with the Alliance? And so one of the things that the website does is we're trying to get a lot more information out there. And so I think it's great that the Agile India Conference videotapes all of these sessions because that's a great phenomenal piece of information for the India Agile Group to kind of share it with everybody and spread it out through the community. We do that as well with the large Agile Conference in North America. We just don't do all of the sessions. So that's one of the things we have. But we use this as a filter to help us make decisions about are we gonna do this or not? And to some extent, how should we approach it? So can we approach it in a way that's gonna encourage to more so the practitioners to actually engage with the association? So this is what decision filters doing by passing along this question, it gives people kind of those guardrails to stay within saying, okay, I'm working on something and this can be day-to-day decisions that I'm about ready to approach this new story that I've got to work on. Let me think about it. How can I do it in a way to make sure I'm living to that? The other nice thing that decision filters are helpful for is to stop and name discussions in their tracks. So I like to have these posted up, especially if you're in a co-located situation. You get in this long discussion about something that obviously doesn't have a lot of bearing on what you're really working on. I always like to re-around a point and say, hey, are we living to that right now? Or can we forget it and move on to something else? Help us get to an answer quickly. Does it really help us do this? Or should we just forget about it and move on to the next thing? Okay, any questions about that? Decision filters, they are very helpful. They can work and help you out in a lot of different situations. The third thing is very important. And this one is something that's kind of even going a little bit against the grain, even for a lot of agile teams. And it's the idea of not only being focused on outcome over output, but also measuring accordingly. So when you measure, what do you typically measure to track things that are going on in your project? Just shout out some things. Story points, what else? Velocity, burn downs, what else? What was it? End-to-end lead time. Except for the last one, all of those are measures of output. And to some extent the lead time is as well, right? Why do you think we measure those things? They're there. What did you say? The value. Why do we measure like story points? So a lot of times teams measure story points, velocity, things like that because it's easy. Say that again? Sorry, I didn't hear you. Quantitative. Quantitative, yeah, they're quantitative, right? So sometimes teams will say, we know we want to measure value, we want to be more value oriented, how do we measure value? Customer satisfaction could be one thing. Some teams will actually come up with the idea of value points. Has anybody used value points? That's good. What value points are is basically, we're gonna take the idea behind story points and do the same thing from a value standpoint. But the thing there is, is it's not really telling you exactly what's going on. So what I have found to be helpful in customer satisfaction is a great example of this, is that if you're wanting to measure outcomes, a good way to do that is to look for goals and objectives. Now, I think the reason that a lot of teams don't do this is because it is difficult. And you can't always immediately see the result when you do that. But I think there's still some value in it. So what I like to do when I'm looking at objectives is I always like to identify a certain set of attributes about those objectives. And again, this is another good thing to have a collaborative conversation about to make sure that everyone is in a clear understanding about what it is we're talking about. So it's a little cut off here, but it's basically the name of it. The units, the method, so how we're going to measure it. These three things in and of themselves are extremely important. The name and being very precise about what it is we're talking about here. So we will have names for things, and this is my business analyst background coming back to haunt me now. But I have found that teams will often use different words for the same concept, or they'll have different concepts to apply the same word to it. So it's always good to have the conversation. When you say new and renewed members per month, what do you mean by that? And let's make sure we're all in agreement, okay? So that's where the what to measure is helpful. And then talking about how we're actually going to do it. And you can get a little bit technical here. And it's helpful because you might actually need to put some stuff in your backlog in order to make sure you're getting that measurement now. Because you might not be getting it before, right? Then the next thing is you want to understand your target, your constraints, and your baseline. Where are we at right now, baseline standpoint? Where do we want to get to? And what do we want to make sure we don't do at all costs? So constraints, they can vary as far as how they are in relation to the baseline and target. So sometimes you may be at a point where you don't want to get any worse than you are right now. Right, so in that case, your constraint would probably be matching your baseline. In other cases, you would say, well, we know that we might institute some things that temporarily might cause a dip, but then we'll start heading towards things. Which is what we've got the case here. So our constraints, and the example that I'm showing here is again from the Agile Alliance is, how many members per month are we adding or renewing? And so right now, baseline is 250 members. And admittedly, you might not always know that baseline information right off the bat either. You might have to do a little bit of digging to figure that out, we certainly did. And you think about, where do we want to get to? So what business driver is causing us to get to where we need to be, and then how much kind of fluff in that are we willing to accept? So in this case, we said, we're gonna try some things that might drive a little bit of a decrease in what we're doing, and we're okay with that. But if we get below 200, then we know we gotta worry about it. So part of this is having the conversation about clarifying what all of these things mean and what we're trying to accomplish here. And then the next part is what we do with it. So one of the other downsides of doing value points on actual stories is that in oftentimes a single individual story, although we'd all like that to be adding a little bit of value, honestly may not drive forward any progress towards this outcome, right? You may have to have a set or a collection of stories. The more complicated, the more complex your system is, the more likely is you're gonna have to have multiple things going into place. But what you have here is you try to find some objectives that you can put something out into the wild, out into production, and quickly get some feedback back, still quantitatively, about what kind of impact that had to make a determination, okay, are we heading in the right direction? Do we need to change what we're doing? Or have we actually already met the outcome? So it's the whole deliver frequently, get feedback on it and decide what we wanna do next, okay? So hopefully you can come up with some of these objectives that allow you to do that. In some cases you may not be able to, or these might have a longer lead time than you're really willing to wait before you decide what's your next move gonna be, okay? So ultimately, having these, describing your outcomes in terms of objectives is very powerful because this also gives you some guidance as far as when we're making decisions, which route should we go with it? But if you're in the situation where we may have a bit of lead time before we can get there, and you still wanna track it immediately, there's another way that you can go about doing it. And that's known as the parking lot diagram that I've used. This was actually originally created as part of feature-driven development. Anybody hear that? Yeah, okay, good deal. It was one of the earlier brands that has kind of fallen out of favor, well not fallen out of favor, but just doesn't use much. And the reason I like this over primarily burn up and burn down charts is because one of the things that I find specifically burn down charts is, is that with those you don't get a sense of what kind of scope change is going on. All you know is that you're burning things down and everyone's happy. What you don't know is how much stuff do we keep adding into the backlog along the way. So burn up charts are a little bit better because you can at least see the scope change going on in there. But both of them, a big problem they have is they aren't telling you context. What do you think I mean by that? So environmental factors is one thing, what else? It doesn't tell you what you're delivering. It tells you the number of things you're delivering, but it doesn't tell you whether those things are the right things. Just gives you a bulk number, which it can be helpful at least to guide you in the direction of maybe we need to ask some questions, but it doesn't tell you are we working on the right stuff. This at least gets you a little bit closer to that. And so let me explain kind of how this is laid out. So you have something that you're working on, you've broken it up into big chunks, preferably things that are closely tied to delivering a specific outcome. And you might be getting multiple outcomes from this particular thing. And you have them broken up into groups. And again, the more complex your system is, the more of these boxes you're going to have. So let's go to a closer look at these things. So one way that you can go about doing it, and don't get too hung up on this word right here, it could be epics, it could be features, it could be whatever your framework describes as those big chunks of work. But you basically have the big chunk. Again, hopefully this needs to really be more tied to outcome than anything. You have some sense for how many little chunks fit into that big chunk. You might want to think about when are we planning to release it? This could be a release number, it could be a date, target, things of that nature. And then you have everyone's favorite stop lights to indicate status. Now here's an important thing. The status color is determined by human judgment, not by some algorithm. So you'll notice this is green. You'll also notice that we have only completed nine out of 12 stories. In this particular case, the team had the epic, they broke it down. They looked at it, they started delivering things, maybe getting things out into production, seeing the feedback they were getting back. They realized if we deliver the nine things, that's giving us the outcome we were seeking. We don't need to do those other three. And so the product owner or the product manager said, yep, we can call that one green, we're good to go. Yes. It could be that that nine out of 12 is your minimum viable product. It could be that your minimum viable product were three stories, because the idea of a minimum viable product again is what's the minimum amount we need to do to get something out to learn whether we're heading in the right direction? This could be, we're done with this particular thing. All said and done. Does that make sense? Okay. I've worked with some companies where they didn't quite understand the concept of minimum viable product. And there's a movie in the United States called Princess Bride. I don't know if anyone has seen that here. There's a saying in there where we keep saying inconceivable and the other one responds. You keep using that word. I don't think it means what you think it means. That's the case with MVP in some organizations. So yes, in this case, it could be the MVP or I would even seem to think that this is probably, it's ready and good to go. So with that in mind, if we go back here and look, what this is helpful for is really to communicate where we're at to people outside of the team. Quickly, and if they're looking at it with the right intent in mind, this is a great thing to help start some conversations. So if I'm saying someone that's from the outside either I'm a stakeholder, I might be kind of another project team or whatever, and I look at it and say, okay, I know that item details and create new order are fine. Those are good. Some of these yellow things, we're a little worried about them, but yeah, okay, we might wanna think there's some risks there. We might wanna have some ideas of what's going on in place, but they're okay. This is the thing I'm gonna focus on, right? It's probably, it may have already slipped a release. We haven't quite got it done, and this is the, we've got 90% of the 90% done. We've got 90% left to go, right? Never been in that situation. So what does a team need help with from this to satisfy this and get this done? So what this is really good for is to quickly relay status, to help communicate and to help focus the efforts where they need to be. It also provides a bit more description of what it is we're working on, because you also notice that some of these things are white, we haven't started working on them yet. And it might turn out that when we deliver some of these other things, we're not even gonna bother with those, because we don't need them to in order to accomplish the outcome we're looking for. So being effective has a couple of different aspects to it. Being effective might be, we're gonna be effective by saying, you know what, we don't need to do this at all. We're also gonna be effective by saying, we don't have to do everything up here. And you can only do that if you're defining scope, if you're agreeing to scope, if you're committing to scope, based on outcomes, not specific backlog items. Does that make sense? So I always, when I'm talking to people and they say, oh, we're in this situation, we're a fixed time, fixed cost, fixed scope. I said, well, you're doomed for failure. But let's try this. Let's define scope and our commitment on scope based on we're gonna get to this outcome. We're gonna solve that problem that we identified early on. But by doing it that way, you leave the team a lot more freedom and flexibility to say, how can we get there? And what really does it mean to satisfy it right now within those other two constraints? And then those other constraints actually become liberating because they help you hone in on, we know that we only have so much time to do this in. We know this is what success is described as. We have the flexibility to work with scope. So what's the best way to make that happen and we can apply our creativity to make that happen? So the question was, can you give an example of an outcome-agreed backlog versus a output-detail backlog? So the backlog itself is still outputs. What it does is what you're doing is you're establishing an agreement at the outcome level to say this thing is gonna be considered successful. So one of those would be when we are working on the website, for example, we want to increase the number of subscribers that we have. What we haven't nailed down is what are all the very specific things we're gonna make that happen? All we know is that we're aiming to increase the number of subscribers we get on a monthly basis by 200. So there's a lot of different ways we could go about doing that. We are gonna try, one of the things we're gonna try is we have videos that are from beginner sessions that are available to subscribers and above. So we're gonna create a class, put together those videos, we're gonna put that out there and we're gonna see what happens. We didn't have that as a agreed upon, have to deliver this as part of the scope, but we're gonna try that and see if it works. And we tried out there and says, okay, it didn't do much. So we gotta go try something else. Or we find out, you know what? That gave us 300 extra subscribers a month. We don't have to do any other things. We can move on to something else. Does that make sense? It really is establishing and having that commitment based on, you still have an understanding as we know we have to do this, but it gives you a lot more flexibility in the details to figure out what's the best way to do there so that you can apply learning and understanding. Okay, any other questions? Yes, you had your hand up first. That's so helpful. But in the process of it, I think we are perfecting one important element. If the common sense is more important than the learning. Yes. So if you keep on finding for bias, and listen to a common sense, that is a better tool that we give as a product. Yeah, I would completely agree and that's kind of the reason I use these techniques is because they try to force people to use common sense because oftentimes common sense isn't common practice. So when I work with teams, so the teams I work with, we don't, if anywhere from the outside were to come and look at them, they would probably have a hard time identifying what particular approach we are using. I'm perfectly fine with that because we're getting results, right? Thanks. Yes. I'm trying to do as a good practices. There's a button behind the fix. We have a test, make sure it doesn't happen again. That's an example of something that something might say, well it doesn't really give us the opportunity or it doesn't give us the outcome. So we're not gonna do that. Right. What do you have to say about that? So I primarily use the decision filters for more feature-based stuff. When it comes to making decisions between do we do more features or do we do fixed technical debt, that's a little bit different situation. And one of the things that helps me make that decision is I'm also the help desk, which you should get all your product owners to do that. The other decisions are gonna be wildly different when you do that. But you have to weigh that if we don't fix the technical debt, that websites not gonna be available for more people to be engaged with it. So we obviously need to address these things. And it's a constant balancing act to say when is it more appropriate to spend time on this versus that? What I often find happening is that we effectively say as we're going along we're gonna allocate a certain amount of our work effort towards new stuff and we're gonna allocate a certain percentage towards cleaning up technical debt. And the ratio of those two things differs depending on the situation. So when you're building something new, hopefully you're more on the new feature stuff and you're not introducing a lot of this other but that isn't always the case. So then there's sometimes where we need to really focus over here for a little bit but you wanna try and get that balance. The decision filters, I really do look more towards the new feature stuff but there's also implied in there is that if the thing isn't working, it ain't doing that either. Does that make sense? Okay. Any other questions? Yes. So the comment up here was that often when you've tried to measure outcomes you've found that you have something with a long lead time between when you move a change in and when you see results and yes that's another reason why looking at objectives is difficult. That isn't the reason not to do it. So one of the things I try to do there is to say, if we go back to this example, this one we're only measuring once a month. So depending on how often you're moving stuff into production that might be fine or that might be way too slow. One decision you could make is say we're gonna measure based on how many new ones per week. The other thing is is are there some other indicators that are somewhat correlated to this that might have a good causal relationship that are quicker to come back. So you can get some input. Otherwise you might say you know what, we have a hypothesis that doing these things is gonna drive the change we need to. So at least we're looking at are we moving in the right direction and then the decision point on pivoting is gonna be a bit longer. So you have to kind of weigh that on your individual situation. Any other questions? So to kind of wrap up, these are the main things I want. If you don't remember anything else from at least this 45 minutes, certainly the whole day, these are the key things that if you're really serious about being more effective and worrying more about effectiveness and efficiency and the key thing is that if you're effective you're also gonna look pretty darn efficient as well. Cause if you're able to focus on doing the right things you're gonna be producing the stuff that's really generating value and chances are you're gonna be able to get to work on more things that are actually delivering that value as well. So again, it's building that shared understanding. I can't stress enough how important it is to do that at the beginning when you're building it but also to make sure you're maintaining that shared understanding. Cause you may go through that problem statement exercise at the very beginning of your effort but if there's any kind of turnover in your team or even if there's not and just as things progress people start losing the memory of that discussion. It's always good to revisit it. If you're in the midst of an effort and you don't think you have shared understanding it's never too late to do that little problem statement exercise. It doesn't take more than a half hour to an hour unless you get into some really good discussions and sometimes what you might find is, oh my gosh, we've had this discussion we've been doing the completely wrong thing. But it's better to find that out sooner rather than later as long as you're gonna correct course. Provide guardrails for decision making. So distribute decision making out into the organization. Don't leave those folks out hanging to dry but actually provide them some guardrails to drive within to make sure when I'm making those decisions I know that I'm doing it so I'm keeping it in alignment and always look to measure. So the question was, is there a technique for decision making cause in big organizations, is there a measure? The measure is actually reflected in how quickly are we getting things out the door. Cause often that one of the biggest symptoms of lack of decision making is, well whoever was measuring by lead time those lead times are gonna increase. Cause you're sitting there and there's a lot of churn going on. And you don't necessarily need a measure everyone can kind of feel it, right? And so what that happens is what I've found to be effective for decision making certainly decision filters. I also find it's helpful to have the discussion before decisions need to be made about who's making specific types of decisions. So that once something comes up and it's a critical timeframe as far as we need to decide you're not spending a lot of time saying okay who's gonna make the decision? You already know that you have an idea of who makes the decisions how do they like to make decisions what information's necessary so the minute that comes up you say okay we need to put some effort to getting that information pulled together so we can make that decision as quickly as possible. Last thing not only measuring based on outcome but output but actually thinking outcome over output. In fact I equate that heavily to being effective over efficient. So thinking about how are we really driving value what outcomes are regenerating what change in the world are we trying to produce? So I like to give credit to the photos I got here there's a site called unsplash.com so if you this all of the photos on there are royalty free so it's a great site to get that kind of stuff. Again here's my contact information here's where you can get the slides and a lot of additional information on my website if you're at all interested it's a book that has a lot of this information in it as well came out last year, two years ago. So got five more minutes I wanna yes. I was actually hunting around yesterday it looks like there's a tool but I couldn't get it brought up on my internet browser so if you do a if you Google parking lot diagram tools there might be something that comes up I think it's a plugin that allows you to do it in Excel. Yeah. So I wanna thank you for your interaction I'm happy to stick around answer any questions you have enjoy the rest of the day and the rest of the conference thank you very much.