When Agile “Doesn’t Work” at SKILup Days 2024

All right. Well, thank you guys so much for coming to my talk. I'm talking about, uh, when Agile doesn't work, um, and just replies to common objections to agility.

Um, so I've been doing work with software for about 12 years. Um, I see here I said primarily in agility. 'cause I've been in Agile, a scrum master for, uh, several of those years, but I've kind of dipped in and out.

There's several different roles. Um, I've been in product ownership for a while, a little bit here and there. I've been a business business analyst for a while.

I've done some software development, so I've kind of been all over. Um, and so that's kind of where, but majority of my work is in agility. So with that, um, that's where a lot of my, um, experience comes in.

I have some, some stuff to say about, um, you know, how agility works. So, um, and this is a picture of my wife and my child, just so you guys kind of know who's talking to you a little bit, a little bit of connection there. My, um, my child is here, he is, uh, three or four, I think, but he's, uh, seven now.

Um, just about ready to turn eight. So he is gotten a lot bigger, but I just really love this picture, so I just wanted to share that with you all. Uh, so yeah, there you go.

So what I wanted to hear today is, um, like I said, I've been here, uh, several years and especially in agility, and I have met a lot of people that have a lot of stuff to say about agility and why, you know, it doesn't work or why, you know, it might be good generally, but hey, it doesn't work here. And, um, and so really walking through those arguments that I've heard, and then kind of some things that I've experienced along the way that kind of serve as a counter argument. Um, so, so I've got several slides that kind of have that same format, just the, the argument and then kind of counter arguments against that, so to speak.

But then the next part is how to engage with people. Um, because when, um, when I first gave this presentation several years ago, that's one thing that I didn't really include. And I feel like now I really need to include some of that, because as I was going back to these slides, it felt a little bit like a, here's why I'm right and why you're wrong, kind of thing.

Like, Hey, agility works. You're wrong. Here's some counter arguments.

Prove that it works. And like, no, that's not really the point. That's not, I'm not here to try to be right.

I don't think anybody here hopefully is here to be, right. I think we're trying to do right for our business. Everybody cares about the business.

People that don't like agility, they care about doing things well. Um, and we care about doing things well, um, as agileists. Um, and so really just wanna make sure, like as an agile, I, I believe agility is correct.

I believe it's the right way of going about doing things. Um, I wanna just talk about how can we engage people in a way that's effective to help you under help 'em understand the benefits of agility. So, um, but yeah, first talk about the things I heard against agility, so we can kind of walk through them.

So, um, I'll go ahead and start down that path here. So one of the things that I first heard when I was starting my career was that Agile isn't really known for quality. We really need high quality.

And again, some of these things you may have heard and then other things you may be like, no, I haven't even heard that, because it, it just doesn't seem true at all. This is one thing I have heard. And just as a caveat, this is really something I heard when I first started out.

Uh, and the company I started out at was a logistics company. Um, and they were a smaller company, but they were hungry. They really, really wanted to just go after growth and go after all these new clients and grow as fast as they can, strong as they can.

And, um, and so they had a backlog of a ton of things that they really wanted to get done on our, on our products. They wanted to add a lot of new features, um, a lot of really good features we were all excited about. Um, but they wanted to move so fast and they were like, Hey, we gotta move faster.

Like, let's, let's try this agile thing. Like let's get into this whole agile thing. Let's really step that up so we can go faster.

And so, um, a lot of the dev team that I was on, they kind of equated, oh, agile is that thing where you just push so fast and so hard, you just neglect quality along the way. And so this is what I heard at that point. Well, agile isn't known for quality.

We really need high quality. We can't skimp on quality as we build this thing. And, um, you know, again, the the counter, and again, all these things, as I mentioned earlier, I wouldn't just say, here's the counter, like, this is why you're wrong.

But I want us to understand from our perspective, um, kinda what the counter is in ourselves so that whenever we do engage with people, we know what's on, what's going on. So the counter that I have for this is that without exception that I've seen, like this is true when I gave this talk. And it's, it's also true now, um, when I first get this talk that is, is that without exceptions, teams that I have personally seen, do Agile have been of much higher quality than the ones that have stuck to Waterfall, um, just due to, uh, various factors.

Um, and I mentioned Scrum as well here as if you're using Scrum. Uh, so if you're using Scrum teams can specify some quality gates in the definition of done. So those of you that use Agile, most of the time you are using Scrum.

Um, if you don't know the difference, uh, agile is a very broad term. Uh, there's, there's a manifesto out there that has four things that describe what Agile is, and then 12 principles, and that's all there is. You can read that in three minutes and you'll, you'll understand to some degree what Agile is.

Whereas Scrum is kind of one layer above that. And it's a framework that is a little bit more intense. It's not, it's not fully intense, it's only 22 pages, but it's definitely more than one page.

So it's a little bit more than Agile. And, uh, if you're unfamiliar with what Scrum is, although I can't imagine that because it's so widely used, but Scrum is where you kind of take a specific measure of time. Like two weeks is pretty typical.

You say, for the next two weeks we're gonna make a plan for these next two weeks we're gonna do that plan. And then at the end of that two weeks we have this thing, we've built this piece of software that gets integrated into our app and that piece of software we're gonna test, we're gonna, we're gonna review that with people, we're gonna review how we did our work, and then we're gonna start the whole process over again. You're gonna keep doing that time after time after time, um, until you build something great, you know, incrementally, uh, one iteration on top of another.

Um, so when you do that, uh, one thing that's really important is when you get to the end of that, of that time box, so to speak, and the, the end of that two weeks, you wanna have that thing that you've built quality. You wanna say, okay, we cannot call this thing done. We can't call this thing done unless it meets our criteria for what done even is.

There's a bunch of things that we have to have in place if we wanna call that done. And, uh, that's called the definition of done in, in Scrum. And so if you have that definition of done, you can add anything you want into it that you and your team know to be a good quality game.

So, for example, you can be like, I don't want this thing released until it's fully tested, a hundred percent code coverage. I don't want this thing out until QA has given, uh, has done a full aggression test. I don't want this thing out until, um, our, our, um, our PO has a product owner has done their due diligence and looked, looked over the whole thing.

Um, I know whatever else there is, uh, out there that's gotta go into your definition of done. So you can make sure you say that thing can't pass our, our can't pass into the, into, um, into the next stage until it meets that definition of done. So in that way, yeah, that the quality is a very big part of Scrum at that level.

And then the last part I just wanted to to touch on is that quality is actually, so it's something that's a good practice, whether it's agile or Waterfall, it's not necessarily that like, well, because you're agile, you're less quality or 'cause you're waterfall, you are less quality. Like these quality gates are important, you know, whatever you do. Um, I think it pairs better with agility though, as you see there at the bottom.

And the reason I say that is, is really because of the iter iterative nature of agility. Like if you're spending two weeks doing something and then testing it, and then even if you release it within that two weeks and then you release these small chunks of work, um, you only find a few bugs at a time and they come out iteratively and incrementally. Whereas if you have waterfall, you'll spend months and months and months building something.

And I've seen this been months and months and months building something, release it, and then a plethora of bugs come in. And that just doesn't seem quite as tolerable to users that I've seen. As you release something, a few bugs come in, but you fix 'em in a day or two, and that's like, okay, that's fine.

Waterfall, you release something after years and then it's just buggy. And people are like, well, these guys built a buggy app. So, um, anyway, that's why I think it pairs better with agility.

But either way, uh, quality is not something that I would say is anti agile or Agile is not so anti quality. It's the opposite, um, one I can see. So that's the first one.

Uh, another thing that I've seen a lot or I've heard people say a lot is that, um, you know, we developers know best. You know, we built the app, we've done the coding. We, we know what this app really needs, but uh, we lose our voice.

We give it to the business. The business just continually just in Agile. There's a product owner.

The product owner tells us everything that we need to do, and we have no voice in that. Um, and uh, that's absolutely not what Agile's about. Um, in fact, agile, one of the 12 principles of Agile said that one pager that kind of tells everything that Agile is one of those 12 principles, is that business people and developers must work together.

Um, and I, I'll keep on reading some of these things here, is if the product owner is too focused on one side, so if they're too business focused or if they're just a really technical product owner and they're just really focused on the technical side and they don't really prioritize some of the stuff that the business is asking for, um, then that's a good opportunity for you Scrum Master to get them, get involved and, and, and help the product owner and say, Hey, let's come up with some kind of a balance here. How can we make this thing work for everybody? Um, and the really key things are the bottom two, being open and building trust.

So as a dev team, you don't wanna cannibalize all the features. Kinda like I was saying earlier. There needs to be some kind of a balance there.

I have seen both sides. I have seen, uh, the business come in and say, Hey, you really need to get our features done. This is important.

We really need to get these done. And devs like, no, we can't get these done. We really gotta work on these quality things.

And then the dev side actually gets to the point that somehow they're bullying the other side and saying, no, we are, we are doing all these refactors and you're getting nothing. It's really been kind of toxic and there wasn't a lot of trust built, but that's what's really key. Building trust, being open product owners need to understand the value of the technical stuff you're doing and being able to understand the value of the business stuff you're doing, and figure out which ones are true priorities, um, and keep a good pulse on that.

So that's, that's one very important thing. Okay. Uh, next we have, uh, something that I hear quite often.

I've heard it pretty much everywhere I've worked, which is that what do you do when you finish your sprint early? You know, so they say, here's sometimes we finish a sprint early, what do we do now? It just seems like wasteful to do nothing.

We're just sitting there. We, we planned, uh, a sprint, so we're gonna do this work in two weeks and we're gonna take two weeks to do it. Well, we got it done on a week and a day.

We have four days left over. So now we're just sitting here. Well, the first thing I just, I just wanna get this outta the way.

I didn't even have this as my first point, the first time I gave this talk, but I really, I added it because it's, it's, uh, something I feel like just needs to get outta the way, which is you don't have to do nothing and you shouldn't just do nothing like that. Just that that is a little wasteful. So you're free to get a headstart on the items in the backlog.

So just because it's not in the sprint, you can go to the backlog and find some things to do and, and get started on those. The only thing I would say is a caveat is one of the benefits of having a, uh, a sprint is that you all talk about it, you plan together and you know everything you to know, uh, about it 'cause you've planned together. Um, and there's, there's conversations that happen along the way, but generally you have an idea of what you're doing.

Um, so if you do just wanna do something in the backlog, make sure that you talk it over with whoever needs to be talking to make sure that the, the product owner knows you're doing it. That, um, that it has all the details. Maybe there's something that the product owner wanted to put in there, didn't get around to yet, or whatever.

Just make sure that there's some clarity that like, I'm doing this, okay, I got, let me, let me go ahead and get started on this. But generally you're free to get head start. The point of this, of this, of the time block of the, of the sprint, um, isn't to lock out things that you, it's just to, to plan what you want to deliver.

So if you've gotten that done, great, let you know, do other stuff. That's all good. Um, but I would go on down the next point here is what is waste?

So in my earlier career, I did a lot of work with, um, with Lean Six Sigma and in the Lean six Sigma world, waste is an incredibly well-defined, strictly defined term. Like if someone were to say, what is waste from a lean perspective, you can go, ah, I know, I know exactly what waste is. In fact, there are eight different kinds of waste.

And they form a, uh, an acronym. They form the acronym downtime. You have defects over production, um, waiting, um, not engaging employees, and you can keep going down.

And, and the point of that is that you can, uh, and this is from a manufacturing standpoint, if you can walk into like a manufacturing facility and you can just look around and you can say, oh, there's inventory over there just waiting, that's waste. Oh, there's this person over here kind of just leaning against, that's waste because you've trained to kind of use your eyes to see waste. And it's a little bit different for software.

Um, we, we don't exactly, uh, have the ability to kind of just see inventory in a corner. Um, but we do as a, as a kind of a, a caveat, we do see like Kanban boards and stuff that is, is waiting in a Kanban board. So you can see some of that inventory in a digital stance, excuse me.

'cause every, every ticket that you have in your board, uh, whatever column it's in, whether it's to do in progress, those tickets, um, they represent some work that went into it. So people met to talk about those tickets, right? The business or the product owner met with some stakeholder and met with, I don't know, business analyst, whoever it is, I don't know.

But, but somebody met to build out that backlog and put a lot of effort into that ticket that is just to most people, just little couple lines on a board. But that represents a lot of time and effort. And when it's just sitting there on a board, it, it provides no value.

The only way that that value is realized is when that ticket gets developed and makes it into production, and then they can start realizing the value was created for, until then it's not producing any value. So there is legitimate waste in the sense of it's sitting there producing no value, but work went into making that. Um, so that's true, but within the context of a product waste, there's a bigger problem out there.

And that bigger problem is what if you spent all this time building the wrong thing, right? Like, what if we had the product owner, the, the business analyst, the developer, all these people meet, discuss, and build out the requirements or the tickets or whatever for this thing. And they went into the backlog and it went into development and someone spent a lot time developing it.

Then it went into code review and someone spent a lot of time code reviewing it, and then it went into, uh, QA and supposed to spend a lot of time QA that, then it went into user acceptance and, and your PO spend a lot of time, you know, you're doing that. And then it was released and all this work and all, who even knows you were to just measure the amount of touches that that went through and the amount of, uh, of billable hours that went into that. Who knows how much that would have cost to get that through.

And then you get into production and nobody uses it, or it provides no value, or it didn't do anything near what it was supposed to have done. That is the biggest kind of waste, which is building something that's just not valuable, um, building the wrong features the wrong way, the customer doesn't want it, whatever. And that is something that Agile is really focused on, is particularly have, scrum is heavily product focused, and it, it is, it does tolerate a little bit of process waste.

You know, like, it, it, it basically says that the most important thing is making sure you're delivering well, right? That you're iterating, you're getting feedback on stuff and then feeding that back into your product and then building the right thing. Um, so that is something that Scrum is heavy, heavily focused on.

Um, and maybe there's a little bit of process waste in there and that you have to wait a little while here and there. But considering what is trying to prevent, that's a tolerable, in my opinion, um, a tolerable, um, thing to, to take on. But if it is a major issue, if you're like, I can't tolerate any process waste at all, no process waste, total waste free.

Um, there are other things besides Scrum, like we have Kanban, like you're from a Kanban, it's like Scrum in some ways, but that has got, um, uh, there is usually you have like a, like a board with like to-do and progress and different kind of columns, but you don't have a sprint. You just kind of pull whatever's next on the top of the, of the lift and you do it that way. So whatever's the top is good.

So if it truly is something that's important, um, you know, there's always the ability using something like Kanban to manage your processes. All right, next we have in our business, things change so much we can't really commit to the work for a full sprint. I've heard this one, um, actually pretty often at several different companies.

And it's, it does seem strange to me because, um, the company that we started that I started with, like I said, they, they really kind of adopted Agile. Um, but when I got there, they started, you know, their agile journey, um, from like a more waterfall way of working. Um, and they were saying, well, we can't do Agile because it's too, things are too chaotic here.

And that seems strange to me because wouldn't that pair more with Agile than Waterfall? The things are chaotic, but regardless, they were like, we just can't do the sprinting thing. We can't, we can't create a sprint.

Two weeks is too, too, uh, is too short of a time box or too, too big of a time box. We need, uh, we need to just be free flowing. And um, initially my thought, my thought before I really put a lot of this together was, okay, um, shorten your time box.

If you have a two week sprint that you spend two weeks building something and then you start over and build something for another two weeks. So on, just shorten it to one week. Um, and I thought about that for a little bit and I was like, you know what though?

Um, if you can't get, if you can't, two weeks seems just like a lot. Um, so how do I wanna say this? Um, if you can't plan two weeks, it's probably a bigger problem.

Like there's a fine line, there's a fine line between being agile in the sense of like, we want to respond to change. And then it is saying we're chaotic. You know, if you're responding to change, if you have a short change window, okay, that's tolerable.

You're using agile, that's okay. If you're chaotic, you're like, I can't even plan two weeks without something going crazy and blowing up in our face. That's probably something you need a little bit more problem solving around.

Like, that's probably a legitimate problem. So like, um, I'm just looking at my time and see if I have time for the story. Um, yeah, so when I was, again, earlier in my career, one of the big things, um, somebody come up to us and said, Hey, we just, we just sold this thing, like we have to start building this today or tomorrow, like soon we gotta get on this.

And I was like, well, we gotta have some little bit of conversation around this. Like let's plan a little bit more. And, and, you know, uh, the guy who was selling it, uh, who happened to be kind of in the, uh, executive um, area was like, no, we need to do this now.

He pulled a developer aside and said, Hey, what are you working on? He's like, oh, I'm doing this. Like, not anymore.

You're doing this now. And, um, just, just, you know, totally blew it up. And, um, well long story short, we didn't build the right thing.

And there's a lot of problems around that. And, um, whenever you dig into the actual root cause of that, um, sales was really struggling. Basically.

Uh, they weren't meeting the numbers they were really hoping for, and they were just throwing as many hail Marys as they can, like trying to close these deals, promising things that they, they're just, they're like, I don't know if we can deliver it, but, but we've gotta get this thing done. It's like really just working, working themselves to death, trying to get these sales closed. And so we were kind of in the middle of that.

And so that was a bigger, deeper problem. It wasn't just, you know, well, we need to do better within it, or, you know, lock people out and say like, no, you can't do the, it was like, we need to fix our sales problem as a company. So that was a big problem solving issue for us.

And so, um, you know, it just kind of goes to show that sometimes the problems aren't always one, they're just right in front of us. They can go a little deeper than that. And so that does need a little bit of problem solving.

Um, and again, just like I said last time, if this is truly is an unavoidable issue, if you're like, you know what, we can problem solve all we want, but this is just the nature of what we do as a business. I, I don't really know a good example, but there many businesses that are just like, we are chaotic. That's part of what makes us us, and there's not really way around it.

Okay, scrums probably not the right framework and you can use Kanban. Kanban is also agile. It's just a different way of being agile.

So I would just recommend looking into that if that's, uh, truly a problem. Okay, next we have, developers don't want to give us timelines, but we really do need them. With Agile, we're having trouble getting these.

So I heard this a lot, uh, again, just, uh, really throughout my career is just, you know, well one of the big things about Agile is that it always goes longer than the timeline, which isn't necessarily true. Uh, waterfall also goes way farther than the timeline. Uh, but um, but one of the things, the misconception I think is that you just throw timelines out the window.

With Agile, that's not really the case. What you do is you respond to change with agile. So Agile's not anti timeline, it's just pro responding to change.

So you can build a timeline and then just make sure that you're, uh, adaptable with it and you're able to change and willing to change if and when things change out there in the world. Uh, if you're stakeholders just, you know, understand that there's something else that they need or, or whatever. So as you kind of see here, it's really a function, a lot of just the kind of team you have.

Um, I've been on newer teams and um, you know, timelines are a struggle. There might be teams that are like, oh, we're so new, we don't really know the tech stack very well. Um, I think this will take like two days, but just to be safe, let's call it a week.

'cause we're so new and it takes like two to three weeks. Um, so that, that's how bad these things can get sometimes. But once you get more mature, I do see that there's a lot more comfort with, uh, with these, with these estimates.

Once you know the tech stack, once you know what's what goes on, it gets a little better. You also have data as you get more mature, you can be like, how long is this going to take? Well, we had something similar that happened, you know, six months ago, and that one, um, took about, you know, three months.

So it'll probably take about three months to, um, you know, we made buffer it a little bit, maybe four months, but generally we're probably gonna be good around three months. And that, that's a little bit more of an accurate statement. As you get more mature, you just get better at understanding what your, um, uh, you know, what your timelines are gonna be.

Um, but then down there at the bottom, like I I said, it kinda goes back to what we were saying earlier, timelines are estimates and they should be reviewed and adjusted and adjusted in the sprint review. Like the reason that people want timelines, there's a lot of reasons people want timelines. One of them may strictly just be for budgeting.

It's like, you know, we, we, we think we're gonna make this much money from this feature. Um, we won't spend that much on it, so we have a bit ROI, whatever, you know, it's just stuff that people, uh, people want just for that reason. And, um, and so when we get to our sprint review, so again, the sprint review, we spent two weeks building a portion of this feature.

We got to a place that that thing has at least some part of it done, and we're going to review that with our stakeholders. When you get to the table with that, you can say, okay, here's the features we built. If they're like, oh man, I just think maybe I see it now and I, I know we said this, but I'm seeing it now and I think maybe that over here is better, can we adjust it to be that?

Or you can pull off a timeline and go, cool, um, yeah, that's gonna take a little bit longer. So maybe this is a three month project now it's gonna be a three month and a week or three month and two weeks, you know, adding more sprint onto it. Is that okay?

And you know, maybe they'll be like, yeah, yeah, that's good, and you would just adjust the timeline based on that. Or maybe they're like, no, honestly we, we kind of have a deadline. We really gotta be done in three months.

We can't do that. Okay. Like, okay, cool, that's, that's perfectly fine.

There are other things in this timeline that we can probably remove to make room for this other thing you're asking for is that, okay, we remove this thing here and maybe at some point in all that time you'll get to some kind of good agreement. But having the timeline, there is a, it's really good to have that artifact there to look at and, and kind of understand where things are landing, uh, as far as, you know, the plan and, and how and, and where, where you're gonna get done and what's gonna be in there and things like that. So yeah, generally use the timeline's fine.

Nothing wrong with that. Um, if your customer doesn't want a timeline, okay, great, no need to. But if they do want one, you know, no big deal.

They just gotta make sure that everybody's kind of agrees that there's adaptability there, um, in case you want something different. So, um, this leads to kind of the last portion of this, which is what to do with meeting resistance. This is, like I was saying earlier, like a lot of these things as I've been going through them, it might be like, well, yeah, like these are, these, these are legitimate things people believe about Agile.

Like why doesn't work? Um, and you know, I just, it just feels like it's very argumentative to say, well here's why it does work. You're wrong.

And that, that's not the goal. Like the goal is for us to understand, like I was saying earlier, for us to understand why agility works in the face of when people say it doesn't, or we know it does. Uh, here's some ways we can kind of look at that.

But as far as you're talking to other people, if you're talking to other people and they're telling you these things like doesn't work as X, Y, and Z, the best thing you do is just, you know, ask them things like, Hey, well would you be willing to try this? Would you, you willing to do an experiment? Like not telling them, here's why you're wrong.

Just being like, well, I hear what you're saying, um, let's just showing them that it works. Like what kind of experiments can you run to show people that this little thing right here that we wanna try to put into place might actually work? And, and just helping them kind of get there.

Um, and the next thing is just really important, and this was added since the first time I added, I did this talk as well, which is showing empathy. So again, you're not there to be right, like we're all here to succeed together. Like you're trying to help people, you're trying to empower people to do the best that they can.

And agility is kind of the tool we have in our tool belt to help people do that. So show empathy, like when someone's like, I just, this isn't gonna work. Like a lot of people have been hurt by agile, if you wanna call it that.

Um, Agile's been used as a weapon in a lot of ways, you know, and not agile, that, not true agile, but that, that there's some things that people call Agile. Um, like maybe someone was like, you know, agile to us was that we had to use this tool, we had to use this exact template, we had to do it this exact way. We had to meet these exact standards and we didn't, we're not meeting our agile quality, you know, controls or whatever.

And it was just dumb, you know, and that's their experience of Agile. And so they're coming to you saying, no, we don't like Agile. It's really bad.

It doesn't work. And you know, some of the, some of what you do is you say, I'm sorry, you know, I'm sorry that Agile didn't work for you. I'm sorry you experienced that, that wasn't the right thing to do.

Um, but I think you have an experience of Agile that's not right. Like I think maybe if we work together, we can figure out something better than what you've experienced in the past. And that's important too.

And um, and if you can meet them at that level, like understand where their, where their heart's at and their head's at with this agile journey and meet them at that level, that'll go a lot further than just trying to dogmatically say, here's why I'm right. So that's a good way of kind of meeting people where they are. Um, but the last thing you wanna do is when Agile really doesn't work.

So other situations where people are right, where they're like, agile won't work here because this, and, um, I put here when change is expensive, 'cause that's the whole point of agile is that you, you are able to change direction a little bit based on what you, what feedback you get from your products and from other places. So if you can't change very easily, if change is very expensive, then Agile doesn't work very well. Now one thing I'll say is that in my, the first time I gave this talk, there's a lot of places I would've said, oh yeah, like, here, here and here.

But as I've gained more experience, I've seen Agile work in places, I would've thought it wouldn't have worked very well. Like I would've said something earlier in my career, I would've said something like, well, agile won't work very well in like a highly regulated place like the government or the bank. And I'm seeing a lot of agile teams in the government.

I'm seeing a lot of agile teams in the bank. I work at a bank now we were agile and um, you know, the reason I would've said that they, it wouldn't work is 'cause of all the government regulations. It's like, well you can't release this thing until you have all your paperwork in place.

And that could take forever. And believe me, I was a bank, it did take forever, but we were able to do it iteratively too. And so it, it actually, we were able to problem solve a lot of those things and get to a better place.

And so that list of places that I would say Agile probably won't work is, is shrinking to the point that now I can't really think of a place that I would say, oh, agile won't work here. Like even if you're building a building or something, um, it's always a good pro like good thing to do to occasionally bring the client into the building and have them look around so they can tell you things like, well, I don't know, I don't, I don't really like that plug over there. I want you to move the outlet over the other side of the room.

It's better to know that now than when the building's built and you gotta undo a bunch of stuff. So even there, I would say probably Agile's a good practice. It may not be as, as effective as other places, but it is still a good practice.

So yeah, I would say most places, if, if it won't work at the very least, you can glean a lot from it. So I would still be very cautious to say it doesn't work, uh, more so now than I first gave this talk. And that is all I got.

So again, I wanna thank you guys for choosing to, um, to come to my talk or to listen to me or having me here. Um, yeah, thank you guys so much. Appreciate your time.

See ya.