AA121 - Self Organization Gone Bad

Self organization gone too far. Can self organizing teams go too far? Somebody told me a story once. That a team that they were on asked as part of self organization, if the development lead could just assign them all work and then they don't have to worry about going through refinements and they don't have to worry about going through sprint planning because the development lead just sends them work. In that, in that conversation. Somebody else asked, what they can do with team members who feel like all of the scrum events are a waste of time, and if self organizing, the, the why don't we just try it phrase being applied, carelessly. So this whole podcast is going to be about self organization, what are the signs it's going wrong, and then when you see those signs, what can you do to course correct? I, I feel there's not, there's not a lot of that on, on the interwebs about this. No, there's, there's a lot of wisdom about, how to do things. And then there's really not much, as you said, around, around this. Right. Throwing around these ideas with Reckless abandon even, I mean, just saying we don't need the retro this sprint because we just had one two weeks ago and we're pretty good. Yeah. Yeah. We don't need it. Let's cancel it. We're too busy. Self organization gone wild. It's a title of a podcast. Hey, yeah, I think, I think you just hit the title of the podcast right there. That's a, I don't know, like, I don't know if I'm brave enough to name the podcast, self organization gone wild. The process for this podcast is we're gonna go through some of the signs that self organization is to kind of run off the rails and Then we're gonna talk about what you can do to kind of course correct. So in no particular order let's start with the lack of structure or process adherence. So, this would be mine that I've actually heard a team, that a team has tried to, to get me to come along with it that I resisted, in their attempt, which was, we don't need to have sprint reviews. Oh, like we're an internal facing tool. This is real early in my career too. Like we're, we're an internal facing tool. All our users in house, we don't need to have a sprint review, or, you know what? Planning sprint planning versus refinement. We don't see a difference between sprint planning and refinement. We don't need both those sessions. We'll just only have sprint planning and do all our refinement as part of sprint planning because it's refinement and planning is they're just planning activities. We'll just do them all the same in the same session. Yeah, I think the Scrum Guide only mentions the word refinement maybe once and it doesn't even say you should do it. It just says you might find it useful. Yeah, so teams can hide behind that even they can say well look the Scrum Guide doesn't mandate it, right? So this is a great topic because yeah, definitely there there can be meet me on the team, like maybe the the powerful tech lead who's assigning work to people and saying you don't need to worry about Thinking about the work. I know what we need to do. Yeah. Right. And this, this can actually, even be a... A product owner saying, well, this is what you need to work on without explaining the why. So then you become a coder, not a, not a development team. You're just basically cranking out code without any regard to why. And if you don't know the why, how are you going to make a difference, right, to the customer? You probably don't even know who the customer is at that point. So lack of structure and process adherence. There's a lot under that phrase. You know, lack of structure, what kind of structure, right? And then process adherence, I think is self explanatory. He's just not following the process. I'm not suggesting you do it to a tee. I think you can suit the process or adjust it to, suit the, the needs of the team. I think the pushback. That's every, this is every Kanban team that I've ever encountered in the wild. Like when I start with a company and the team tells me we're doing Kanban, we don't need your scrum stuff. That's, too much structure for us. Too much overhead for us. We don't want, 15%, 20% of our time in scrum event, meeting time. Basically, we don't want to spend that much time in meetings. And, the pushback is what we're doing. Kanban we go on from one thing to the next. And then when you dig in. You know, they're doing Kanban, but they have no WIP limit and they have 87 things in progress. And the things that have been in progress have been in progress for a really long time. So you ask them for their, lead time cycle time, and they don't, they don't even know what lead time cycle time is. Maybe I'll change my mind as the podcast goes on, but this category is really easy to spot. And the leadership is telling you, I have no idea what the team is working on. I have no idea what they're planning to work on. This, these are all indicators of this category being a huge problem. You know, I've seen entire development teams get canned for this. You know, they just get rid of the whole team. Oh, I'd rather start over. Then try to work my way out of this hole to try to communicate and get this whole team of people plugged into my organization. They, they say, no, I don't want to do that. I just want to get rid of this hole. So I'll cut the whole program. That doesn't solve the problem necessarily long term, right? I mean, you start over again and then you have the problem again with the new team. I agree, but, but I've seen it happen because of this problem. Yeah. Yeah. And in real life, what that looks like is. There's really no perception of motion, right? Moving things forward from a leadership perspective. When asked, the team says, yeah, I'm working on that, right? Things stay in the same column, as Brian said, they keep starting, not finishing. So, easy to spot. Definitely, easy to spot. There are other, other signs underneath this category. Like, for example, oh, there's really nothing. Organized in the to do column. There aren't enough things there because they hide under the guise that well, we do emergent work, right? Okay, you do but you know one or two things you must know and whatever you do know must be prioritized in some way You got regularly replenish the backlog and things like that when they're not being done You know, they're not following the structure or the you know, or the process right so what can we do? That's the next thing right under each one of these signs. We're gonna Share with you what potentially could be done. I think you almost want to go back with a team like this to the definition of self organization. It doesn't mean you can do whatever you like. Which is often misinterpreted in that way, right? So the term self organization. So I think you might want to start there and say you have the autonomy as a team to do these things yourself. Figure that out as a team as opposed to Anything goes basically, because that, that's just going to lead to chaos. Earlier in my career, I remember working on development teams. A big reason for this kind of thing might be that the product owner to the team just doesn't show up. They're just not available to the team at all. So you get some of this stuff where it seems like the development team is kind of going off the rails and working on whatever they want. Because the, the team doesn't have the availability of each, dedicated, role that they should have. You may, you may also not really have a product owner. You may have somebody who is pretending to play the role. Maybe it's a proxy product owner or under this, this idea of stretching the term self organization too far, you have team members rotate. In the role of a product owner Fundamentally, I don't have any issues with that. But in practice you find that they don't necessarily Not every team member possesses the skills they need in order to Carry out the duties of a product owner effectively. Yeah, so that's the problem with it. They're playing the role for a while You don't have sprints. So let's just say for a week or a month or whatever the timeframe is. And so I think that's what you also need to look at and say, is this really serving the team well, because that's self organization gone too far. Probably. Yeah. I, I actually, I brought this up today I said that usually there's a, with regard to the products, there is a roadmap and there's a constant discussion about where we're going and there's a real near term part of the roadmap. And then there's a longer term part of the roadmap. You know what I mean? Because, because the backlogs emerging, like the stuff that's closer is way, way, way more detailed and we know how to measure it and we know what it is. And, and I said, there's another side of the organization about the organizational development of where do we want to go as an organization? It's 18 months from now. What, what type of organization, how do we want our teams communicating with each other? How many teams should we have? What's the breakdown? What skill sets do we need? And very rarely is that stuff, made transparent and then put on a board just like the backlog. And then, and then, and then we, and then holding people accountable in the organization to say what are you trying this month to get to this future state? And very rarely do organizations do that with their teams. And I feel, if you have this problem, lack of structure because your, product owner isn't available, or something, some other thing like that. And this, this piece of your organization, organizational development is missing. Like, you may never bridge that gap. You may never get there. The details you need are just missing, I think that's an excellent point. You make this idea of taking the level of, I don't want to use the word expertise, but you know, the prowess of a, of a team or teams forward with time. And a deliberate plan to do that. That's, that's often not there at all. People just muddle through, and form teams and, and disband teams, as you go. It doesn't need to be a, a plan that's cast in stone, but it needs to be an initiative that you can think through. And, and more importantly, have people who are accountable to move. Everybody in that direction, right? And that's missing most of the times, from my experience. If someone is listening to this, like, what can we kind of drop on them? Drop on them? Boy, my euphemisms today are terrible. They're bad. Um. What wisdom can we impart? What nuggets of zen can we impart? I think we impart enough zens, zens? At them? Something. No, I think the thing to recognize here is there needs to be evolution of your teams going forward and if that is not recognized then, the next step which is how you get there is obviously going to be missing. So if you're listening... And yeah, just remember that needs to be there and look back and see, I mean, how have you, how have your teams grown in the last six months, a year, two years, if you've been there that long? Yeah. I would say that evolution is occurring, whether you're tracking it or not intentionally guiding it to a place. That's a different thing, but that it's happening. It's happening with everyone you hire. It's organically happening. Yes. You might as well try to direct it, you know. Or at least try to influence that. Yeah. Yeah, yeah. Or get that, keep that resume updated. Keep that resume updated. I just wanted to say that I never say that. I never get to say that on the podcast. So I wanna say that! Moving on quickly, you notice that there is an environment of decreased collaboration. Usually it's between team members on one team. So let's, let's stick with that for, for the purpose of just getting through it quickly. Decreased collaboration, team members isolate themselves, team members that say, Oh, I'll just give me the next work item and let me go off or whatever. You know what I mean? Like I was on the team once where I was trying to encourage both I and the engineering, my peer on the engineering management who basically hired all the developers. We both were trying to promote a culture where, yeah, you could code features by yourself. I guess if you want to write, and then only come like only pop out at the end of the sprint or whatever at the end of the, at the end of your work, basically a code review time or whatever, and they be like, Hey, I'm done. Here's all my code. But we were trying to say like, Oh, the better process is to. Peer together and then you don't need this like formal code review deal at the end where you you know You go in front of somebody and they stamp your work if a pass fail, whatever The better way is to sit together any of the even better way is to take a couple people and sit together While you're coding the feature that we don't need all these reviews and all this stuff afterwards you you're already coming out with superior code by having more than one mind on it some people get it But some people are just like, give me my code and let me leave me alone. I want to go to my corner. I don't want input. Yep. Lock me in a room and slide some pizza under the door once in a while. yeah, I agree with you. I think there are other symptoms under this category too. Like for example, people, saying, well, why do we have to have a retrospective? We don't have sprints. So. What about this specifically? Comment is what about just skipping this thing? I have nothing to add, right? As opposed to a scenario where the team collectively says, Is there an issue here? Yes, there's an issue. We don't wait for a formal event to be put on the calendar. Talk about it. Talk about it, just hold it impromptu and just say, let's get together for a few minutes and hash this out. This one thing that we've just agreed collectively that is an issue. Don't park it somewhere, because when are you going to do that, right? And when you do do it, it's a longer meeting, which then in turn feeds that resistance and objection, right? To having this thing called a retrospective, just get it out of the way. So I guess where I'm leading with all this is that the team needs to decide collectively that there's Well, there is not a need for something that's been happening, and make a decision collectively and move on. and there's also why would somebody... Allow a strong personality to anchor the conversations, right? Maybe that person who is anchoring has more knowledge about the domain or the technical knowledge or whatever it is. So I think teams like this could use a facilitator who could come in and maybe just, try and level set a little bit and say, yes, you have this knowledge. Maybe just set aside a little bit of time and share that with others. Let's just move along on this particular meeting. To the agenda that we have. Yeah. Like there's, I mean, we probably could stay on this one, the whole podcast, this particular item, like a decreased collaboration. Cause the other side of this, you just hinted at the other side of this, which was, you have like a development lead that comes to your sessions and just shuts everybody down, you know? Oh, that's just. Terrible idea. We're not doing that. That's ridiculous. Why would we do that? I've been in sessions with those development leads. They're real people and they suck all the air out of the room. Oh, and you know what, product owners as well. I've seen product owners like that. Like, this is ridiculous. This is going to take the whole sprint. These two items are going to take the whole sprint. This is like a five minute task. And you know, I mean, they, they don't, they don't understand the technical details of going through it. They don't understand they're dealing with technical debt. And honestly, they don't care. They have no, they have very little empathy. And they don't care. That's the other side of what we're talking about. A lot of our tips have to do with talking to the members of your team, encouraging kind of the shared responsibility with the rest of your team members, and not kind of dealing with one person who's just steamrolling the whole conversation. There's another podcast for that, I'm sure. If your team is experiencing this though, just know that you're basically heading down the wrong evolutionary path. Or it's not even evolution at that point. You're going backwards. Well, you were talking about like, get someone who's skilled in facilitation. You know what I mean? Yeah. Ask for someone, at least, even if you can only get them for sprint planning. You know what I mean? Hey, is there anyone in the company that's really good at facilitating, even if they don't understand technical... Can we get them for our sprint planning time? You know, whatever, two hours every other week, four hours every other week, whatever it is, like, can we just borrow them for that amount of time and see if the business they just sit in the room and Hey, you, you were saying something, do you want to continue exploring that? Like you can do that without understanding technical details. You can tell when people are getting talked over and stuff like that. I would hope the product manager would have those skills. I really would hope I, I mean, I would hope there's enough counterbalance where that's not happening. Again, I've worked on teams where that happened all the time. So I, I know it's not completely reality, but also I'm trying not to spend a whole podcast on this. Yeah. we kind of talked about inequality and, and power imbalance, sabotaging your self organization, which we kind of talked about at the beginning of the podcast, talking about the a lead developer or whatever architect or somebody just, Assigns everybody, tasks. And there's very little self organization you can do. And you're like, well, you own today, you're working on widget a and Brian today, you're working on widget B and Bob today, you're working on widget C and then go off to your respective areas. Cause that's what I've tasked you to do. Here's your work breakdown. And you're going to follow these lines on the chart until this date. And then you're going to cut the quality and stop working on it there. Yeah. And you'll be done by the dates when I tell you, you'll be done. Yeah, that's right. That's right. Yeah. I mean, that's certainly going to stifle any kind of innovation. You might have, aspirations. Yeah. This is the complete opposite of self organization. This, this is command and control right here. Rather than collective decision making, which is what we were talking about before. Yeah. Yeah. Collaboration leading to a decision. This is authoritative decision making. What one, we all go to one person, make a decision, and then we all have to wait for that person to make a new decision when we have to send them new details or whatever, and then we wait and then we're, then most of our time is waiting. I mean, maybe, maybe life is easy in that environment. Maybe I need to retire and work in that environment. Om, and that's what I'm saying. You see, you want to retire and work in a command and conquer environment? yeah, that sounds fun. Right? It does for you. Somebody, yeah, for somebody, definitely not me. Another sign that your self organization is derailed is that your team is not meeting its goals or deadlines. I'm gonna put in parentheses, I'm gonna put deadlines with the little... The little star next to it, and we'll put milestones next to deadlines because like see the podcast we did, where, where am I see the podcast we did earlier where I talk about like hitting quote deadlines, they're just milestones. They're just milestones that you made up. Yeah. I'm like, all dates are made up. Everything's made up. That's what I'm saying. Welcome to the podcast. Everything's made up. Let's, let's ignore the obvious, elephant in the corner in this, conversation, which is all your deadlines are made up by somebody who has no idea about the work and they just give them to you and they're already in the past when they give them to you and you can't, like, you're just failing, even succeeding, you're still failing, put that off to the side for a second. Okay. And let's talk about the teams that they commit to sprint goals. They, they miss everything. They roll everything from one sprint to the next. You know what I mean? They say, Oh yeah, 20 points. No problem. 20 points. And then at the end of the sprint, they finish like five. And then continually every sprint after every sprint after every sprint is like that. You know what I mean? Like that, that's, that's, that's the way I'm going to apply what I'm saying now about the teams not meeting its goals. Or deadlines, basically deadlines that they set themselves and goals they set themselves with, well, with the product manager. Yeah, so if this is happening repeatedly, yeah, man, so yeah, self organizing so we're going to do this and we fail, we're going to do this and we fail. Somebody needs to now on the team say, it's not working. Why is it working? So let's get together and talk about it. Ala the retrospective right talk about it and say what are we going to try differently? Yeah, but Don't go out of your way and say I'm gonna suggest we do it this way now And that's the only way right I'd say position that is an experiment you say let's try for a sprint if you're sprinting Let's try doing this for a sprint and see if it Improves how we fare at the end of the sprint. If you're only delivering 50% of the work and then you try this one little experiment and you get up from 50 to 60, that's progress. So try and treat that as an experiment. You're going to find there's less resistance from your team members. If you're doing it that way, especially from those people that say, I'm just going to go along with them, the status quo. Yeah. Yeah. You're going in a direction that we don't normally cover on the podcast, which is, yes, you are regularly, you're regularly, I can't say regularly. You're regularly, look, space station, Regula one. This is enterprise calling. Do you, you're, you're regularly monitoring the team's progress. Like progress towards whatever goal they've set, but also you have eyes on their process and and how well they're adhering to their process Hopefully you do if that loop is operating in your in your country Hey, and yeah, if that loop is operating in in your organization in your world. Yeah. If you don't have a loop a Backlog, whatever roadmap or whatever that that helps say like here's where our organization wants to be In two years, you have no idea if you're on track or not like, Oh, we all want to be self managing teams that grab from business initiatives, create goals of their own interface with leadership to double check things and then, innovate and give us new things that we had no idea were possible or we're all punching the clock and, hoping like looking like, Oh, is it five o'clock yet? We're ready to go home because we're all in office. Cause our CEO said we had to be here. I was running out of ground right there. I, yeah, absolutely. So I'm assuming that you're tracking both of them. You're moving forward with the product, you're moving forward with the process moving forward with the organization and, and there are feedback loops built in at multiple levels, your own teams have feedback loops for themselves, but then you have a feedback loop. For the organization and what like what we just threw out right now like boom. Yeah, that's a lot of stuff. Most organizations don't have the organizational feedback loop that you referred to. Right? In fact, I would even venture out and say most organizations, even at the team level, that feedback loop, they're simply. We had a retrospective. We decided to do those two things. We put them in the backlog and then we forgot about them because we have other fish to fry. That's what I've seen most times. Now some teams are very good about that. Scrum masters as the facilitators are very good about that in that during the sprint, if you're sprinting, every couple of days, three days, they will bring that item up or those items up that they decided to improve upon and say, Hey team, we decided to do these things differently. How are we doing on that? And so out of sign out of mind is a bad thing here, right? Because you're just simply. I've been on teams before that will add some of their retrospective takeaways to the backlog. And it's, it's, it's, it's at that very bottom lane. That's like all other work. It's in that lane. You know what I mean? It's not really tied to another epic or initiative or whatever it's in. It's at the very, so when the, when the team scrolls a board and they get all the way to the bottom, the, all other work is like move forward with this process or figured this out or whatever, like that I've been on teams that do it. Boy, have there been a lot of teams that just don't, they don't have it visible at all. I'm a fan of showing this stuff on the dashboard. So, I encourage teams to look at the dashboard every day. In fact, I use the, the dashboard as a jumping off point from there to the actual backlog or sprint board, whatever. So they, they look at it and they can see a quick summary, if you will, where things are at, what was our commit. You know what I say, do ratio looks like, but they can also see what the improvement items were that were decided upon and then next to it, you put like progress on it. It's something not started. Then you can say, well, when are we going to start on this? Something in progress? My question normally would be. You know, we're gonna start on the next one. Is this done right? So they shouldn't linger is my point here. Most of these practices should not linger. You put them in effect and then you again inspect them at the end of your sprint and say, Did this work for us? Especially if it's an experiment to always look at the results and then Feed those back to the experiment and say, yeah, this was a success or it wasn't a success. And that's fine too. Yeah. Let's try something else. We talked about a lack of collaboration. We're going to talk about a lack of communication and coordination. Usually this is like the collaboration aspect is inside of a team and communication coordination, I feel is outside of it. Like the team out to the rest of the organization. And, I would say organizations catch this problem faster than they catch collaboration inside the team. Like they, they can see a team working in a silo that's only kind of like looking inward, very insular type of team. I can think of a bunch of teams that I've seen like this. Yeah, these two C's as opposed to the other C. Yeah, I agree. These are usually prevalent. You know outside on the periphery and and again symptoms wise teams will say we're waiting on So and so but that's an external dependency. That's right, which they put on the board as a dependency and Yeah, those scrum masters that aren't really doing the job, right? They will say yeah, but You know, it's there. We raised it. You raised it to to where? Don't put it on a board. Try and focus on getting it off the board. Right? So try. Yes, it's one thing to make it visible. Fine. But then what? Right? The goal should be to get rid of it off the board, which means either to accept it, mitigate it, resolve it, etcetera. And doing that involves interactions outside the team. So when you have this kind of a challenge, what it what it looks like in real life is You know missed deadlines or or work that's carried forward right and then people hide behind that we're waiting on them, right? That's the classical. Oh, but the holes on your side when you're in a boat, right? And there's two people rowing one at each end. Yeah, I was on a team one time where the management, the people above product, the business unit management, kept saying like, well, we need to add another tool other than, I don't remember what we were, I think we were using Azure DevOps. They're like, we need another tool. To better map these dependencies so we can tell what's got to get ended before something else can start and what's got to go in what order and I remember it like it was like that meme with a dude getting thrown out the window. You need to not consider picking things up that have dependencies. You need to break these silos down where I don't have to go do all the testing with that team and do all the data modeling with that team and do all the data processing with this team. I'd rather have a data processor, data modeler, data analyst, all on one team and do the whole thing. Oh, what is the, what is the analyst going to do when the data modeler is building the model? I was like, sit over their shoulder and learn how to build a data model. It's like building data model is not difficult at all. But, but, but we need Enterprise Architect, or, we need to create ER diagrams. Yeah, tooling is not the answer here. You have an org design issue, you have... An issue to sort out with the teams, communication, collaboration, right? So you need to break those barriers down. I agree with you. People say we need a different tool. Let's just have a shared Google Sheet or something. We can put all our dependencies on there and we'll assign them to people. No. Try and get those, get everybody in a room and say, look, we have these things. How can we sort this out? Rework the way your work is currently structured, slice it differently so that these dependencies are largely, avoided. This is lack of communication, coordination, like lack of coordination might just be lack of skill in coordinating. You know what I mean? You don't know who to talk to. You don't know when to talk to them. You don't know, like, there is a time to do planning to talk to other people about what you're about to do to say like, Hey, this is what we're about to do. Here's a concept. This is what we're thinking about. This could be as easy as bringing people in from other teams or like tech leads that are responsible for other teams. Bring them into your sprint review at the end of your planning when everything's planned to just have them just review everything you're about to do with them. It takes 10 minutes. That's not a lot of time. You spent four hours in the room, 10 minutes. Hey, this is what we're about to do. We're going to interface with this system. We're going to pull this data. We're going to do this. We're going to transform it this way. We're going to load it here. We're going to do this. That looks great. I mean, that's a great plan. Have you thought about this scenario? No, we didn't. Here's how we might do that. Whiteboard out whiteboard out, change some plans done. You mean like that's, that's an architect. The way I think of an architect is. I'm supporting the teams. I know way more about the system than they know. I want to make sure that what they're doing serves the whole organization. I'm trying to help. Sometimes teams are like, scared of asking for help. We're having a planning, but I don't know. This guy's calendar is pretty full. Does he, does he want to show up? Just, just tell him, hey, I see you're in a meeting. If you get done early, show up to the end of our session, just 10, 15 minutes before the end of it, if you can, if you can pop in, and just talk to people to, to, to get you through this. And that that's, that's the kind of stuff that like more likely what will happen is you will get through planning. You won't have all the right people to make all the decisions that you need so you'll make a tentative plan and you'll go into the sprint review tentative plan and then as the plan gets carried out and your developers do work, you'll change the plan because then those people become available rather than them coming to your sprint reviews. If the cross team, Members that you require become too busy or whatever then you have that conversation separately Okay, our team leads shared across eight teams. Is that is that really believable that they can support eight teams? Maybe we need another team lead. Yeah, I think timing is is critical, right? Like you said, just do it just prior to you're about to start Working on something and then be open to change. Don't say this is our plan. Oh gee, we got to change our plan now. Except that the plans will change. I'll say that for those of you in the back of the room, the plans will change. You can get people in your meeting and you can do stuff after the fact. The better way would be to be proactive about it. And get the people in while the decision is being made. Cause that's the, monetarily speaking, that's the cheapest time. To make the change to your plans before you've done any work for me, but your plans are just ideas. They don't cost anything. There's zero, 0. But they, they turn into mucho dollars pretty quickly if the timing is all right here in all this. Mucho dinero. Yeah. That's, that's, that's goes back to episode one right there. All right, let's move on. The team is not able to adapt to change. That's a symptom. The team not being able to adapt to change. That's a weird symptom because how would you know that teams not adapting to change? Well, you wouldn't know because, often what happens is you've got one or possibly more team members saying we set out a plan. We're going to follow the plan. Or we need more requirements. Yeah. Oh yeah, exactly. We, we need more requirements. Things aren't clear to me, so I'm not going to start working on this. Right. So that, that happens way, way too, too often for my life, but it does happen all the time. I'm sure people. Watching and listening have come across this as well. The team is not able to adapt to change. Change is uncomfortable for them, right? So immediately what happens is they put up their guard and you get change resistance. Now when that happens, what is, what's the outcome of this when there's change resistance, right? I think the team feeling stressed and overwhelmed also fits in the category of the team not being able to adapt to change. I think it's the same thing. I put in the adapt to change category we welcome changing requirements. I was on a team once that was working in legacy code code that we know nobody on the team had either developed or tested. We knew the business case in which the application was used. But we didn't know what changing any one section of the code would do. So we were real uncomfortable working in that part of the code. So we had to be okay trying the developer, trying to change things and then us testing different scenarios. And if something blew up. We had to be okay with it, like it was, there was, there was not like automation and stuff like that around, there were, there were at that company, there was automation in, in testing, but it was in different areas, newer pieces of code, not the old, old legacy stuff. Probably because people didn't have knowledge of the legacy code to automate it, right? No, yeah, not at all. And also the legacy code. What's very old. I mean, the tools that they had available back when that code was written were, were archaic at the time. Like there would have been, even if we would have had that automation, it would have been in some kind of language or whatever, or tools or whatever that were haven't been supported for years. Anyway know? I think of the same thing today. I think of teams that, they say, Oh, I need to sign off on all these requirements and I can't change. You know, I, Oh, I don't want to change any requirements once we get a sign off because something breaks it, we're going to be on the hook to spend support hours to fix it. That's what I hear. You know what I mean? I hear that, especially when I was on contract with, with the big contractors and like, I don't mind naming them because they're so big that nobody on like, like IBM and those guys, like contracting teams from Deloitte and IBM and stuff like that. That's what they would say is like, Hey, yes, there is a gap in the requirements around what you've identified and what you've kind of talked through with the businesses, but we're not going to fix it. Because if we fix it, and we generate other bugs, now we're on the hook to fix those. And it's gonna come out of our, whatever, hypercare budget, or whatever, some kind of budget, right? That's already been paid for ahead of time. And they're just not gonna do it. So basically, they're, they're averse to adapting the change. Understandably, right? They're feeling stressed and or overwhelmed. The other way I've seen this happen is the team are initially Okay with change right rapid rapid change you but they take pride in what they're doing So they're working on something and then they told to drop that work on something else drop that work on something else They never get to see things to a completion stage, and that gets frustrating for them. I've seen that. And so that could actually take that toll as well on their psyche, right? As a team. So, yeah, they could be feeling stressed. Again, I want to go back to the facilitator because they can help immensely here. As a catalyst to explain to the team, why change is happening. In some cases, not all, in some cases, change could be happening for the wrong reasons. And a skilled facilitator could try and minimize that if not eliminate that. So all of these things add up to, making the team more open to change. The only thing we haven't talked about is a team that is constantly stuck in forming or a team that hasn't figured out a way to work through, conflict in a healthy way. Basically a team that's always in conflict. I mean, we probably should have hit this real early in the podcast because this is like a... Low hanging fruit type of conversation with self organization like obviously you're not like on the Maslow pyramid when you're just trying to like find somewhere to Sleep without the rain raining down your head like you're not going to worry about like, am I my ideal person today? Like obviously that's not going to happen. So if the team is constantly fighting with one another, you're not going to go. And like, well, how can we better collaborate and coordinate between other teams in the organization? Obviously you're not going to do that because everyone is. Struggling not not to be fighting in constant conflict We've done a podcast on psychological safety. I'm sure we have more than one. I'm sure You, you need to start by stressing respect. This is a long and winding road. Uh... Like... Another song now stuck in my head. That's right. Paul McCartney would be proud. if you don't have this culturally, I'm worried about you. I mean, there's some things you can do to try to start this, but I would hope that like the, it's a team thing, not a culture thing. You know what I mean? Like a new team in forming mode. Have to figure out how to evolve and, and, and earn and learn this between team members. I'm hoping it's just your new team and not a culture problem. If it's a culture problem, that's way outside the scope of this podcast. And keep that resume updated. If it's a culture problem, you will not, you'll be basically, you'll be pushing water up a hill with your bare hands. So yeah, I agree. Whatever the reason might be, make sure that this problem doesn't persist over a long period of time, right? To the extent you can influence that. Because if it does, you're not really moving along that evolutionary path that we talked about earlier. If you focus on the work rather than on the people doing the work. It does help with this and there's a bunch of stuff you can do tiny little things that help with this. And if you can do a bunch of things to help with this, maybe, maybe you can move to the norming phase and move out of the storming phase and get quickly get out of this constant conflict. Although what you said about like have a moderator or a facilitator or somebody with good facilitation skills and someone with good EQ, that goes a very long way you're not getting out of this category by yourself, just, clocking in and showing up at the office every day. Like that's not enough to get us right. This will not go away by itself. Yeah, absolutely. There needs to be definitely overt effort, in order to make this better for you or covert effort, whatever works for you, but yeah, definitely bring the work to the people, take the people to the work. Did I get that backwards? Who knows? I was going to go all French revolution, but I'll, I'll, I'll wait. Yeah. If somebody is saying, Fred, you did this, Bob, you did this, Mary, you've only done this, that kind of thing. You don't have a team of eight people. Let's say you have eight teams of one person. Yeah. That's not right. And that's definitely not good. Yeah. Well, that's it. That's our list. Hopefully this brainstorming session about self organization has been helpful. And if it hasn't, keep that resume updated. No, I don't, I don't, if it hasn't, we'll give you your money back. Well also if it hasn't like arguingagile.Com, like we got a form on the site. Yes. Give us some feedback and, like, and subscribe down below. That's right. Be kind to one another, everybody.