AA129 - Agile Complaints, Gripes, and Pushback

So an executive recently brought up a gripe to me saying that, their pushback on Agile with most most of the people they've interacted with is that there are no deadlines in Agile and that it is very difficult to get them to commit to a date. It's very difficult to get, actual estimates out of them of how long something will take, for example. And, I thought there was, I thought it was an interesting conversation. I decided to bring it to my favorite enterprise agility coach. Mr. Om Patel. This topic comes up fairly often, actually, in my experience anyway, when people say, yeah, we're doing Agile. We don't have any dates or we're doing Agile. We don't plan. And oftentimes it's, it comes from a place of absolute conviction that they say that's what Agile is. And, unfortunately not only are they not accurate in what they're portraying? they are way off base. So, again, I'm not blaming anybody here, because they don't understand it. It's probably the fault of Agilis. We didn't make it clear. Over the years, in, in advancing agility, right? That all of these things are embraced with, the approach of being agile. It's just that what we don't do is we don't, we don't look at something that isn't understood, isn't known, it's too far in the future, etc. And lock down all sides of the classic iron triangle. So, when there are no dates, well, you know they complain about that typically because they come from a project management orientation where you have lots of dates, right? You have Gantt charts and you have dates, you have milestones, for the whole project that somebody dreamt up one day. And maybe they didn't just, I don't want to necessarily say that they're, they're wrong in what they're coming up with, but they're wrong in what they're coming up with. They may look at analogous, projects. Like we've done this project before, something very similar. So based on that, we think that this one is going to take something similar, right? Okay, I understand. The rationale is there. However, then you go back to that and, and the very same project management folks define. a project as something being very unique. Every project is unique. Ergo, you cannot really relate to projects. Even if you've done a similar one before, there are lots of factors there. So dates, yes, definitely I can understand the gripe about there are no dates. And that's possibly because they've been told that by somebody who's an Agilist saying, we don't have dates in Agile. We only plan two week sprints. Which is actually not correct that we plan to experience. It's not correct that we can't have dates, right? The Agile doesn't mean there's no planning, which is the other thing that people say, you're, you're Agile. You don't plan. Yeah, no, we've absolutely planned, right? We just plan differently. Let's stick with the no deadlines as just to pick, pick one of the gripes. So bringing my. Product management hat to the arena here to the arena. I don't like that's weird. Like, sorry, like I'm going to insert like a little captain Kirk fighting the green guy thing here. Um, like bringing my product manager hat, what I hear, not committing to deadlines. What I hear with that is lack of predictability. That's what I hear with that. I hear a lack of predictability meaning you can't tell me when things are going to be done by certain date. You can't align milestones. The first thing I'll always say when challenged on this is, I can hit any date, show me a Gantt chart, I can hit every single date on that Gantt chart, 100% of the time, and people will scoff, and say, that's, you're being ridiculous, Brian. Stop being you or whatever. And, but it's true. I can hit, I can, I can break work down to a granular point where I can hit the deadline. It's just, it's just is what the customer is receiving by that deadline that you set often arbitrarily. Is that actually going to solve a customer problem? The, I mean, like when I, when I hedge that much to bring this up, I think we're both already shaking our heads. Like, well, no, probably not, you know? And that's, if we even, if that's, if we even understand the problem by the time we set that milestone, right. But I can hit a milestone a hundred percent of the time, that that's, that's, that's, that's part of it. Yeah, absolutely. I agree. You could definitely hit a milestone. It's just what you're getting right. You may not even get a. Functioning product or a product increment by that milestone, but you can hit it, right? And even if you did get it, to be a functional, release or whatever. The question is, what are you really delivering right there? What, what, what suffers as a result of you just having to meet that specific deadline, right? What gives? Um, have you had enough feedback from the customer by that time and incorporated that into the product? Do you have good quality of the product, right? That's usable. It's, there's a term that comes to mind. It's, fit for purpose. Is it fit for purpose? Right. Oftentimes people devolve the conversation into, bugs and escape defects and things like that. But I always come back to that and say, is the customer agreeing that this is fit for purpose as a, as a release by that day? If they are, then great, you've met it. But trying to do that arbitrarily, just literally just taking a random date on a calendar and say, on this date. We'll have a release. You're not going to meet that. And that's going to contribute to what you started with, which is lack of predictability. All that's going to happen is that Executive is going to keep getting disappointed and say, you keep missing deadlines, right? Because those deadlines are not grounded in anything. Yeah. They're completely random. You know, the interesting part about this is that, when you're talking about things that lead to lack, lack of predictability, what I'm hearing is lack of a strong product presence. I think there's a lot of people that are trying to do this without, without asking more from the business, more meaning, good, solid product management practices. From the business, I don't know if you've ever been on a team. I have been on a team where like you have like a scrum master and you have a bunch of developers and they don't have a product manager or product owner coming to their reviews and they're trying to do the best they can or whatever. They're not set up with all the correct pieces. And they're not set up for success basically. And, I imagine the executives that they're going to having a frustration to say, I don't quite understand how this stuff gets done because all the product stuff is missing from those teams, I got to imagine that that there's an element of this in play with companies like that Absolutely, and I have been on several projects like that where there's there's no product presence but also, you know by definition therefore, there's really not a whole lot of customer feedback there, right? And not just about Having something tangible that you want feedback on. It's just even, even the, the actual needs upfront, nobody does all the vetting. Nobody actually talks to the customers necessarily. There's a lot of this. Assumption based building going on, maybe sales comes in and says, this is what's needed. Trust me, right? And then the teams go build that. And even if you miraculously hit that, that, that mythical date that somebody came out with, the minute the customer sees it, the reaction usually is not very positive. And that's when the executive then comes back and says, what are you doing? Right? Nobody wants this. To me, a lot of that. In fact, most of that is avoidable up front, right? At least that's my opinion. Most of that is avoidable. If you were just to line up the program in a way that You know, make sense. So set yourself up for success by having product presence, making sure that customers engaged from the beginning and throughout. and then not necessarily commit to dates right when you start the project, but you know, iterate on it for a bit and then see how you're doing based on that. You could come out with perhaps a date range that says this is where we can come up with. You know, release one if you want to go down the path of MVP, you can do that, but Um, release one, 1. 1, whatever it is, you can say, that's when we're going to come out with it. You were talking about the, the window. Yeah. Like I can always give a window from the backlog. Like, I, this is, the more we talk about this, the, the more kind of, I was going to say silly, silly is probably not the right word. Like ludicrous. That's probably, that's probably like a silly is not the right word. Like ludicrous is probably even worse. Like the, the more we talk about this, the more, um. Yeah. Asinine. Asinine. We're not getting better. Like the words are not getting better. Like the, the, the, the sillier it gets because like, I keep my backlog between two and three sprints ahead of the team, like with refined work. So I can go into my backlog at any point in time. And we're, we do two weeks sprints, we're six weeks out, right? One month to six weeks out. And I am vetting things that are coming through the intake process. Maybe six weeks in front of that or more potentially, so I'm, I'm 12 weeks. I'm a quarter ahead basically. So saying that you can't saying that you don't have predictability. I just think I translate this into my head of, you just don't have good product practices because even if you didn't have solid product. In your organization, you probably still could as a team rally around this two to three sprints ahead in the backlog and then you could be telling people you'd be communicating windows of when we'll land things to your stakeholders, within, two sprints or so of each other. So you're within a month, you're giving deadlines. Basically, you're giving them delivery deadlines, basically. You know, communicating quote deadlines. But in reality you're just telling them like, Hey, our sprints end on Thursday and we'll have it to you four Thursdays from now. Somewhere between four Thursdays from now and six Thursdays from now. So just go find what those dates are on the calendar and just give them those dates. Like, that's pretty easy. And then it, it should be, right? Yeah. It should be easy. And, and then the first, the first indication that you're gonna miss those dates. You do the same thing a project manager would do, and you just communicate with them. They're like, Hey, the date slipped, and these are the reasons, and this is what we're doing, and this is what you're gonna get or not get, or whatever. And you know, that's, I don't understand why it's a big thing. That's what I'm saying. I don't understand what, it's not being done. It's not being done. Right. That's probably the main reason, really. Right. It's, yeah. Right. It's probably not being done or they, their product function at those organizations is very, very immature or something like that. That's probably what this is. Yes. Yeah. The other thing that I hear a lot with, resistance to agile is that, that, you don't, agile has no documentation. That's the other thing about. That I have directly gotten pushback in this category is like, Oh, you want to be agile? That just basically means you don't write things down. Yeah. And that's again, another one of those classic, misinterpretations, right? Where people say they misinterpret, the ethos of, A working software or comprehensive documentation. Yeah. They can read that quickly and say you focus on delivering stuff, but no documentation. Mm-hmm., it's not what it says. Right. If they read it slowly, it's only four words. If they read, if they read it slowly, it says comprehensive documentation. And the concept of just, good enough. You need documentation. There's no denying that. But you don't necessarily need reams and reams and reams of documentation, as was the case in, years past, where documentation actually was a deliverable. Unless it was met as a deliverable, the project wasn't successful. Here, you need just enough documentation. To use the product, to be able to support it, to be able to use it, et cetera. If you have just enough, then that's good enough. And now, now people say, Oh, what does that mean? Just enough, right? It can mean literally, it can mean anything from, notes that are legible, understandable, it doesn't have to be formatted and it doesn't have to be done that way unless the customer is asking for that, they're asking for it. Then fine. But people misunderstand the point that Agile does not mean zero documentation. It means just enough documentation, right? And maybe I think that that principle could be reworded, to say that. Just in time. Yeah, just in time or, or, just enough, but you don't need to go crazy over it. I think everybody who might be listening to this podcast is going to be like, yeah, documentation, whatever. Everyone knows like, yes, we document, but we're not going to hold the whole quote project up on the documentation being done, which I remember like the early days of my career. I remember like, oh, documentation is not done. We can't close. You know, basically close the, the financials or whatever. We can't, can't book the money'cause we're waiting on documentation or you know, we just, everyone is like, that's ludicrous. we're not gonna do that. But some people like the formality of documentation because if you have documentation for like, I think in the old days with like handoffs and stuff like that, I think in the old days, where in the handoff you had something, and maybe this goes back to like. When software was actually in packages that that kind of thing, you had something to hand over to somebody, you know what I mean? You had like a comprehensive user guide that detailed all the functions of the software or something like that I think of like delivering an API without the documentation like you can't deliver an API without the documentation So some documentation is required, but I can deliver you one single endpoint to the API with documentation for that little endpoint. So you could argue like, well, that's, it's so tiny because it's little, but the documentation has been done at the same time. Like that would be an example of where you, you would do documentation and the software together, right? Yeah, that's a great point. That's exactly what I had in mind when I said, just enough, right? So if it's just one endpoint, then that documentation, that little piece of documentation that you deliver covers that endpoint and that's enough. And you just add to it and iterate over time, right? So the entire, the entire payload, for instance, doesn't have to be completely documented. Especially if the documentation happens after the fact. Which used to be the case, right? In the old days because people, to your point, people are looking to close the project and that formal step of closing the project was called administrative closure, project management speak. And, until that happened, money wouldn't change hands. So there'd be a lot of pressure on people to complete the documentation. And again, the quality, et cetera, was pretty dubious, but they completed it just to get that checkbox and then say, pay us, basically. So, yeah, I agree. I think this is a great example of how you can deliver just enough documentation. If you keep iterating on it. And that's, that's all that's needed. It's the endpoint that's usable. Great. Perfect. You've got, you've met your mission. Oh man, I remember, I remember they, they would try to roll on a documentation person for a period of time and then try to roll them off after the, they've delivered whatever. Like, the thinking was they, they, the documentation's been delivered, we never need to change it ever again. Kind of like the software's been delivered, we can fire the whole team now because it's, we'll never have to change it again. Which is just... A ludicrous way of thinking but that but but again the actual documentation aside, the formal delivery of it, and those handoff events where you had sign off, and you had like, Hey, we hit this milestone, and then the project manager communicated that out to everyone, and they, they sent, forms out in triplicate and, climb from the highest hills and the hills were alive with the sound of music or whatever, like that, that, that broadcasting of a milestone being completed, I think that is what, certain executives chose. It's ceremonial to them, because we, in the, again, in the battle days, I think they were battle days. Um, there would be phase gate reviews with these executives with all the other around the boardroom table. And, the project manager would present, what's being met for that phase. And then there'd be grilled, to be Q and a, all of that formality is missing now, right? Because we're delivering frequently. Right. We're delivering on a cadence and we don't necessarily have those phase gate approval processes anymore. So we don't have a project manager or anybody really announcing those off the rooftops. Right. And that, that is something that people miss perhaps. I was going to say also, they, they, they don't, all the people that used to be in the room, at like a management level, like now they don't have the, they don't have the forum anymore to interact with the product. You know, I mean, this is turning out to be an anti product management podcast. But like, again, like if your product people are not getting the right people in the room. For the demos, I guess I can put scrum masters feet to the fire on this as well a little bit like if you, if you don't have the right stakeholders in the room and you're not doing a great job at stakeholder management, that's when you run foul of this issue whoever has influence over the product, you need to be ahead of that organizationally and and let them have some kind of form where those people have a say, you know? Yeah, no, that's absolutely right. And I think if you were to kind of say, Hey, How do we supplement or supplant, that need of formality now for working in an agile way? Maybe, maybe I can suggest, something I've seen that works reasonably well here, which is a change management function where somebody comes in They will do the announcing of, here's what's coming, 90 days out, 30 days out, etc. Here's what's happened, right, the day after it was released in the wild. And then follow up thereafter, right, how many, what the adoption rate was like, etc., etc. That, that whole communication, that happens over time could be really that, that pacifier that kind of substitutes in the formality, but it's not a point in time event. It's multiple events over multiple points in time, under the guise of change management, especially if you're in a regulated industry. The other thing that, I'm going to keep us trucking along. The other thing about, lack of documentation. Lack of formality. Basically lack of process. That's, that's sort of what they're complaining about. The other thing along with that is I have heard in my career, a lack of longterm planning, for example, that where I threw out earlier where I was like, well, it's a benefit to be in, six weeks, six weeks ahead with my team because I'm wearing two weeks sprints and I can go, two to three sprints. And then, and then I'm also doing discovery. potentially two to three sprints in front of that. So I'm 12 weeks out, but I'm not much further out than that. That, so the, pushback, which I do think sometimes is valid here is, you're only thinking tactically and you're not thinking strategically. so what, at what point is your agile team taking on the challenges of thinking strategically where the business is going to be three years from now, for example, I mean, I'm not, maybe not even three years. Maybe that's too much to ask. Maybe, maybe a year from now, let's just talk about a year from now. Yeah. I think this, this, this podcast on having. You know, the strategy, right? Having a strategy that aligns with your vision and your mission and then breaking those down. So it's perfectly all right. I think I think about the time frame of, let's say, a year to say, well, what are we hoping to achieve in the next fiscal year? That's our strategy, right? And break those down the strategy down into. Smaller chunks. These chunks could align themselves to maybe the six months or three months. And you mentioned that in your planning, you're you're about about 12 weeks, which is a quarter out, right? Maybe you can do that. Maybe you can have a rolling planning machine, right? That looks forward every three months. But all of that is looking at a one year strategy in place, right? Your teams aren't necessarily going to be challenged with that. I think that's where your product folks, your product management, folks will need to. Kind of hang their, their approach on that strategy and then communicate it down, obviously, with the teams and so forth. So it doesn't mean that there is no long term plan, though the long term plan gets set. At the at the, unfortunately, we're still dealing with the annual budgeting cycle, right? The tyrannies of that. So, okay, while we're in that, in that mode, why don't we look at what do we have money to do? What are we trying to do for this? This much money that we've got this budget, and then how do we break that down into? Perhaps smaller chunks. Let's say, we can plan in, let's say, four increments that span that fiscal year. Now, each of those increments align perfectly fine with the way you're describing the planning to work. Right? Yeah. With having seeded backlog and then doing the discovery that much further out, etc. So you could still have that. What you cannot have is the, Okay. The planning of old was long term planning was 10 years out, right? This is the GEs of the world, right? That's what they were doing before, and then medium term planning was 5 years out. And short term planning was 1 to 3 years out. I think all of that has shrunk dramatically over the last few years. There is no long term planning. There is no long term planning whatsoever. Because, what does that even mean? Long term planning, right? There is only the annual planning because, things change all the time. Nobody, nobody imagined that you would have Uber or or whatever else. So, so that's I think the cycles of shrunk dramatically. But it doesn't mean that you cannot have planning that's beyond just the two week. Oh boy, like talk about stuff getting like, holy, get out, cut out of the podcast, Batman. Like five years is beyond most people's thinking. You might as well go to Mars, at that point, because nobody can even think at that level anymore. And if, and if you have plans they're basically invisible to everybody because as you accomplish your milestones nobody can even live at that speed. We should be planning to that. But, I don't know, if you have plans that are 10 years out, they're pretty coarse. And, yeah, yeah. They're not really all that well defined at all. They can't maybe, but I mean, like missions don't change that often. I think maybe like going back to our mission and vision podcast, like missions don't change that often. So you should have goals that align with the mission of your organization. And the vision of your organization. And I can't imagine that those change every two, three years. They, they probably go longer than that. So like, I don't know if this is just like. Just people short cutting things because they're living quarter to quarter because that's the way the stock market works or whatever, or if this is just some kind of, deep rooted, rot in the system that is kind of taking a hold. It's probably both because those execs that are planning that far ahead, let's say three or five years, They won't be in that position three to five years from now. we're up against the Deming podcast because that's what he warned. 18 months, two years is too often for your executives to move around. It's, it's way, way, way too fast for your executives to move. Um, cause they can't, you can't implement, you can't, basically, you can barely even change the system inside of that timeframe. True. Very true. He was one smart dude. the other thing that goes along with, with kind of what we're talking about now, sort of loosely, is, I've had, development teams, engage with me, that's my nice way of saying fight. I've had development teams engage with me about. Hey, if we're only ever building the, again, agile development, right? Getting something out of every sprint, every sprint, if, if we're only ever building something that has to be delivered every sprint, then, well, we can never kind of take a step back and consider the whole architecture or design of the system or plan out, pieces of the, of the future system and I've heard that pushback before is it makes it more difficult to take a systems design, look at the entire system and, and then to build pieces of those systems. I've been challenged on that before, like for more than once. Definitely, definitely heard that as well. But in this case, I do believe this comes back down to the, the expertise. The prowess of the architects, the true architect, they should be able to think in a kind of systems thinking manner, and they should be able to come up with a design that, that, that, that. precludes this thing from happening where lack of design and architecture like if that's happening you don't have an architecture worth their salt on your team you don't understand their domain perhaps you know or there's issues that they're solely ignoring and basically wallpapering over Scaling issues, for example. They're not building those in. So, these cracks expose themselves. Um, I, I don't believe that this is something that's insurmountable given the right people in place with the right expertise. People have had this discussion with in the past. They, have a, I don't know a good way to say they have a lack of understanding of the difference between, refinement and sprint planning. I will say a lot of times because refinement is me. I own, I, the product manager, I own refinement. That's my opportunity to punch ahead for the roadmap to connecting the strategy, a lot of different things in refinement. And, and sometimes I'll use entire refinements. Often with my team in the room with my full team in the room to do nothing but talk about how what we're about to build fits into a larger architecture or to talk about a future architecture that does not yet exist that we are building the first piece of and that and how we'll have to build a much much much larger system in the future. But the first version is going to have none of that because we're trying to get to market. We're trying to prove people want this product. We're trying to prove it is valuable and solves a problem. And, so there's like a, there's like a MVP little tiny version. And then there's the full blown version, and a lot of developers like very senior people in their careers have challenged me to say, um. Why would we build a, this tiny sliver that doesn't do X and Y and Z when we know that anyone who joins is going to want X and Y and Z? But I've had that argument. M many, many times it would be a spirited discussion at the least. Yes. And I can understand how that would happen with developers that really don't, they think they know what's needed. Right. So you're in a perfect position as a product person to, to be able to say, we're testing the market this way. Right. Essentially. but yeah, you're right. You'd, if they were to just go and. Just sit there and develop everything before delivering anything, then that wouldn't be agile, right? So it behooves all of us as agilists to convince developers to say, look, we want to show this to our customers, let them tell us which pieces of the puzzle should be exposed to which teams, right? They can come back and say, well, maybe we want some people to be able to see things, but not change things. Okay. Well, now we've learned something about their intended use. So we go build that. We know the pieces, we have the pieces, right, to build it. This is typical of most of these applications that, you put people in groups, et cetera, et cetera, and you provide them with group permissions and whatever else. but let's not assume that they want something and then try and build that ahead of time. So it falls under the guise of deliver it. Solicit feedback and then rinse and repeat. I feel the complete opposite side of this is executive saying Um, I don't like agile because, I can't lock down the scope before you begin something to say, well, the opposite, this is the opposite because the last thing we talked about is, Hey, we're going to start building a tiny sliver of the system and we know there's a big system that needs to be supported. And then the other side of this is I don't want you building a big system. I want you to tell me everything you're about to build, and, and my product pushback to this usually is like. I can't tell you what I'm about to build because I have no idea. I don't know how much is going to be enough and when we can stop. But all I know is this is the business's number one strategy, number one customer problem, number one priority. We're going to stay on this. Until we all agree unanimously that we are done right until the metrics match and the customers are happy and the money is coming in until we all agree we're done and we want to pivot to something else. Yeah, not only do you not know what all there is to build, maybe the customer also doesn't know. They learn along the journey themselves, right? So if you show them something and you have a discussion with them every time, they may say, Oh, well, can we do this? Yes, or maybe not. Maybe we can do this instead, you know what I mean? So that that's how the product evolves in tandem with the customer. Sometimes they don't necessarily have a clear idea. Every piece of functionality ever needed in the product by them, right? They don't necessarily know that, an executive who says we need to know everything that needs to be built obviously, it's not coming from a place of agility, right? They're coming from perhaps, perhaps they're part of the old guard. They're saying, well, we need everything written down. That way we know we're cutting the risk. Ultimately, you got to figure out why they're asking the question, right? And I think nine times out of 10, it's, they're trying to cut the risk of scope creep. Essentially, they want to lock in the scope and say. All of these things are what we have to deliver. And anything outside of that, by definition, we're not going to deliver. But that's kind of premature because maybe something outside of that is exactly what the customer wants through discovery over time, they decide they want this other piece of functionality that they didn't even imagine on day one. So, two things here. One is, if you're worried about locking down the risk, you're locking down the wrong risk. You're locking down the risk of scope creep, supposedly, whereas we should really be, the classic words are welcome changing requirements even late in the process, right? But, the risk you should be worried about is not delivering something that the customer really wants, right? So flip that on its head and say, let's engage with them, right? And let's build something, even if it's not exactly what they want. We know it's not exactly what they want. But then we can tailor in, it's got a, almost like a homing beak, tailor into, the, the process. There's some variance there. We're going to listen to the customer and we're going to pivot every single sprint. The other thing that's on this list that I hadn't, I hadn't thought of until right when I was ready to hit the stop button is testing, like inadequate testing like, Hey, we're agile now. And the scrum guide says developers do tests. I don't mean, I don't think the scrum guide even says that, but, so I'm going to fire all my testers and my developers are going to do testing now. So, which obviously like it's, it sounds. It is as much of a train wreck as it sounds. Especially if you approach it with that mentality of, that, that flippant, Oh, I'll just make my developers test, so the inadequate testing and quality gripe is a real gripe, which is also like, it happens to be my lane of expertise. So, like , let's discuss this one. Yeah, absolutely. I've seen that as well where people say we don't need testers, or what, what they say is, we are gonna give you a tester part-time, and then part-time, for three, three sprints, right. And then they'll move. Right. They'll move to some other team. Yeah. Like, okay, that clearly is not going to fly, quality is something that suffers as a result of a lot of these little, tweaks that people make to the process, the process in double quotes, air quotes., and this is one of them. I think when you say developers should be doing testing, you're already talking about it the wrong way. Right? It's, I'd rather say. The team owns quality, right? So, who is the team? Oh, well, we've got developers and we have testers combined. Okay, well, then they own quality. Developers... We should never ever say, I'm a developer, I don't test. You should be writing the test to begin with, but that's a different podcast. Um, right? So, and then the slippery slope here, which is pretty slippery, is get the developer to test their code. It's like, that's not, we know that doesn't work, right? The developer who writes the code tests their own code. That doesn't work. They're going to put up something on the screen that says, world, hello, and they're going to say that that works. That should be Hello world, maybe. Right. And so anyway, quality is something that people bolt on after the fact Yeah. Often instead of building it in. Right. That would be the big problem with this category, is that, people pushing back in this category, they, they're implement, I'll call it their implementation of agile, inadequate testing problems with quality, whatever, is that they are trying to inspect for quality after the fact, which is a huge problem. The team should own the quality should be built in. And then also, like I said, it should be built in. So the next logical thing is quality. Like there should not be the option to compromise. Or trade off quality for anything else that should not be an option. It, if, if you're, if you're baking in, tests, into your code. Again, we can hold, we can do a whole podcast just on this one point that we're talking about now. Quality should be done in stages and it should be done, it should be started as soon as the work item starts. It should be like, as soon as the work item starts being discussed, we should be talking about how we're going to test it, and then, there should be some, some sort of standards in place. I think of the definition of done type of, working agreement type of, it's agreements basically with a team about, writing automated tests, writing unit tests, writing, maybe, UI tests for certain things, if necessary, API tests, stuff like, stuff like that, basically functional tests, should be, checks, checks should be done along the way. And all of that should be a standard part of the process. It's, it's not something you can throw out in order to, accelerate your development by 10% or whatever. Yeah, but often times, though, what happens is the teams don't really pay attention to these team standards, I'll call them loosely, right? they simply just muddle through, is what they do. You know, they have testers that test after developers throw things over the wall at them. And then they raise bugs. they don't worry about things like, minimum, code coverage, for example, or, regression every, every step of the way when it moves through different environments, for instance, things like that. So again, this, this talks to, I think, largely to the maturity or probably the lack thereof, right, of a, of an agile team. If a team's been around long enough, they will have figured all this out. Yeah. And then you will have these, these team standards. And. The thing that I watch for is that not only that they exist, but then what happens over time to those things? Teams that are maturing will improve those standards over time. And when that's not happening, quality is suffering. You just know that, right? That's, that's interesting. Cause I haven't, I haven't heard that one before as your Agile team matures, is your quality maturing as well over time? At least your processes, I would say. Yeah, you know, what's funny is a hundred hundred twenty something hundred almost 130 episodes I don't think we've ever done an episode on Testing in agile like a basic like the basics of testing in agile. I might need to put that on the list because again like that's that's my professional background And, something I can speak directly to and with my expertise. So we should put that on the list for sooner rather than later, actually. I agree. Absolutely. Well, if you're getting challenged, that, Agilis, they, they won't commit to deadlines and they don't know how to hit deadlines and milestones and dates and whatnot. Um, podcast can help you. Let's know what your thoughts are down below. Subscribe and like that's right. Subscribing and also subscribing like a date out of the air. That's what that's right.