.jpg)
The Agile Within
Providing agile insights into human values and behaviors through genuine connections.
The Agile Within
Transparecy in Delivery Builds Trust (Without Micromanagement) with Sonya Siderova
What if everything you thought about improving team delivery was focused on the wrong problem? Sonya Siderova, founder and CEO of Nave, challenges the traditional approach of pushing people to work harder by revealing a game-changing insight: between 60-90% of delivery time is actually waiting time, not effort time.
Through her work analyzing over 100,000 workflows, Sonya demonstrates how making the invisible visible transforms team performance. She shares a powerful example where simply adding a second approver to a bottleneck process reduced delivery time by 40% without requiring overtime or additional resources. This shift in focus—from workers to the work itself—creates transparency without micromanagement and builds trust across all levels of the organization.
Sonya walks us through practical approaches for mapping workflows, structuring work around customer value, and establishing team decision frameworks that enable autonomy. She explains how aging charts can quickly identify bottlenecks during daily standups, saving teams from wasting time on status reports and focusing them on what truly matters: getting stuck work moving again.
For leaders struggling with the eternal question "when will it be done?", Sonya introduces probabilistic forecasting using Monte Carlo simulations. This approach replaces arbitrary deadlines with data-driven projections that acknowledge the inherent uncertainty in knowledge work while providing meaningful ranges for decision-making.
Whether you're a team lead trying to improve predictability, a product manager seeking to deliver customer value faster, or an executive looking to create a more transparent delivery system, this episode offers actionable insights to transform how you think about and measure work. By focusing on flow rather than force, you'll discover how to dramatically improve delivery performance while creating a healthier, more trustworthy work environment.
Listen in and learn how to stop pushing people and start pulling work through your system for remarkable results.
Connect with Sonya on LinkedIn:
https://www.linkedin.com/in/siderova/
Check out Flow Metrics Including Probabilistic Forecasting using Nave:
https://getnave.com/
Follow us on LinkedIn:
https://www.linkedin.com/company/the-agile-within
Welcome to the Agile Within. I am your host, mark Metz. My mission for this podcast is to provide Agile insights into human values and behaviors through genuine connections. My guests and I will share real-life stories from our Agile journeys, triumphs, blunders and everything in between, as well as the lessons that we have learned. So get pumped, get rocking. The Agile Within starts now. Attention, scrum Masters and Agile enthusiasts, are you ready to level up your skills and connect with the best in the industry? Well, the Online Scrum Master Summit is your chance to hear from world-class Agile experts, gain real-world insights and explore the latest trends shaping the future of Agile. Best of all, it's 100% free and completely online. Happening from June 17th through the 19th, this event brings together thousands of like-minded professionals for engaging talks, interactive sessions and hands-on workshops. Don't miss this opportunity to sharpen your skills and expand your network. Sign up now at onlinescrummastersummitcom. And now on to the show. Welcome back to the Agile Within everybody. This is your host, mark Metz.
Speaker 1:My guest for today's episode is Sonja Sidrova. Sonja, welcome to the show. Hi, it's a pleasure to be here. Thank you so much. I follow you on LinkedIn. I see all your wonderful posts that are out there. You're from Antwerp, belgium. Is that right? That's right, yes, okay. So, sonia, if I were coming to Antwerp for a day and had never been there before, what's one thing that you would say that I couldn't miss doing?
Speaker 2:Mark. So when I say that I live in Antwerp, I don't really live in the city itself. I'm living in 30 kilometers away from it, in a little place called Zursel. It's a little village with a gorgeous nature, and the one thing that I would do if I knew you were coming around is I would invite you to be my guest in my home. I would invite you to come to my place because we're living in the middle of the forest, in a house in the middle of the forest with a huge garden, and I have two lovely dogs.
Speaker 2:I have two Labradors One is still puppy, super crazy to be around and I would love. I would love it if you can come and stay with us for a couple of days, because the biggest thing for Belgium apart from the chocolate and the beer, of course is the gorgeous nature and the quietness, the beauty of where you are. It's a farm country. There are a lot of people in the villages, in the farms, and it is a lovely place to really stay and just enjoy the silence, enjoy the nature. You're more than welcome to be my guest next time if you decide to come around.
Speaker 1:That sounds fantastic. So is it even quiet, even with the puppy in the house.
Speaker 2:He's the loudest thing in the house, for sure.
Speaker 1:All right, well, thanks for sharing that, sonia. I want to introduce you. So. Sonia is the founder and the CEO of Knave, a company that helps teams use flow metrics to improve delivery performance and make better decisions. Her background is in agile coaching and lean product delivery, and she's especially focused on making delivery more predictable and efficient, and the title for today is how Transparency in Delivery Helps Build Trust Without Micromanagement in delivery helps build trust without micromanagement. Tell us a little bit more about transparency and delivery and how that builds trust, sonia.
Speaker 2:So I probably should take a step back first, because I do want to talk about delivery and I do want to talk about, when it comes to delivery, what does this really mean? Usually, when agile teams go through their work, they measure different kinds of things, they report different kinds of things, and the goal, obviously, is to make data-driven decisions, to be aware of what's going on and to be more transparent, to be more productive, to be more predictable, if you will. The biggest mistake that I've been seeing lately is that the focus really is on the performance of the teams in terms of individuals. If, let's say, someone says, hey, I need this done by that specific date and things start going south, the first thing that people do is to keep pushing people work harder. They keep pushing in this direction and say, hey, you have to stay long hours or you have to stay over the weekend, or the focus really goes into individuals and how hard they're working.
Speaker 2:Now, the problem with this approach is that effort time and delivery time is not the same thing.
Speaker 2:In fact, there is a study that we performed internally at NAVE, where we've analyzed more than 100,000 workflows, and it turned out that anything between 60% and 90-90% of the total delivery time is waiting time.
Speaker 2:Pay attention to these numbers because they were like really a game changer for us. Anything between 60% and 90% of your delivery time is waiting time, it's not effort time. So when I talk about delivery, I'm talking about both those efforts time and waiting time together. I don't usually talk about effort time because, if you think about it, anything between 1% to 30% is effort time. If you keep pushing in optimizing that effort time, you can literally improve those, go to up to this 30%, but no one actually talks about the rest, like the 60 to 70%, that can actually be improved in order for us to become faster, to become more predictable. So when I'm talking about delivery, I'm talking about both waiting time and effort time. To be even more honest, I'm talking more about the waiting time than the effort time because there are just little tweaks that may happen in order to reduce that waiting time tremendously without changing anything else.
Speaker 1:So why do you think it is that the waiting time is not one of the first places that we go or that management goes to look at the workflow of work to try to reduce? Why is it? Is it just easier to push on the people to work harder or work longer?
Speaker 2:Because waiting time is invisible, because you don't see it, because no one knows about it. That's why and it's not that people, like, don't have the expertise or they don't have the willingness to get there, they just don't know about it. Honestly, this is one of the main reasons why I started my own business back in um 2014. I wasn't in a situation where I didn't see what's going on. I was in a team. Everything like everything was delayed, people were frustrated, the development cost went through the roof. We didn't know what's going on, so we started unhiding what's going on with the work. So this was like a big shift in the actual way we thought about it. We started to think about the work itself and not what the people did right. So we didn't want to focus on the workers, we wanted to focus on the work itself.
Speaker 2:We started mapping the steps that work goes through, from the idea to the refinement, then to the moment that the team put it into the workflow the code, reviews, the approvals, the deployments, all of it. So we started mapping it. Then we actually visualized that flow of how the work moves through that flow, and then we started measuring how much time the work spends in each state. We didn't care who is doing what, we didn't care what people are busy with. We were solely focusing on okay, let's see what happens with the work.
Speaker 2:So we started measuring the times that it's spent in each state and it turns out 40% of our total time, of our total delivery time, was spent in some weird approval state, and we only figured that out when we started measuring that time. We didn't know about it, we didn't see it. It was the waiting time spent in that approval column that increased our delivery times tremendously. As soon as we revealed that information, what we did is to ask for a second person to join on that step, so that there are at least two people available for that approval. So once that person who were responsible for that step were, they were on a leave or they were engaged with something else, that second person jumped in to help. Just by making that tweak, we managed to reduce our delivery times by 40%. We didn't change 40?.
Speaker 1:Yes.
Speaker 2:By just making this tweak. We didn't do anything. We didn't add more people, we didn't have to work overtime, we didn't even have to change how we managed the work. The only thing we had to do is to make sure that the work doesn't age artificially in the process. It doesn't just stay and wait until someone is available to approve it. And the only way for us to know that was to unhide that waiting time. It was to reveal what's going on with the process and really focus on the work and not the workers. The reason people just don't see it. It's just invisible and we have to unhide it. That's one of the things our analytical suite does. It actually measures cycle time of each step in the workflow and then it tells you the majority of the time is spent here. Is this what you expect to see? And if not, this is the bottleneck in your process. This is the main priority for you to handle right now.
Speaker 1:So what does that mapping look like? How do you go into a session with a team to figure out what that workflow looks like? I'm envisioning some sort of a value stream mapping for the work itself.
Speaker 2:It's actually very easy. It doesn't matter what your workflow looks like. It really doesn't matter. The most important thing when you talk about flow and we talk about mapping that flow is to make sure that you represent what you're currently doing. You don't want to design some fancy processes or any some sort of a future state of the work. You do want to visualize exactly the steps that your team are going through in order to release a piece of work that has been requested from them. You have a board. It could be Jira board or Azure DevOps board, even Trello board, doesn't matter.
Speaker 2:You take a board, then you create the columns which represent the steps and then, as soon as you have a work item, you create a card for it and then move the work item through these columns or statuses and as soon as it goes out of the process, then this means that the work has been delivered.
Speaker 2:Now, during our retrospectives, we just go and evaluate our cycle times and the breakdown of these cycle times. At NAIF, we have the so-called cycle time breakdown chart, which essentially is a pie chart which shows you, from all of your delivered work items and the time spent in all of the statuses, which is the status that we spend the most time in, and again, for our case back in the day, that was disapproval status. 40% of that delivery time was disapproval status and it's as easy as just looking into the breakdown to understand that. But then I think one of the major things for us was to really have this shift in mindset in our mindset of switching the focus from trying to understand what everyone is doing up to trying to understand what happens with the work and where the work spends the most of our time.
Speaker 1:So one of the traps that I have seen and I'd like to get your perspective on how cycle time can help with measuring that to look is that many times I've seen developers when I say developers, I'm talking the development team of their eyes being bigger than their stomachs, and what I mean by that is this looks like a small amount of work. It won't take me long to do so. We're going to do this piece of work, and before you know it, the cycle time starts going up and up and up, and it stays in development for days before moving, and then, when it moves on to the later stages, it takes a long time to get that, and so one of the things I have seen is trying to break the work down into smaller increments so that we can get that value realized sooner, as opposed to waiting for a larger chunk of work to get done to realize all that value. Is that something that you've seen as well, sonia?
Speaker 2:Yes, I've been into this conversation pretty much on a daily basis. Now, when we talk about how we shape the work and how we organize the work, I have a very simple rule. So, when we're creating our stories, we do want the story to represent customer value. And what I mean by this is that when I'm shaping the story, I do want, as soon as I'm done, as soon as we as a team are done with that piece of work, the person who requested it can check it, can play with it, can give us feedback on it, because the main goal for us as a team is to solve problems, is to deliver something that's reasonable, that's meaningful, and we can only know if something is meaningful and reasonable as soon as the person who asked for it confirms that. That's the only time when we know for sure that what we've been doing is worth it and what we're delivering is actually customer value. So for us, in order to get to that place to understand whether we're moving in the right direction, we need to try to shorten that cycle time as much as we can without compromising the concept of value. Right, I'm seeing teams who are trying to split the work to back-end development, front-end development, database development. I'm not a fan of this approach because if I have a piece that says database development, how would the person who asked for it can give us feedback on it? How would the person who asks for it can give us feedback on it? Isn't it better to split it in, let's say, maybe some UI interaction, so maybe we can have just the frames and then give it to the customer and they can say, okay, this is in the right direction, or I don't like this, or even that has nothing to do with what I asked for. So when we're splitting the work, we want this to be in terms of customer value and we want to split it in a way that we get to that solution in the fastest and easiest way.
Speaker 2:Now, if we've done this and the piece of work is still too big, it's just there is no way to split it. There is just no way to deliver just part of it. If it's too big, in order to make sure that we still stick to those short cycle times, we allocate more capacity on that work. What this means is that, instead of one person, we allocate two, maybe three people, if there is any bottleneck that appears around it. Any question, this is the highest priority for the team. This means that if, for some reason, something more urgent comes in, we understand that by suspending this big piece of work, we are delaying it intentionally. But all of these decisions, they are intentional. When we're saying yes to something, we're saying no to something else and we're aware of the fact that we're saying no to something else.
Speaker 1:I love that.
Speaker 2:There is a lot of perspectives around that. I believe if the main goal of the team is to make sure that value, that piece of value, goes out of the workflow as soon as possible, then they will start paying attention to anything that gets delayed, anything that stays in the workflow for longer than it should, and this is something that we're doing on our dailies. We have a chart that we call the aging chart, and that aging chart it has all of our work items as dots scattered on a plot, and then we know if a certain dot goes up, this means that it accumulates waiting time. It accumulates cycle time. It's not necessarily a waitingulates waiting time. It accumulates cycle time. It's not necessarily a waiting time every time. It's just the higher the dot, the longer it stays in the process.
Speaker 2:Now, for us as a team, the conversation during our dailies is to go through the top dots, everything that's on top, and talk about it. We don't talk about it, anything that just has been started. We don't talk about our to-do lists. We don't talk about things that are still moving the way we expect them to do. We talk about things that are aging artificially, things that are taking longer than, let's say, 85% of everything else that has been finished so far, let's say, 85% of everything else that has been finished so far. We talk about any blocked work, any expedite work, any questions the team has in order to move forward.
Speaker 2:Our meetings are not status report meetings. We don't go through the entire board to see what's the status of each task. The board gives us that information. We don't need to talk about it. The only priority really is everything that's staying longer for a specific state. Why is that? Is it blocked? Is there anything else that you need? Is there like additional information that we need to provide? Do you need feedback? What is it that's making the work stink and aging, and then we brainstorm solutions in order to have this work moving further.
Speaker 1:I'm sure you've experienced this. How do you help teams get unstuck when you're looking at your cycle time chart and you've got this one circle that's like way above the others. So the cycle time is going up, but the team is convinced oh, this is a special situation, this is different, this doesn't always happen. This just is what it is. We just need to get focused on getting it done. Whenever it gets done, it gets done and we won't experience this again. How do you help teams get unstuck with being more open to looking in and not just considering this to be a one-off and something that they shouldn't look into?
Speaker 2:The way our teams make decisions are following specific decision-making frameworks. We call these process policies, and a process policy is just a decision, an answer to a question Like what do we do with blocked work? What do we do with aging work? What do we do if something like a defect arrives? What do we do if we have items with different priorities? How do we manage work that has the same priority? Which one goes first, which one goes second? When is the right time to escalate something? Who is the right person to escalate it to? Those are our process policies, our decision-making frameworks that first enable autonomous teams, meaning they know what to do in every situation, especially in urgency situations, and second, it sets a base for us to keep improving our workflows. If something goes outside of our thresholds, and we have like big red zones that show us that something goes outside of the thresholds, as soon as this is the case, we start talking about this and then we try to understand what was it that actually led to that result? And usually it's something in the policies or the fact that we didn't have a policy about that use case. Those cases are feedback for us. We use that, we use those situations, these outliers, as a feedback loop which fits the rules and the changes we want to apply. On the rules, because those decision-making frameworks are owned by our teams. They create them, we don't create them. The teams create those decisions. They make those decisions because they're in the best position to do so. They're in the trenches all day, in and out, and they know what's best for it. And when they create it and when they own it, there is no reason for them not to follow it. When they see those outliers, what they do is they start brainstorming. Okay, what is it that led to this situation? Can we change something on our policies in order to make sure we don't end up in that situation again? And simple things like we didn't have enough information in order to resolve that problem. Well then, let's change the policy that a task can only enter the workflow if you have this and this and this available. You just don't start the work until you have those three points there. That's how the team is actually embracing these cases, and it is because it helps them do their job better. It helps them to be better at something that they're not individually influencing, but they influence as a team.
Speaker 2:That's one of the reasons why I'm so focused? I'm not focused at all on individuals' performance. That's something that we don't care. That's something we don't measure in our tool. There is no place where you can actually track individuals's performance. That's something that we don't care. That's something we don't measure in our tool. There is no place where you can actually track individual's performance. You can only track team's performance, because it's a collaboration that is needed in order to go out with something, because it doesn't matter how efficient your developers are. If everything gets stuck in the testing phase, you're not delivering, you're not bringing that piece of value to your clients, and when you don't, what's the point right?
Speaker 1:I'm glad you brought that up about the policies, because that is very, very helpful to the teams, very, very helpful to the teams, and I would say yes. And the part that I would like to add is I've seen some teams be so obsessive over making sure they get those policies right up front. Those evolve over time. You cannot foresee every possible combination that's going to happen. So take your best shot up front, set your policies on how you're going to handle work and if something arises, hey, you've got a retrospective. That's a great topic to talk about. How might we update our policies to prevent this from happening again in the future? So too, they're so anxious and so worried to make sure they get all the policies right up front. You know, even within our own society we have to amend laws right, so it takes some time for those to come up and to get those just right.
Speaker 2:This is good. I actually love this because, indeed, those policies, they're not set in stone, they're a living thing, and it's not just with policies, it's everything steady in stone they're a living thing, and it's not just with policies, it's everything.
Speaker 2:If you start thinking on something big and then in the middle of the process, it turns out that it's way more complicated than you initially thought, of course you're going to split it. Of course you're going to change the scope or cut some of the scope or even add more to the scope. It's a living thing. The policies are a living thing and you should change them. They have to change. If you don't change them, something is going wrong. You have to change them because things change around you. Your clients change, the market changes, the environment around you changes. Your policies have to adjust based on all of these changes. So, absolutely, those are living things.
Speaker 2:And back to your initial question mark how does that lead to transparency without micromanagement? Well, first of all, you don't care anymore about individuals' performance. There is no place for that. Second of all, with all that being said, all the policies, all the rules in place, you have your autonomous teams. You have teams who understand how to do the work in the best possible way for the business and for their customers.
Speaker 2:And third, the C-level and the management level. They have that understanding of what delivery means. They have understanding about what's their time to market. They have understanding of how much work they can handle at any one time. They have understanding of the capability of the team, which is the most important thing in order to know when to say yes and when to say no to. In the end of the day, it's a very beautiful picture, because everyone is happy, your teams are happy, your management is happy, your clients are happy, Because the biggest advantage of focusing on flow and flow metrics is that the focus is on the end customer. It is on how much time you make them wait in order for them to get what they asked for, and that's all what matters in the end of the day.
Speaker 1:So, sonia, what about that CEO, that COO, that customer that is waiting for, let's just say, the delivery of a system and, right or wrong, the system can't go out partially, it has to go out as a whole. You're delivering value every week, every two weeks. What have you? It's not going to be released until the whole system is there and you've got this CEO that's asking you okay, I hear all that you're saying about this cycle time, about this value, about wait time, but when's it going to be done? That's all I want to know is, when is it going to be done? And they're so high up in the corporate structure that they really don't want to know in the weeds. They just want to have that one answer. How do you answer that and how do you approach that type of stance?
Speaker 2:I have a very special opinion when it comes to making delivery predictions. I'm a strong believer of the concept of probabilistic forecasting. What is probabilistic forecasting? It is the understanding that there is no one single certain answer to that question. When will this be done? Probabilistic forecasting gives you a range of delivery times and a probability of achieving each of them, and the question when will this be done is no longer that interesting, because we have the tools In our analytics suite. We have the tools. They're called Monte Carlo simulations. They take your past performance data. They run millions of simulations based on what you've done so far in order to give you those dates. So you can simply use your past performance data in order to come up to the answer when you will be done right. And then the Monte Carlo simulations, the probabilistic forecasting tools, are going to give you that answer. They're going to give you five days and the probability of hitting each of them, and now it's up to you to decide.
Speaker 2:How much risk are you willing to take? Your job now is to make that decision. Is the work easy? Have you done this this before? Do you expect any challenges along the way? Are there a lot of unknowns? If that's the case. If it is like very important to hit that end goal, you go with a higher percentile. The higher the risk, the higher percentile. Then you choose the date that's like at the end of that range.
Speaker 2:If the work easy, you have confidence that you can deliver, you know that even if you don't get to that place, it's negotiable. You go with the 70th percentile and then you go and choose a date that's earlier. That's how you make your commitments. You use probabilistic forecasting that's based on facts and not judgment or gut feeling. You use your past performance data in order to come up with that date and from then on you start running that forecast every two weeks. That initial commitment is just that, your initial commitment. Your work hasn't been done just yet. Your work is just has started. So you have to keep running that forecast every two weeks, taking into account what you've done in the past two weeks, and you make adjustments based on the feedback that you receive.
Speaker 2:So if it turns out that the probability of hitting your initial goal is getting lower it's not 98% anymore, it's 90% or even 80%, even 70% what is it that you can do? Can you cut the scope? Can you add more people? Can you reduce the work-in-progress limit so the team can really focus on what they're doing and not doing another 100 things a part of it. What is it that you have to change in order to get back on track?
Speaker 2:You keep changing the process. You keep running every two weeks, even if at some point it turns out that you won't make it on time, and at least you can communicate this early. You can go ahead and say, hey, here is the situation, we won't make it, let's make a decision now so we don't impact the business goals that you have because of that commitment. That's how you build credibility. That's what builds your reputation as a professional Making those decisions and having those conversations, because you cannot predict when you will be done. There is just no such thing as 100% certainty that something will happen in the future. The best thing you can do is to stay flexible and put your hand on the work and keep running those simulations in order to make sure that you'll make it on time.
Speaker 1:That's really good. I've often found that giving people options to be very powerful, because when you just say, like, when someone says are you going to have it done by this date, to just say no, there's some level of rigidity to that and you typically don't get a good response. But if you give them options, like you say, hey, well, if you would like to take on the risk of we've got a 50-50 shot at making it as of this date, what would you like to do? Can we cut scope? Are there some pieces of this that we could deliver later?
Speaker 1:And one of the things that I like to do when I prioritize features to be included in a delivery is I like to go by them one by one, because typically your response is going to be, as you go through this list, stakeholders will say, yes, I need that. Yes, I need that. No, I can't live without that. Say, okay, let's look at this a different way. If I were going to tell you that I was going to deliver everything on this list except this one feature, would you release? Would you go live with it?
Speaker 1:If the answer is no, we need to hold everything, all the work that we've done. We're going to hold it off until we get this done. And okay, that sounds like something that you have to have. But if you turn the perspective just a little bit, sometimes you can get a different answer of well, so you're telling me, I can get all of this in, but I have to wait on just this one. No, we can live without that for another month. Yeah, let's do that. And so you can kind of start de-scoping some of those things that once felt like a must-have now turns into well, maybe we don't have to have it, maybe we can bring that in later. But I love the idea of giving options because that makes someone else feel like they have some power in the say right. They have some power in the say right. They have some choice in the decision, not just be told no.
Speaker 2:And it's their decision. In the end of the day, it's their decision. You can even go ahead and let them choose the end days. You can just tell them okay, these are the risks that are coming with these delivery days. Just pick how much risk you want to live with. And just for the record, 50% certainty is like very low. For me, 50% certainty really means we either make it or not. I would never commit to the 50% chance of hitting a target because, like you, you're better off just buying a pair of dice and trolling them Right.
Speaker 2:Um so never do that. Always go with at least 70% chance that you can hit your targets. The most important thing for me is that when you take action and when you have these conversations Because if you have these conversations as soon as the due date arrives- you lost that game.
Speaker 2:You have to be upfront with this, you have to be aware of it way before you hit that deadline. So take advantage, take advantage of all the tools that would give you that information real time, and make sure you put your finger on the pulse of the work, because, again, this is the difference between professionals and amateurs Even if things don't go the way you expect them to go, if you're upfront about it and you're transparent about it, that's going to make the whole difference.
Speaker 1:Sonia, this has been absolutely fantastic. I really appreciate you coming on the show. If our listeners out there want to get in touch with you, what's the best way for them to do that?
Speaker 2:I'm on LinkedIn, sonia from NAVE. I would love to hear from each and every one of you. I do want to know what's the biggest takeaway from today. I do want to know what is it that actually sparked that thought? Because, mark, I want to be honest. I love I can talk about this all day long, but the most important thing for me is when people take action. So, from each and every one of you, go ahead on LinkedIn, send me a note. I want to know what's the next thing that you're going to do as early as tomorrow morning. What is it that you've learned today that you're going to go ahead and apply as early as tomorrow morning in order to move the needle? Let me know.
Speaker 1:Okay, listeners, that's a call to action. All right, Sonia, it's been a pleasure. Thank you for coming on the show. Really appreciate it.
Speaker 2:Thank you.
Speaker 1:And that ends another episode of the Agile Within. We'll see everybody next time. Thanks for joining us for another episode of the Agile Within. If you haven't already, please join our LinkedIn page to stay in touch. Thanks for joining us for another episode of the agile within. If you haven't already, please join our LinkedIn page to stay in touch. Just search for the agile within and please spread the word with your friends and colleagues Until next time. This has been your host, mark Metz.