AA75 - Definition of Done

I had a remark about PMs contributing and involving themselves with the team to determine the definition of done. Definition of done because from a technical background, I have, I don't wanna say strong feelings cause I don't really have strong feelings. For teams who don't have a definition of done and they get together and they form an initial definition of done that share between teams. I have things that I think should be in that definition of done mm-hmm but you should be part of that discussion mm-hmm sure, sure. Mm-hmm but again, I'm bringing that from a, from all my experiences. Yeah. Technical non-technical team member, scrum master product owner, I'm bringing my contribution to the definition of done mm-hmm well, definition of done. I shouldn't have to write in each story, go to test, go to prod have the unit tests in each one, like all that stuff should be a given. I'm not writing any of that in acceptance criteria. Sure. So when we have a discussion about definition of done, I'm bringing all that stuff. I mean, since we like to argue about definition of. On the internet.. Yes, we, yes. there's a real, yeah, that's another huge, there's a whole podcast that should, that could, and probably should be done on definition of done, because that's another thing that is, there's so much confusion surrounding that. And I don't necessarily there and there isn't any one right answer. So there's a lot of different perspectives and a lot of variables and a lot of right answer there. Well, there is a, okay, there's a scrum answer. I think that the box of the definition of done is fairly straightforward, but what you put in that box, we can negotiate. This is where I was going. But again, I didn't know how deep I wanted to get into this discussion, , the definition of done is a box of what we all agree across all the teams, what we all agree is done, but I could easily see in programs I've been with previously, the argument that I've observed slash bid on this topic is you can't add so much stuff to this so much overhead that it significantly slows down the ability to quickly produce work items. Yeah. It's a trade off right? So you're gonna impede flow by putting in vertically all these things, but the teams can figure that out. And yeah, the product side of the house is part the team in this case to figure out what definition of done really means. Are you done when at the end of the sprint, something is shippable or is it releasable mm-hmm right. There's a distinction there. Mm-hmm so I always coach my teams to develop on a cadence and release on demand. The release part is outside of their control as such the business can say, we want to release here and they should be able to just do it without going back to the dev teams. Now we're getting this stuff. That's not in the scrum guide and that I welcome angry tweets on the internet about like, who is accountable for the definition of done. Is it the whole team? And I ask that because I have been in the product position to have to defend the definition of done to the CEO. When he says, how are you calling this done when it's not in production and usable by customers? Well, yeah, yeah. I'll repeat this. Like for, like I said, I can't repeat it exactly verbatim, but it's pretty close. And that is, if there is a definition of done that has been established by the organization, that must be followed minimally by the scrum team. Okay. Minimally. Now that's the operative word here. That doesn't mean that you as an individual scrum team, couldn't even add some additional things that were pertinent just to you, but minimally you, if there is no or no organizational definition of done defined, then it is up to the scrum team. It also does mention that there should be alignment of definition of done be among multiple teams. Right. But from a scrum perspective, that's, that's the definition of done, right? Is there one already developed by the organization? If so, are we following that minimally? Okay. if not, we create one as a scrum team and it must be shared across minimally across our scrum teams., As a product owner, someone who doesn't have technical experience definition of done the first thing that comes to mind is that definition of done may have some kind of essential, I don't know, feedback loop requirement or something that I have been able to make sure to collect, put in front of a customer and get approval. And so not sure if that's part of the definition of done or if that's just part of my job or if that needs to be called out in the definition of done. But as you said, if it's not kind of written down then the ex, so the whole point from my perspective of the definition of done is to very clearly set the expectations across the board. Sure. Of the minimal that we need to complete to say that we have an increment completed. I think you just nailed it. These are the expectations. Like if we have a welding business, mm-hmm, I gotta wear my dark goggles. I gotta wear my ear protection. I gotta wear my gloves while I'm welding. Mm-hmm like, I don't need you to write all that in the story. I know I need to do all that. Yep. That's a given for every welding. that I start mm-hmm I'm gonna do all that. There's probably maintenance on the welding machine. That's that's, that's not even. Yeah, but that, that stuff's not even negotiable, right. On like, well, well for this project, I don't need you to put on your safety gear and all that kind of stuff. Again, like back in the day, I used to work with a, a heavy equipment when I was in the air force. And I think you had to wear gloves. You had to wear steel toed boots. You had to wear ear protection, double ear protection. Actually you had to wear double ear protection. You could never pull up to an aircraft without, at a minimum of a two man crew mm-hmm like, there were these definition of done mm-hmm requirements. And, and I should point out, you could break those reque. You could choose to be like, oh, I don't need air protection. The, the plane's off the aircraft's off, it's off on the, on the ramp. And the engines are not running. I don't need air protection. You could do that certainly, but you are breaking the definition of done on that project. Right. You know, that you're breaking the definition of done. Mm-hmm , for whatever reason, maybe you didn't wanna, maybe you were already from one plane to another in transit. You didn't wanna go back to the office and get earplugs or whatever. Mm-hmm okay, cool. You're making the, but you know that you are breaking the agreed on definition of done. Yeah. There's no ambiguity there. There's no ambiguity. You're breaking definition. Know you're doing it when you do it. So my, my question here is are you doing that because you feel pressure in the organiz. To compete, produce, meet deadlines, meet deadlines. Yeah. You know what I mean? Are you doing that because of pressures or are you doing that for some like, why, why are you breaking? So, so definit and because I've been in organizations with the definition of done, I've been in organization where they write stories for like deploy it to test mm-hmm, deploy it to production. And those are stories. Yeah. I'm like, that's not a story. I, as a product owner would come in, I've been in the position I come into the organization and I'm like deploy to test is not like, that's not a story. Now, if you're gonna talk about a story with subtasks, do the change, test a change, deploy it to test, deploy it to prod. I can get down with those subtasks mm-hmm but the business value mm-hmm encompasses all of that. And until it's in production, no, you as a team cannot claim the value, the business value, right. Until you are done, mm-hmm with all these activities. And I may not specify every single one of those activities as acceptance criteria, cuz I think of the acceptance criteria. This goes back to our acceptance criteria. Absolute. I think of the acceptance criteria as a checklist for me, the user of the software, I was gonna say customer stakeholder. I could use a lot of terms. Me the user of the. To, to, to just check off each one as I go down the user story in a demo to say, oh, number a, or number B number, number a mm-hmm item, a item B item C. I agree. It's done. Mm-hmm yeah. I mean, indeed, that's one of the formats of the acceptance criteria. Verify that and then B, C, D, right? Sure. So you could just check those off. I agree. Absolutely. But again, the point of this topic and the reason I bring this up and segue us into this whole other podcast is , the establishment of your definition of done. For me, it's a much deeper conversation as a PM with a technical background, then it might be for a PM with a non-technical background. I, and I realize the arguing point against that immediately is like, yeah, it is. Unless your team is all supporting. If your team is supporting all the different things, then maybe that's not true. Yeah. Yeah. I mean, that, that's pretty much it you've summarized it right there. Yeah. Again, assuming your team is not, is not staffed by completely by junior developers or offshore developers who just don't. They don't want to add more work, so they're not gonna contribute. Mm-hmm just doing, doing what's prescribed. So if you're, if your model is one of a prescription model, you won't get that. Right. They're just gonna say, this is what I, you tell me to do this. I'll do that. And that's it. Mm-hmm right. Do the bare minimum, right. Mm-hmm but there, there are people out there with that, for sure. Yeah, absolutely. So you said something about incentives. So what would, why, why would somebody do that? I think the military example you gave was a as a good one because it aligns with our teams and our teams are inclusive of if we're using scrum of our scrum teams and as a team, we succeed together and we fail together. So if we have defined our expectations and the definition of done to include these things, and we have someone who's decided not to wear their earplugs, their failure becomes not an individual failure, but a team failure. So then now, okay. What dig into that rationale. We just, some have somebody who's like sh screw it, you know? Or do we have a shortage in supplies? You know, do we have a scrum master that needs to kind of, alleviate that, that impediment and make sure that we have the tools and the supplies and the that we need is I can give you more examples too. And then I can give you more another example that I remember before I left a base one time, one of my last nights on the flight line, as like the senior person, like, I didn't really need junior people to work with, cuz I basically could do everything by myself oh yeah. In 20 some in 20 something. Yeah. Oh yeah. You knew it all. Yeah. I knew how to do everything. Of course. Gotcha. Yeah. I've never had an accident. Yeah. Yeah. Invincible mm-hmm , so basically like you're a, the minimum you need to service an aircraft is a two man crew because you always need a spotter. You need someone to, to, to put a chalk under the vehicle's tire. Maybe you don't have a collision with the aircraft and stuff like that. A two-man crew is an absolute and, and , what I mean absolute minimum, it, that is the absolute minimum. And you could service an aircraft by yourself. However, if you had an accident and you were by yourself, You everyone would immediately, there would be no escaping that you are breaking a definition of done, basically. And you being a senior person, you should know better. Mm-hmm so there is no getting out of that discussion of, Hey, I took shortcut like there, there there's there's no other excuse you could apply in that situation. Other than I took a shortcut and made a mistake. Mm-hmm yeah. There's no way to get out of it. Even with two people, you can make a mistake and then, then you'll have a discussion of like, well, what happened? Why did this mistake happen? There was not communication between the two people, whatever misread hand signs, whatever. There's some wiggle room in that because you're not breaking the definition of done. Yeah. There's an agreement. and you are following the agreement mm-hmm versus there's an agreement and you're going against the agreement. And another point you are a part of inputting and putting your input to, and agreeing to that agreement, even in an established organization definition of done again, that's minimal, that's the minimal. So if you have additional information or if you have additional, so you're going through retrospective and you're going like what, why are we writing this in every story? Why isn't this as part of our definition of done? So we should be revisiting this very, fairly frequently and our team should made a part of this that makes them accountable. It makes them have ownership over it. So so I would, I would say that that might be a little bit different than the military in the sense that you're probably not so much a part of that, that creating that definition of done. They have ownership. They can. So what doesn't work, they have the opportunity to speak up and change. that gets harder in some hierarchical institutions. I mean, maybe even the military I don't know how much influence you would have trying to change the, the procedures and the processes that are there. Well, you, well here, here's the thing about definition? Well, this is a great example. It's a bad example cause it's not software development, but I also think there's an advantage because it's not software development., development team could be applied to anything, I guess that that's, that's, that's the other thing that you're kind of leaving out. It's like sure. Development team, like you're servicing an aircraft, you're a development team. You're not writing software, but you're, you're contributing to a goal. Mm-hmm the definition of done in that example is the bare minimum of prerequisites for you to call the job done. Your team could decide to add more to that mm-hmm and it could stay inside of your team cuz the, like the other teams might not adopt the best practices of your team. Mm-hmm sure, but eventually over time as your, and this, this certainly happened eventually over time as the teams that service Aircrafts they come in and you find out , well, when we have these three people together as a crew for the night, they get their AF aircraft done in , 75% of the time of any other team, what are they doing? Right. Are they taking shortcuts or are they just more efficient? Exactly. Yeah, yeah. Yeah. And as, as a supervisor. You should be asking that you should say, are they taking shortcuts? Yeah. And the, that question, are they taking shortcuts? You should be able to look at their safety record. Right. And, and like, in the air force, we didn't really have like a net promoter score, but like in software development, you hopefully with your stakeholders and your stakeholder teams, or if you service internal teams, you'll have a net promoter score with the people that you work with. Yeah. To say, Hey like this, this specific development team, their velocity's super high, their, contribute their contributions to the program are really their, everything we ask 'em to do they get done, but are people satisfied with their solutions? Mm-hmm you should have some kind of spec for that. Mm-hmm the equivalent, the, the, the aircraft loading, unloading example equivalent of that is let me look at their safety record. Let me look at their on time departures. Cuz if you cuz in this example of what I'm talking about, the goal is to de departing aircraft and arriving aircraft are handled. Arriving aircraft, the air crews at the end of their end of their air day, end of their hours, whatever, they're kind of like truckers. They have certain hours that they're allowed to be on the plane. And when they arrive on station, they're just looking to get off the aircraft, they're just whining and , I mean, like they've been flying, so like you can't say that they're just whiny about it they're just what was it a snively? Is that the that's snively? Oh yeah. Let's a little snively about it. Um, but I mean, you have to have some empathy for your users. Like they've been, they've been in the aircraft potentially up to 12 hours flying maybe if they flew from Atlanta or whatever, to Japan, they've been flying 12, 13, 14 hours, have some empathy for them. So you look at the safety record of the ground crew. How many accidents did they have? Right. How many incident reports? Incidents. Yeah. Right. injuries, accidents, collisions, that kind of stuff. But also you're looking at how many times did they delay, were they blamed for the delay of the aircraft or, or did the crew complain that the crew was taking too long or whatever, if it was an arrival cause arrivals and departures handled differently. but you kinda look at all those together. And again, if you have good stats, if you've instrumented well, right. The product people deal with that all the time. Software's not instrumented, but if you've instrumented. and, or you are doing good surveys with thumbs up, thumbs down, net promoter score big for your basic stuff. You can start taking in that data of which teams are servicing the business. The best I don't know about mm-hmm no, that's, it's the greater service we try to get to. Right. So yes. Which team has, what level or grade of service, right. That that's the term they use. Yeah. This scrum guide is super light on how the definition does crafted because I could easily see like what we're talking about now of like let me go to the best teams. Let's pivot back hardcore to software development. Let me pull the best teams. The people that hit their velocity have a high net promoter score, the backlogs in order, all, all, all the things that we would talk about. Just, just like real black and white type of stuff. You could argue team to team, right. But we're not gonna do that for a second. Who would be the person to say , well, these are the top tier teams in the organiz.. So what are they doing in their definition? Do they have a more expansive definition of done? Maybe they've, they're doing the minimum definition done that we've set across all the teams in the program, but they were also doing all these other things. Their definition of done includes good unit tests and automation and monitoring and learning and production for the things that they push out, like how, and the other teams aren't doing that, right? The other teams are doing manual testing. The other teams are pushing to this environment or their WIP is, more items or their code coverage is less or yeah, the code coverages or they're like their cycle time and their lead time, like are, is longer for the other teams. Yeah. As opposed to these, like, what are these teams doing and why are they so far ahead of the other? If your definition of done is across several teams, who is the person that prompts them to append or update their definition of done? Is it just one person on one team? And then they kind of try to get the community going. Cause that seems like an uphill battle. It is an uphill battle. it should be somewhere. I mean, higher than that, I mean, I, as a co I did, I disagree really. So unless you are, unless you have a, unless you have a, an organizational definition of done established it, this is my opinion. Okay. I believe that the scrum team should work together to define their definition of done. That should include the scrum master, certainly facilitating , and understanding what that definition of done is the product owner putting in the, and, injecting that empathy., and the organizational marketing sales, those type of things, but certainly centering around the user experience. along with the development understanding of their individual they're very individualized process. So for instance, in the manner in which they push software into production. So so those are all gonna be different. So each definition of done is very unique. Yeah. I think that. Establishing a minimum definition of done should be done by the scrum team. If there isn't one organizationally, additionally, if there are multiple scrum teams, I believe that those scrum teams and dependent, we generally don't have scrum teams that are boiler plate of one, another. Each of them are doing different things for different reasons, with different goals and different metrics, which means it makes sense for them as a team to potentially augment the minimum definition of done that has been established for the scrum team. So that's my opinion on that one. The other thing I just wanted to mention is there's so many freaking variables, right? So when you were talking about your example with the military and the planes and you know, saying, well, we have this really high performing team that, all right, we are getting great metrics out of across the board. But that immediately made, made me go back to think about context, the Hawthorne effect, like yeah. Are you familiar with that one? I don't know for our readers. So the Hawthorne effect was a study that they did and they basically said, Hey what could we do? And I'm paraphrasing here. I don't remember exactly, but it was done. I don't know. It like 1920s. It was a long time ago. Yeah. It's like the 1920s. Yeah. So they did an experiment and they're trying to get manufacturing of, I don't even remember what it was up. So they hypothesized that maybe lighting lighting may have caused an improvement in improving the manufacturing, the manufacturing process and their, their throughput essentially, and what they found was yeah. What they found was so they did it, they did experiment. And so they did lighting changes and so they increased the light. Right. And when they increased the light production went up. Okay. Right. So then they were like, all right, well, let's, let's, let's do a little more experimentation. And so they decreased the light. And so what happened? The production went up. And so they actually did, they did, there's a picture I saw of actually these, these workers that are standing in long lines, some of them had like buckets over their heads so that they could actually have some of them had light and some of them didn't and you know, what happened, production went up and what they realized was the Hawthorne effect was an increase in production because they knew they were being observed. Oh no. So yes. As long as they knew they were being observed, their production was going up. So my point is that sometimes it's not just so easily understood. There's a lot of variables. a lot of players, a lot of metrics and takes a lot of, yeah. So anyway, watch them every step of the way. That's a, that's a very, that's a very passive, aggressive way of picking productivity go up. Just point that out. So when you're being measured on, basically the widgets that you put through, as long as you're being watched and , measured. Actively being watched, you're going to do better and better and better. Yeah. so my point is, Hey, I, I, I don't know from that team's perspective, I think it would, I would love to have been on that aircraft carrier to be like, Hmm, what's causing this and it would be, yeah. So, and, and I would be delving potentially into some more. Hmm. What else is going, what's different about this team? What's uh, well, I'm like, I'm just wondering, like, because again, there's not a lot of like, again, the scrum guy's just like, do a definition of done. If there is one, just do one and follow it minimally minimally follow. Yeah. The bare, the bare minimum effort. But like, like the point of me bringing this up is like, if there is a definition of done and there are teams that are kind of playing with it and figuring out if we do some other adjustments, we get better quality or better results or whatever. Like what, what is your assuming? You have more than one team mm-hmm right. Cause that's, if it's just one team it's right. There's no reason to talk about it. It's super easy. Again, assuming you have more than one team or more than one product owner who has their own team each product owner has like two teams or whatever, and you have a, a whole program of team. You have eight teams or whatever. Mm-hmm, your definition of done is share between all the teams. How do you amend that later to say, Hey, when we run our tests through some kind of front end integration automation that this other team has done with 10% of what they own, they have much higher customer satisfaction or whatever. We should do that for all the teams and append it to our definition done rather than having all four product managers or product owners in the program, write it into their stories or whatever. Like we just want to do it program wide, is it development, leadership decision? Is it product leadership decision? Is it all the teams just kind of talking to each other and deciding it can be as simple as that. Right. But that doesn't happen that often. So it's usually we're talking about multiple teams. Yes. And typically, although not always, right. There's some sort of scaling involved. So depending on the scaling framework of choice in this scenario, it would be the person who is at that level. For example, in safe, it might be an RTE. In scrum at scale, it might be the chief product owner looking at this in, and then I, I feel like the. Circles of the ven diagram are actually closer together in real life than depicted on that diagram. So it could be a chief product owner in conjunction with their equivalent on the process side to talk about this and say, how do we align the teams, get them together for a bit and talk about commonalities and differences and come up with one version that can be perhaps ratified across the two teams. Let me ask the same question in a different way. Hoping they get a different answer and hopefully I'll get the same answer in a different way. I don't even know what I'm asking anymore. Hopefully they get the same passive aggressive answer. oh man, what if you are the first product owner slash manager at an organization and you have, let's say you have two development teams and your company's grown to a point where they bring in a product manager for the first time and a scrum master for the first time. So now you have like the full blown all the prescribed positions, right? the whole prescription who introduces. We need to have a definition done for the first time. And then how do you do that with your teams?, I think largely it falls on the process side. I mean, typically it would be the scrum master or somebody like that to say, Hey guys, how do we know we're done? Yeah. Right. And it starts there, but you set two teams. So if you have two teams and you have two different scrum masters, then they have to collaborate. Sure. To make sure that they have a common definition of done that goes across those two teams. Sure. And you scale up from there. Yeah. It, it is not an easy thing to do because often the teams would say, well, this doesn't apply to us. Right. Because that team has specific nuanced things they do. Yeah. So these, those things don't apply to us and vice versa. Sure. Sure. So you kind of have to go across the board and say, let's just raise it up a bit. Yeah. If you're doing mobile apps and one like, like one team web app and mobile app, one team's mobile developers, one team's web, like one team goes to the app stores for approval and the other team doesn't like, well, I don't need that in my definition. Exactly. Like, I mean, maybe you don't need your definition done, but I kind of think if you have two teams Ishe has a scrum master. I kind of think if you're gonna charge a scrum masters, but being the process owners, here we go back to a theme on the podcast., They should see the need to be like, Hey, our definition of done is out date. Our definition of done doesn't include these things that people have been asking about. They should see the things going on and know they've gotta facilitate a collaborative session between the two teams yep. To amend the definition done, or create the definition, done, whatever delete things, what, whatever they need to do., but if they don't see that themselves, there's nothing wrong with somebody product anybody. Oh, I was gonna say prompting them. I was gonna say, if they don't have, like, if the organization doesn't have SCR, like if, oh, there's that someone was just playing the role, playing the role. wear hat, wear a hat. So I've got couple, a couple of thoughts here. So number one, you mentioned something about Hey what happens when you have multiple teams and , so aligning across on a definition of done and then who makes that decision? Is it leadership, whatever it sounded to me that almost at that point, it could be pivoted to a definition of done that's minimally defined by the organization potentially at that point. Now you need to follow that. So there's a there's that, that could actually be adopted. Right. So there's that my next thought was we haven't talked about that. We haven't talked about it. Like again, the program where I was with a CEO who. If it's not in production and users can't use it, you can't call it done so dictates or I I've been in programs with a, a development lead. Who's like, if you can't deploy it to the environments, if it's not checked in, you can deploy it to whatever environment with a click. The, the definition of done for one program was it needs to be releasable with that that program was very advanced. It needs to be releasable, one kind of feature flags. And it doesn't matter which environments you're released to. So stage test production, that doesn't matter. That's not in definition done, but in that environment they were super advanced where they had their older releases behind feature flags and they handed off each stage of the release to whoever owned the environment is being released to. So the production users would choose to take the, the thing into their environment, but the development team would call it done, cuz as far as they're concerned, it's done and it, and all of their , automated tests have succeeded. Their reports came back with zero problems or no problems with the release. So the release and all the items were in it that were in, it are done. Mm-hmm but it wasn't in production yet. Mm-hmm because they handed off that responsibility to somebody else to choose when, to take it into their environment. Mm-hmm so basically you had you, I mean, and you could stack up multiple. At that company, you could stack up two, three releases to be like oh, oh, you, you have you have three different releases. Each one has different features that stack on each other. Well, I'm gonna reject the first two releases, take third release, which includes everything from the previous two and not the big UAT type of thing. Sure. And, and, and, and only do one big test. Like, so their definition of done was different than other places that I've been at. Again, a director of development had influence into that when I was talking about there and another was the, the CEO directly had influence into like, unless it's in production and people can use it, don't call it done. So I've been in a bunch of different environments with, with different, different stakeholders who made the call to affect the definition of done. Mm-hmm , that's why I'm bringing up. That's why I'm kind of hammering on like, well, who, who was involved and how do we know it's time to change and this like, cuz people that listen to this, that, that listen for more than 12 minutes like eventually they'll realize like they will have different experiences. That's right. I'm never letting it go. Well, just to kind of just try to wrap this up from my perspective, I just wanna say so I, I, I think I gave you the, so my thoughts in regards to being able to take a definition of done, that's been created by your your teams and potentially actually creating that as an organizational standard minimally, right. That's an option. the other thought I had was to create if you have multiple teams that definition of done, but, and, and I was trying to express this before, but I don't know if I got it across. I don't believe that you know, that they need, they do need to follow that minimally. But to your example, given earlier where you have a mobile app that doesn't apply to someone else that their definition of done can be different, can include. Additional items or things in addition to the things that are minimal. So in my mind, you would collaborate across your teams, find the, the cross section of things that apply to all. And then, and then in regards to changing, updating and iterating on definition of done, I do believe that the scrum master has a role in, I, I believe that the entire scrum team has a role in that. Sure. But I also believe that this, perhaps there needs to be some regular revisit there, there, there really should be some regular revisiting of the definition of ready and definition of done in my, in my personal opinion. Number one, but number two, I kind of think this could be self-limiting to use the term you used earlier in our, in our retrospectives. So to be deliberate about our definition of done, are we meeting the definition of done which items aren't we meeting? Are there things that we are tasked that we are repetitively putting in that we could actually include in the definition of done? So I think that that might be something as a scrum master that we could be more deliberate about and certainly create a bit of a cadence just to make sure that it's something that we are thinking about fairly regularly. I agree with that. And I also think another way to. Get input into that. DOD is what feedback are you getting at your sprint reviews? Mm-hmm are, are they feeding back to you that something's not quite right? Mm-hmm maybe it didn't meet your definition of done and, and the individual teams in that example, Brian had mobile app, web app, whatever, right. Those individual teams can have definition of done for their own output. Right. That's fine. But collectively, as a program group of teams, there needs to be a distinction between what is releasable versus what is shippable mm-hmm right. And based on that, they can say we're done, but we're not done done mm-hmm as a group, not as a team. So I think that's true. And I think too dependent on I've been in situations where dependent on the team, that the process actually for deployment differs between teams, which means that innately, that definition of done would actually, so the pipeline so not common, but but I have seen that happen and I, and it was for , some valid reasons and they were going through some, some, definitely some learning curve, but in that case there wouldn't be a hundred percent definition of done that would've met that criteria across the board. so anyway, those are my thoughts. I mean, it just in regards to figuring out collectively, a definition of done with your teams potentially adopting that organizationally continuously , inspecting and adapting and doing that on a regular basis paying attention to our feedback loop. Yep. Paying attention to in our retros, Hey, are we meeting our definition of done? We, if we aren't, where, why are there other things that are in our tasks that we could be including in the definition of done so that we don't have to repeat them in the task over and over again? so those are some of the questions I might ask. Is there an opening for a business risk? And like, like, think about like ear production or always having a two-man career, whatever my, in my examples before, like, can the product inject to be like, Hey, we're willing to accept risk to say that like, all your teams have to. Automated tests for all the software, except this one team who's kind of out there, like, is that a, is that even negotiable? Like not, not like that at that point, you are not doing definition of done. Like how can you have a team that doesn't comply to the definition of done? Yeah. You know, unless you, no, I think everybody to, yeah. So everybody complies to the minimal definition of done. What I'm saying is there might be additions to the definition of done, which would apply to specific teams. So like the mobile example mm-hmm yeah, yeah, yeah. That makes sense. And then one more thing that I just wanted to mention last one, swear. This is the reason I believe that it hasn't been further defined or explicitly defined in the scrum guide because it's complicated and there isn't a silver bullet. There isn't a checkbox, a checklist, and there isn't a simple solution to this period. This is something that needs to, explored and inspected and tested just experimented adapted. I think a lot of it is contextual as well because to come to have this idea that there is a singular definition of done that we can aspire to. I think that's a fallacy mm-hmm it is based on context. Mm-hmm is it yeah. It's based on context. Absolutely. Sure. Like, can I, can I not just like, could I just rattle off a boiler plate definition of done and everyone kind of be like, oh yeah, we kind of should be doing that at one company maybe, but you know, but yeah, but like at, at one company, but if one company's definition of done encompasses unit testing, I mean, unit testing's pretty basic to me, if you're not unit testing, we might not even be going full T D D you know, exactly code type of stuff. Like, because we know the company's not there yet, but if you were to start a company from scratch and say, like, I would just wanna make sure that whenever we code something, it doesn't break. Right, right. The test first, like you, you should. Writing your code in a way where it's a, a test first culture. If that is not implemented in your, in your definition done from day one, you're gonna have quality problems done., is there not a boiler plate we could deploy on day one? But I think you just answered your own question. So yes, you can definitely do that in that case. That's what I'm saying. That's why there's not a universal one. If you're not doing T D D, then you don't have this idea of, we should have all the tests written first, they should all pass. Cuz then they'll go. We're not doing that. Yes mm-hmm right. Ideally. Yeah. I would love for that culture to be more prevalent, but I know it's not there. I have one final thought so from my understanding and I could be wrong, but my understanding was the rationale for simplifying and changing some of the terminology and the 2020 scrum guide was to open it up to a lot more industries than just software development. Yeah, I get that. And what that means now is definition of done really does mean really different things to just software development. That's where I was gonna going when I say this contextual. Yeah. It depends on the product you're building, right? Yeah. And that's why it can't be defined in the scrum guide. It's ephemeral. What's your definition of done for this podcast? Right? It's that we are done.