Episode_9-Lucy_O_Keefe-Ready

In this podcast episode, Liz Crescenti and Marco Bonilla are joined by Lucy O'Keefe, the CEO and founder of Dart Frog Consulting. They discuss the role of Agile in continuous improvement. Lucy shares her journey of how she got into Agile and Scrum, starting from her background in software development. She explains how she became passionate about Agile and its benefits for teams and organizations. Lucy also talks about how she introduced Agile practices in her workplace gradually and saw the positive impact it had on project delivery. She emphasizes the importance of continuous improvement, feedback loops, and customer delight in Agile ways of working. The episode concludes with a discussion on the definition and benefits of Agile. Welcome to Lean into Excellence, a Workstream Consulting Podcast. I'm Liz Crescenti. And I'm Marco Bonilla. And we will be your hosts as we embark on our continuous improvement journey. Welcome back to another episode of Lean into Excellence. I'm Liz Crescenti. And I'm Marco Bonilla. And today's episode is extra special. It's our 10th episode, so we are so grateful and thankful. We've made it this far, so thanks for all our listeners. And we also have Lucy O'Keefe joining us. She is the CEO and founder of Dart Frog Consulting. And we are going to jump into Agile and its role in continuous improvement. So very excited about that. Lucy, welcome to the program. Thank you. Happy to be here. Yeah, so to give people a little bit of background, Lucy and I have known each other three decades, just to round down a little bit. So three decades. And I had the pleasure not too long ago, about 18 months ago, to sit in and get certified by her as an Agile Scrum Master. So, Lucy, why don't you tell us a little bit about yourself and how you got into this world, right? Because obviously how we start isn't how we end, right? Yep. That's our experience, so. Yeah, exactly. So, I mean, funny story. I went to college and I wanted to be behind the scenes. So just me and the computer, to be honest, because I was very shy. I didn't want to have to talk to people. So got my bachelor's, you know, in systems analysis. My master's in management information system. Started as a software developer and I was really happy not having to deal with people. And that was back in 94. So I'm aging myself a little bit here. But then back in 2012, I was a business systems analyst at a company in Charlotte, North Carolina. And I went to a conference for business analysts and project managers. And I went into this talk and this woman was talking about Scrum. And I sat there and I was just thinking about, you know, how different Scrum was from Waterfall, what I was used to doing. You know, in IT, that's what we did. And I was doing that for almost two decades at that time. And how much better it would be if we adopted Scrum in Agile ways of working. And I got back to my company and I said, we must try this. So I started just borrowing some practices from Scrum and adopting those in the Waterfall projects that we were working on. And the company saw the benefits of it. We started, you know, just doing Scrum within our teams. And that really brought me out of my shell, to be honest with you. So, you know, anyone that knew me when I was in my early 20s knows, you know, that I was I would not be the type of person I would be here talking to in a podcast. I would be speaking in conferences that would be training people because that's not just who I was. And Scrum completely changed my life because I am just so passionate about it and what it can do for teams and organizations. And, you know, through, you know, working in the team as a developer first and then as a Scrum master, it just really helped me see how important it is for people to work in an agile way of working, if you will, where we are focused on continuous improvement, where we are, you know, continuously replanning to make sure that we're delighting the customer. Right. It's not about what it is that we're doing, you know, for ourselves within the organization. And, you know, I ended up getting some certifications, the CSM certified Scrum master, which is the one that I certified you on. And then a second certification, which was the product owner. And I just loved how my instructor was was doing the class. And it turned out that she is she has been my mentor for seven years now. Her name is a new Molly, which you've met as well, Marco, in that class. And I just wanted to do that. Like, I just love the way that she was able to influence people and help people reach their goals through Scrum and through Agile. And that's what I decided that I wanted to do. And and here I am today. Right. I'm a certified Scrum trainer. I'm a certified team coach with Scrum Alliance. And I just love helping people, you know, see what Scrum and Agile can do for them. Not just at work. I mean, of course, at work, because that's that's the majority of what people learn Scrum for. But but even in their own lives. And I use, you know, Agile concepts in my own life as well, you know, to manage things that I need to do for myself. So that's that's how I got here, I guess. Lucy, let me ask you a couple of questions to get some thoughts. So you went to a conference, you heard about Agile and obviously it's usually on the surface, right? It's usually not a deep dive like what you did. What about Scrum or Agile hooked you on that first the first time you heard about it? For me, it was common sense. You know, having worked in Waterfall for so many years and seeing the struggle. Right. And the fact that, you know, I have worked in many, many projects. None of them were ever delivered on time, on budget or on scope. Because it's just not a great way to do software. And everything I saw about the continuous improvement and feedback loops and doing it a little bit at a time, starting with what you know, right, and getting feedback and not worrying about scope creep. Right. Because we want to make sure that we're delighting the customer. It just made sense to me that that was the best way to to do software and not just software. Right. I can use Scrum for many, many things. But just the common sense of it all is what just, you know, that light bulb just went off in my head when I heard that. And, you know, and I love, you know, developing and coding and all of that. But it was just a much better way of collaborating with other people to make sure that we're delivering the right thing. And Lucy, with that said, you talked about taking some of the techniques and bringing it to the workplace. So you came from a conference, you brought it to the workplace. Culturally, was it a challenge? Because, you know, sometimes we try to introduce continuous improvement on different levels. We say it all the time. It's uncomfortable. It's uncomfortable, right? But for the most part, for the good, we have good intentions. How was it for you that first time you said, you know, I just came from a conference, I learned all these potential applicable techniques to our world. Yeah. How were you able to get people on your side? Were you, you know, were you fighting it the whole way? Yeah. Any roadblocks or hesitation? Yeah. So the thing is, just like any habit, right? If you want to start a new habit, you're not going to start 20 at the same time. So the key thing for me was I wasn't calling it Agile. I wasn't calling it Scrum. I was just, you know, trying to say, I learned these things. Can we try a few things? So the first thing we did is we got the BRDs, the business requirements document that we had. And I was like, OK, can we translate these into user stories? Right. So we did that. Great. Then we were working on this a little more and I was like, can we meet every Monday? And developers, can you tell us which one of these you want to work on this week? And they would. And then a week later, I was like, can we start meeting every day just for 15 minutes? You know, just to make sure that everybody knows what's going on. And we started doing that. And then it was, you know, the last thing was, can we meet every Friday and just review what you guys coded during the week? And, you know, and see, you know, if we have any defects, if there's anything that needs to change. And everybody was fine with that, because once again, I wasn't trying to completely change the way that we were working. I was just introducing little by little new habits. Right. And at the end of that, I think. And for some reason, this is a number that keeps, you know, that stays in my head is we had 13 defects at the end of the project. If you've worked in software at all, 13 defects is amazing. Yeah. It's nothing. It's a home run. It's nothing. Right. But why was that? It's because we were meeting every week to see what was being delivered. Right. Because we were able to get that feedback. It wasn't from stakeholders at that time. Right. But from the rest of the project team and and then everyone saw the benefits. Right. So it wasn't me coming in and saying, we must do Scrum, we must work in an agile way, please learn Scrum. It wasn't that. Right. Because I hadn't really learned Scrum. But it's like, oh, I know that there are these practices. Right. And these events and we used to call them ceremonies back then, you know, that we do is like, how can I incorporate that into a waterfall world? Right. In a way, that's going to help us improve a little bit, you know, the way that we are doing our things. So that's how that happened. That's fantastic, because so many people, you know, learn something new and they just want to run with it. And you just kind of slowly ease everyone into it. It's almost like they were doing it before they realized they were doing it. And I think that's just a really smart way of just kind of approaching any type of new behavior. So that's fantastic. One thing we haven't done is define what agile is. I was just going to say that. Because people are going to be like, what are you guys talking about? Let's start from the beginning. Let's take it on back. Right. Right. So, Lucy, in a small paragraph, what is agile and why do you see the benefit? What is it that it does for you or for a company, I should say? So it's funny you're asking that question, because just last week, one of the signatories of what we call the Agile Manifesto or the Manifesto for Agile Software Development posted something on LinkedIn. Somebody asked them what agile is and what he said is agile is early delivery of business value with reduced bureaucracy. And I don't think I can come up with a better definition of what agile is than that. But, I mean, of course, if you go and read the Agile Manifesto, you're going to see that agile is a set of four values and twelve principles. It is a mindset and it's really focused on delighting the customer, on empowering teams, right, on self-management, better ways of working. Right. The common sensical stuff that I talked about earlier. Right. So that's that's what agile is. It's not a methodology. A lot of people think, oh, it's an agile methodology. No, you can't do agile. Right. Agile is something that you are. It's something that you become because you are demonstrating those values and those principles that I talked about. And, of course, you have all these other practices that come under the agile umbrella. But agile is just these four values, these twelve principles, and it's all about delivering high quality products as fast as possible so we can get feedback and improve on whatever it is that we did before. Yeah. And exceeding expectations, right, is what you're doing. I mean, you're not just delighting, you're really exceeding. Yeah. I mean, that and that's key. Right. Right. And if I if I may. Right. And it's usually in the form of on time delivery. Right. Quality. Really, the two big things and safety is the third. Hopefully, I don't know, in a software world, but safety is something what we think about in a product development world. Right. On time delivery and quality. Right. Least amount of waste to get the biggest bang for your buck. Right. Right. Yeah, exactly. So it builds on lean thinking as well. Right. So the removal of waste is huge when we're talking about agile. Right. Focus on the most important things. There's actually a principle in agile that it's called simplicity. The art of maximizing the amount of work not done is essential. When I first heard that over 12 years ago, I was like, what the heck does that mean? Right. I guess the simplicity is essential, but maximize the amount of work not done. A lot of people don't think about that, about how much we gold plate. Right. How much we do things that we shouldn't be doing. And that's why a lot of projects just last so long, because we are working on low priority items that aren't bringing a lot of value. So when we're talking about agile, it's all about bringing value. Right. So I've worked in agile products where we didn't deliver even half of the requirements, if you will, because they weren't that valuable. And we got to a point that because we did deliver the highest priority items first, the product owner or the users, customers, stakeholders are like, we don't need anything else. You know, you've delivered everything. We can do our job now. We can use this software that you've created to do what we need to do, to do what we need to do with it. Why continue to spend money and spend time? So, you know, and that product specifically, we finished months in advance, which is something you don't see in the traditional world. Yeah. So in my world, sometimes we talk about analysis paralysis, where they want the product out the very first time. And we know you're never going to finish a development cycle if that's the case. Right. We'll get on the next iteration, which is perfect if you hit all the major points. Right. All the high quality, high value target. So, you know, let's talk about that a little bit more. You mentioned the customer a lot. I'm going to loop back around to the design side in a second. But how important have you seen, especially taking the tactic of implementing the stakeholder into the process? So I'll give you an example. So I teach design thinking at the universities. Right. And that's really, you got involved the stakeholder from day one. Right. And in the product development world I came from, of course, started years ago. We weren't so, I shouldn't say interested, but once they gave us specs, right, we call them specifications. They left us alone for months, which is very dangerous. Right. No updates. No. Here's our results of what you gave us six months later. And they're like, well, yeah, you met some of the technical needs. Right. But because it wasn't that interaction with the stakeholders, we didn't really get down to the fundamentals, what they really needed. Right. Versus wanted. Right. You know how the language goes. So tell us in your world, since you switched to this new concept of introducing a better flow and incorporating stakeholders, how's that worked out for you? And why is it so beneficial to bring them in sooner than later? Because we want to make sure that we give them what they need. Right. So, you know, you know this. I know this. You know, when we're working the traditional way, as you said, we talk to stakeholders in the beginning. We gather the requirements from them and we don't meet again until it's over. Right. Oh, you think it's over? Yeah, exactly. Exactly. So I say this in all my classes. I do do a comparison between traditional or waterfall and agile. If people knew exactly what they wanted. Right. If we were that clairvoyant that we can tell what we need 18 months from now, we'd all be millionaires. Right. And we wouldn't need to be doing what we're doing. But we're not. Humans don't know what they want until they're able to see it. Right. So I'm sure you've seen it as well, where, you know, we have a project that goes for 18 months. We deliver the project. They're not delighted. Right. Because it's not necessarily what they want. It's what they thought they wanted. But when they start using it, it's not really what they wanted. It's not meeting their needs. And, you know, we've done studies and checked how it was being used. Maybe 50 percent of the features are being used. Right. Because we didn't have that conversation. And agile is completely different. So actually, one of the principles in the agile manifesto is that business people, business people and developers must work together daily right throughout the project. Why do we do that? Because the product is for the customer. It's for the stakeholder. It's not for us. Right. Right. We're not the end. Exactly. So unless we understand and get the feedback from them as often as possible, we're not going to be delivering what's truly needed. So, you know, there's various ways that we do that in agile and more specifically in Scrum. And I'm just talking more about Scrum because that's what I do most of the time. You know, we have what we call sprint reviews. Right. So at the end of every sprint or iteration, we get together. The stakeholders are there. We do a demo of a usable product. Right. So we create a usable piece of that product, which we call an increment. Then they can see it in action, if you will. Right. And they'll tell you, oh, that's great. Or, you know, can we tweak this a little bit? Can we change this? Can we do that? Right. And then we go back to the drawing board. We iterate on that. Right. And then, you know, and then we review it again next time and next time. And by the time that we finish this whole product, there is very little that they don't like because they've been a part of the process. So, Lucy, one of the things I try to iterate with the classes we teach in Lean Six Sigma is that, you know, if there's a defect in the process, we don't want to keep it going. Right. Because the longer it flows in the process, more time is wasted, more resources wasted, and eventually you just got to bring it back. Right. So the concept of failing fast. Right. That came out of the software world. You want to know if something's defective, stop right now. Right. So how does that work in the agile flow? Yeah. So the funny thing about that, I just want to bring this up as well. So if you're familiar with the Toyota production system, right, that is something that they did there as well. Right. Where they finally said, you know, we want to stop the process as soon as we know that there's something wrong. Right. So they gave everyone the ability to hit this button that would stop the production of the car so they could fix the problem. You know, so that's part of Lean, of course. Yeah. Not passing the buck. Right. Yeah. Yeah, exactly. Let's not wait until the whole car is done for us to take it apart and fix the issue. Right. So, yeah. So we do the same thing here. And that's why we work in iterations and iterations are just short, you know, spark of time, if you will, that you decide how long a team want to go to create a part of this product. Right. So if we work in short iterations, we are going to learn very quickly whether we did something bad or something wrong or that we're failing. Right. The longer your iterations are, the longer it's going to take you to figure out that there's something wrong. And going back to what you said, the more costly it's going to be to go back and fix the issues. Right. So we do advise people to have shorter sprints or shorter iterations, if you will. In Scrum, you're able to have up to one month iterations. I think that that's way too long. Right. If you're waiting four weeks to one month to get feedback on something you did on week one, then it's going to be the same issue. Right. We've already forgotten what it is that we did. So it's going to take us longer to fix it, longer to fix the issue. And then we're not going to get feedback again in another four weeks. So those feedback loops that we get are going to help us with that failing fast idea. Right. That you were talking about where let's find out as soon as possible. But not just that, not just the feedback from the stakeholders, but on a daily basis, the team itself should be having those conversations and figuring out what's working and what's not working. And that's why we meet daily for 15 minutes or less to inspect where we are and make sure that we are progressing in the right direction. Yeah. And like you said, 15 minutes or less. So it's not like someone has to think, oh, I got to meet with them. It's just another meeting every hour or day. It doesn't have to be. It can be, like you said, 15 minutes or less, but you're on the same page and it's going to avoid the disturbance later on. Yeah. And being transparent, right? Transparent about what's going on. Yeah. That way we do find out as soon as possible whether there is something headed in the wrong direction so we can pivot at that time and fix that and adapt our processes accordingly. Yeah. We say in class a lot of times, you know, speed without quality is just making more stuff without saying the word. Yeah. You know, just fast. Technical debt. Yeah. So a couple of things. You know, I don't know where I got this a long time ago. The four pillars that I always teach in class is safety first, right? Safety, quality, speed, right, without affecting the previous two, and then cost last, right? If you get the safety, quality, and speed in those orders, the cost will work itself out, right? Yeah, exactly. But you don't want to put speed before cost because, again, you're just producing more stuff and you can't sell, right? I mean, you have to scrap – in our world we call it scrapping, right? We have to literally physically take out and throw it out the window, right? It's just not beneficial. So, I mean, the concept you talk about is fantastic, right? These stand-up meetings, we call them stand-up meetings because literally we don't want anybody sitting down and getting uncomfortable, right? We don't want to talk about what we need to attack today or correct, right? So these short sprints. So you mentioned sprints before, but we haven't defined what a sprint is. Can you kind of cover that, Lucy? Yeah, sure. So, as I said, it's one to four weeks. The team should be able to decide. Sometimes organizations do dictate what that is, but the team should be able to decide how long those iterations are, that timeframe is, you know, enough time for them to get the work done, but at the same time shorten those feedback loops that we're talking about. So a sprint is where, you know, a team gets together – and this is in Scrum, of course – where a team gets together to turn ideas that exist in what we call the backlog, right? That's where we hold all the requirements, if you will, into value, right? So this is where we're actually creating those increments of the product that are valuable to our clients, right? So within that sprint, there's various things that we do, but, you know, the majority of the time is really working towards creating that increment that's going to create value for the customer. And as I said before, the shorter it is, the shorter your feedback loops are as well, right? So if you have to fail fast, you want those shorter sprints, right? If it's something that it's okay to go a little longer, you can go a little longer, right? And, you know, the most popular sprint length is two weeks, which I think is pretty perfect, to be honest, because I think it's just the right balance of, you know, having a good amount of time to do the work but then having those short feedback loops as well. But, yeah, so the sprint is just that amount of time that a team decides that they're going to focus on a single objective and then deliver that value at the end of that iteration or that timeframe. Yeah, Lucy, I want to ask you, you know, the reason you and I exist is because a lot of companies still haven't adopted continuous improvement techniques, let's call it, right? Whatever that may be. Yep. Yep. Yes and no. So I have to say that there is a lot of resistance to change, like we talked about earlier, you know, and a lot of times they just don't understand why it's important for them to be a part of the process. So if they are not educated for them, it is an annoyance, to be honest. I've seen that in organizations where they're like, I don't want to go to a meeting every two weeks. Why do you need me to be there? I told you what it is that I want, just deliver it, right? Because they're used to that old way. Yeah, exactly, right? But I think what has happened in a lot of organizations is once I – because I like to do some training with stakeholders and leaders so they understand what's in it for them, right? And the majority of the time they don't know what's in it for them and they're like, this is just a team thing. But once they do understand that, once they do understand the agile mindset, if you will, and they see how beneficial that can be, right? I think that they're then more willing to come into those review meetings, if you will, right? And have those conversations and give their feedback because they know that based on their feedback, we're going to be able to deliver better products. But there is a learning curve, if you will, right? Once you go into organizations because they're so used to that old way of doing things that, you know, I mean, it's easier, right? Let me just tell you everything today and 18 months from now, just give it to me. I told you what I want, right? They tend to forget that they never get exactly what they need. Right. I can imagine that once they go through it once with you and see the benefit, right? The benefit of what they've gained compared to what they've gotten in the past. Like you said, go over the fence, get to the end. They have to accept what they got because either they're not going to spend anymore, what we call NRE, which is engineering, you know, development. And they just got to get into the market because they're too late. They're already behind the ball, right? Yeah. So once they run through this once with you and they say, you know what, we saved, I'm making up a number, a third of the time, a third of the cost, a third of the frustration, they actually got what we wanted. It's worth it on our end to be part of your team, your development team is kind of what they are, right? You pulled them in. Yeah. I bet. I mean, I bet, yeah. Yeah, I bet. They want to see the benefit before they actually, you know, adopt it, you know. I'm sure repeat customers, it gets quicker and quicker to bring them in once they've been, once they've seen the benefits. Right, yeah, yeah, yeah, for sure. And a lot of it has to do with the culture of the organization as well. Again, yeah. And I'm sure that varies everywhere you go, so. Yes. Fighting culture is a huge upstream battle, right? Yeah. Yeah. I mean, yeah, I tend to say that, you know, teams can do Scrum or whatever other framework they choose until they're blue in the face, but if the culture of the organization doesn't change, you're never really going to see all the benefits that you can get from working with them. Right, right. Yeah. So let me switch gears a little bit, Lucy, right? So we talk about the client or the customer, right? Because we're here for them, right? We're here to exceed their expectations. But let's talk about some of the challenges we get from the inside. So I'm going to give you an example, right? In the Lean Six Sigma world, we have development techniques too, right? So most people think of Lean Six Sigma on the operations side. After a product's been developed, how do we minimize process inefficiencies and waste, et cetera? We also have techniques on the front end. One of the challenges we have with designers, and maybe in your world it's called programmers, correct me if I'm wrong, that they feel that some of these techniques are a hindrance to their creativity, right? Because as you said, right, they want to be left alone. You were that kind of person. I'm a STEM, right? We come out of school and we just want to be put in a lab and just leave us alone. Yeah. But they consider these techniques or these flow mechanisms to be a hindrance to their creativity. It's going to get in their way. How have you addressed that? I've never heard the side of it's stifling my creativity or anything like that, but I have seen where a lot of them will say that there's too much overhead. There's too many meetings, right? There's too much this, too much that. I just want to sit and do my job and get that done. I don't want to have to come and talk to the other developers. I don't want to have to come and talk to stakeholders. And that's like the hardcore, what we used to call programmer, right? Right, right. You know, they feel like that. And, you know, there are some people that you're not going to change their mind. You know, I've come to to acknowledge that because it does get very frustrating. If you do try to change everybody's minds, you know, you can't change people unless they want to be changed. Right. But a lot of times, again, once they start seeing the benefits of working in a more collaborative way. Right. You know, I think that they start, you know, coming to the lighter side of things. Right, right. Right. Yeah, but one thing with Agile, whether you're doing Scrum or Kanban or any other framework, is that it actually allows you to be more creative and allows you to be more innovative because it is an experiment. Right. We are experimenting every single time. And as long as the culture within your organization allows, you know, allows you to fail. Right. But as long as there's no repercussions, if you do fail, I think that teams see that they are able to innovate more and to be more creative because of that experimentation that that happens. Right. So I don't think that that suffers for me. It's more, you know, they think there's too much overhead. I don't want to go to meetings. I don't want to talk to anybody. I just want to sit and do my work. Sometimes they're just not customer-facing individuals. Right. They're just not people people. Right. Which is fine. I mean, it's not a judgment on them. That might take some training, too. It's like, look, you know what? This isn't going to happen less. It's going to happen more. Right. Right. So, again, at STEMs, we tend to have that individuals from like the Big Bang Theory show I like to reference. Right. Right. They just want to do what they do. And understandably, right, that's what they were used to and that's what they expected when they were in college. That's why they went down this path. But you can't ignore the customer. Right. Because without a customer, you don't have a business. They don't have a job. There's no business. Right. And tinkering or being part of a, what do you call it, like a new concept development with no customer at the other end is not realistic. There's very few of those. What's the point? You run a business and you know what? The customer has the last say, right, if he's going to pay for what you're doing at the end of the day. I mean, they're paying along the way, but are they going to take that product and run with it, right, to the industry? So it's really interesting. So I guess it's shifting gears again. You know, let's talk about leadership. Right. Adoption. Because some of the issues, it's not getting the people in the trenches, you know, who are going to be using some of these techniques. It's spreading that culture, getting leadership to say, hey, you know, this is the way we want to go. And you need them for long-term commitments, right? Because if you get those in the trenches like yourself and myself, like we've been there, we adopt some of the techniques and we keep using them, but we don't have the support of the greater picture, right, for long-term generation. How important is the leadership all the way to executives, right, at the top of the team? Yeah, I mean, it's key, right? Like I said before, teams can adopt Scrum or any other framework and do the practice, right, and practice, you know, the things that the frameworks tell you to do until they're blue in the face. But if there is no leadership buy-in, if leadership doesn't feel that it's important to change the culture, again, you're not going to see all the benefits of working this way. So I did work in a company where they decided that they were going to become an agile company, and the CIO was very clear to the point that it was almost, if you're not on board, here's the door. Yeah, go find another job, right? Which I think is awesome, right? It's awesome that somebody can be so bold. You don't see a lot of that in many organizations. No, you don't. But for me, that shows the commitment that the organization has, you know, in order to make this change, right? It is a completely different way of working. It's a completely different way of leading. It's a completely different way of engaging your employees when you are an agile organization. So if you don't have that coming from the top, you know, a lot of times there's going to be fear within the teams, even if you are an awesome Scrum Master, right? Like, I was a very disruptive, bold Scrum Master. Not disruptive in a bad way, but trying to keep it in a good way, right? Yeah, in a good way, yeah. You're trying to innovate. You're trying to innovate within the, yeah, sure. Yeah, but if you're that type of person that you're trying to do your job and help the team become more efficient, and the team is afraid that if they go with what you're saying, they're going to get reprimanded or worse, right, by the organization, they are not going to change the culture within the team because the organization is not headed in that direction. Yeah. So we do need leaders to buy into this. And there are like agile leadership classes that leaders can take, right? So they understand what it's like to lead an agile organization. And I think that if there's any organization that's serious about having their teams work in a more agile way, that their leaders need to go through a class like that and understand what does it mean, right? What does it mean to my organization? How is that going to change how we work? How is that going to change how we manage people, right? Because it is a very different way of doing that. So buy-in from leadership for me is key for a company to be successful in adopting agile ways of working. Yeah. And I think we actually just had an episode on data storytelling, but just kind of painting that picture, especially for leadership of what's in it for me to show them, you know, this is what is going to happen by implementing this new way of thinking. So everyone's always wondering, you know, basically picture yourself as the hero. This is how it's going to help you in your organization. It's just, you know, just important to have their buy-in, absolutely. Yeah. And, you know, to speak to the language, you know, they're looking at strategic partnerships and increasing revenue or quicker to that revenue that they had promised right there to the stakeholders. So, you know, you really got to sell the benefits, right? And they're there. It's not like it's a smoke screen. They're really there. But you have to get, you got to grease that wheel and you got to get that engine moving, right? Yeah. So, I mean, I was coaching a company that does work with the government. They contracted the government, like the U.S. Army and and like building planes and stuff like that. And they wanted to know, you know, why do I need to do this? And the first thing I did is get some case studies and say, here, here's how they're using in the military. Right. Sometimes they just got to, you know, they just got to see that it's been successful elsewhere in order for them to adopt it. So, you know, if you are going to an organization and trying to sell this whole agile thing, and I don't mean sell because we don't make money by selling. Well, you know, you know, I think it's important that you, as you said, Liz, you know, that they understand what's in it for them. But also, how has this worked in other organizations such as mine? Because not everybody is a software development company. Yeah. And I've seen it work in, you know, many different types of organizations, but it's important for them to know that, you know, it is possible to work in this manner and be more successful and save time and save money by delivering earlier, you know, and seeing the benefits sooner. Yeah, absolutely. I mean, yeah, it's hard to understand what the benefits are until you give them an example or two, right? I mean, a real world example, right, where the rubber meets the road for them. Well, people always want to know, well, what are how are other people using this? And, you know, their success, you can paint that picture and they see that it can be replicated. And, you know, you just get a little further with them and a little bit more buy in. Now, just switching gears, if people were interested in, you know, becoming a scrum master, you know, getting more information, what's the best way to go about that? So I am on LinkedIn, you know, if people want to reach out to me directly. But, of course, Scrum Alliance is a certifying body that I work with and I do classes for. So if you go to scrumalliance.org, that is, you know, one place where you can find out more. And, of course, if you want to, you know, do the Certified Scrum Master, Certified Scrum Product Owner classes, I am one of the instructors that does that. You can find my name, you know, to find the course area. But once again, you can also reach out to me on LinkedIn, like I said before, and I think we're going to give them that information, you know, as you know, when we post this. And how long is the course? It is a two-day course. So it's 16 hours or about 14 hours because, of course, we take we take lunch during that time. But it's, you know, an immersive, you know, two days with a lot of activities. And Marco can probably talk a little bit to this because he was in one of my classes. But it's a very engaging way of actually, you know, learning as you go instead of just, you know, being a desk by PowerPoint and just a lot of theory being thrown at you. Yeah, I'm a believer because if you're a company out there that's having a hard time getting products out the door or delivering products to the customer in a timely manner and high quality, then you need to beef up your front end, right? This is where you kind of clean up all that waste and find out what it is that's causing you to not deliver what the customer wants, right? So, Lucy, it's been fantastic having you here. This is great. Thank you. It's been fun. And we'll have you back on further down the road, right? Yep. Sure. Anytime. Thank you so much. And you can find Marco and I at WorkstreamConsulting.com or info at WorkstreamConsulting.com. And new episodes are released every other Wednesday. And we will see you next time. Thanks, Lucy. Thank you, Lucy. Thank you. Bye-bye.