Ray Arell: 0:31

Good morning and good evening everyone. Welcome to the Agile Community Network. This is episode 106. Today we're gonna talk about dealing with agile burnout. Just as a reminder, we are community supported. Please, if you have a chance, go up to acnpodcast.org and look at our sponsors, reach out to them, become members, whatever it takes to thank them for their contributions that make this show possible. And also the individual contributors that go up to New Agility and give us donations. That helps us to pay for the webinar system and all the other things we need throughout the year. Speaking of that, we are coming into the next year. This is the second to the last session before 2026, which is bizarre to think about that we only have one more show beyond this one left before the new year. If you go up there and take a look again on cnpodcast.org, we could use your financial support. We do have some doubt coming into next year on what we are expecting, and in order to continue to bring the show, we do need your help. I'm joined every month by some co-hosts that have been with me for a long period of time. Shauna, Diana, Jorg, Sheila Eckhart, Sheila McGrath, April Mills, and Hendrick here to get the conversation going along with all the people who call into our Monthly Live event. The goal is to hear from all perspectives. If you're new to Agile or if you've been doing Agile for a long period of time, all of those perspectives, we want to hear those. Be a part of the community, be a part of the conversation. Dealing with agile burnout. I was talking with a couple of people about a month ago, and they were dealing with the issue that their team was not feeling it any longer. They weren't feeling the agile vibe. They felt like they were just stepping in, and every day seemed like the same old thing. The pressure of delivery, they were dealing with some breakdown in the system with poorly formatted backlogs. The priority of things were changing so rapidly, which by the way, priority changing is a part of the nature of Agile. One of the reasons why we have iterative development is that we sometimes need to change because the customers decide that this might not be the right path. If you amp that up, where it doesn't seem like there's a rhyme or reason for that change grounded in customer need, and it just seems like you're developing things that nobody seems to want. That really starts to drag down team morale. Also, sometimes the ceremonies that we do, for example, retrospectives, when you do retrospectives and put in a whole bunch of things that need to be fixed and none of that stuff gets fixed, that also leads to burnout. So you find that even though that you're going through, you're not really leading the change in the organization at all. It just feels stagnant. The lack of stability can lead to the burnout of our developers. And there's a lot of different ways that this can be fixed. This is where I want to hear your guys' perspective. But from my view, I think that there's always needs to be somewhat somewhat of a refresh on Agile's core purpose. Why are we doing Agile within the organization? What are those values and principles that we want to embrace? And how do we accomplish those with the types of ceremonies and tools that we have? Needless to say that over time we overcomplicate things. It's human nature, I think, sometimes when we start putting in processes, but we don't take them out when we don't need them anymore. Also the sustainable pace. I remember a sprint review one time when we were doing Scrum and we were at like sprint 70 or something. And there's a point where teams over time will lose stability. The sustainable pace falls off. There's real work to get the team back into hitting the pace again. I'm curious, how do you create that sustainable pace within your organization? And then just reconnecting with the purpose itself. Why are we developing this product? What where are those customers and what are the customers giving us feedback on? Nothing recharges a team better than hearing great things from the customers. And even sometimes hearing not such good things. It's a way of stepping up and saying, okay, here's the things that we need to go work on. So the questions for today, are you seeing Agile burnout? Have you seen it within your organizations or organizations that you go in and help coach? What are the signs that you look at when say, okay, oh, this team seems like it needs some help because they are hitting that burnout situation? What steps would you take to fix it? What are the types of methods or things that you would do as a coach, manager? I'm curious to hear what you would do. So to kick us off, Diana, do you want to take a stab at this?

Diana Larsen: 5:35

Yes, of course. And you brought up retrospectives as a major contributor to burnout. I do think that frustration of holding a meeting, having some conversations about all the things that are wrong, and then either not identifying anything to fix or identifying something to improve, and then seeing no follow-through on it, or the having no plan for follow-through on it, or maybe it's outside of your control, is frustrating for the whole team. I've seen retrospectives that end up just being a list of here's the things we learned and here's the things we'd like to change, or that we think we should do differently. Nothing further than that. You end up with two lists, and that seems like a big waste of time to the team and to me. Then there are the ones where they actually pick something to move forward on, but there's no plan for moving it forward. No team member steps forward to say, I'd really like to own this for us for this next sprint and see if we can't make some improvement on it. There's a lot of ways in which that gets stalled or stuck and is frustrating and feels like a waste of time. Anytime we feel like we're doing something that's wasting time, that's the path to burnout that really does move us in the wrong direction, really. One thing, one thing I want to mention is that Esther Derby and David Horowitz and I have written a second edition to the Agile Retrospectives book. Please look for that because this is one of the issues we have addressed that wasn't addressed on the first edition. And I'm going to also drop a link in the chat to an activity called Circles and Soup. It's in the second edition of the book, and you can find it in other places on the web as well. This activity helps the team identify the source of their difficulties and where those might come from. Are they in the team's control? Are they things the team doesn't control but might be able to influence? And are they things that are completely outside of what the team can move on their own, give suggestions about improvements you can do wherever you start on that? And the recommendation is always start with things that are in the team's control. And that they feel enthusiasm for fixing. So that's one part of it. But I think the retrospective also is a great place to bring up other signs of burnout that you're seeing in your team. Here are some other things that we are feeling frustrated about. Here are some other things that seem to be holding us back. All those things that make us feel like we're trying to move forward and being blocked. So making sure that you're identifying impediments when they come up and so on. But I definitely see Agile burnout on Teams all the time. Another big source of it is when it's a scrum team and there is a scrum master, and that scrum master is also supposed to act as the product owner. They've got a double assignment, or vice versa. They're the product owner and they're also supposed to have as a scrum master. And what happens is that that those two roles have competing goals. Often things that the scrum master should could be doing get pushed to the side to add more on the product owner side, or vice versa. And that creates confusion in the team and gets in the way of the team being able to do what they need to do. So that's that's another thing to bring up in a retrospective and talk about how can you, how can the is that within the team's control to make an adjustment? Or is there some other party they need to influence to say, this way of organizing this team is not working? What can we do to fix it? A lot of it has to do with having a team that has psychological safety so that you can bring up the fact that we're beginning to feel burned out, we're beginning the frustration levels are getting really high in our team, and we need to do something about it, or we're going to be broken. Those are the top of my head comments to make about it.

Ray Arell: 10:29

Do you all see not just the shared role with the product owner and the scrum master, but also where a developer is not in just one team, they might be in multiple teams.

Diana Larsen: 10:38

That's the multi-team assignments that you know where you that kind of multicastking across work roles is just all kinds of research that says why that I can't put my hand on any of it right now, but there's a lot of it. If you are assigned more than 60% to a project, that's the project that's going to get pretty much 100% of your attention. If you're assigned 30%, 30%, and 40%, there's so much waste in the shift of focus that it impacts anybody's ability to perform well. That builds in a lot of waste into the system. However, somebody is being split across teams, it it's a problem.

Ray Arell: 11:28

Yeah. I appreciate that. I see all of those things, and thank you for those good suggestions, especially the I need to get the next revision of your book because I do want to read that section. Scott, what do you have on this?

Caller 1: 11:41

I was running retrospectives with my team, using ideas boards every two weeks. And the team wasn't really burnt out, but I looked at myself in the mirror one day when I'm like, I'm being lazy. This could be better. I need to be better. I bought Diana's book and started offering the team different formats. Then I started researching activities like journey lines and moving motivators to keep things fresh and offer new things to the team. The thing that I liked about different retrospectives is it asked the same kinds of questions but in different ways. So it got the team thinking a little bit differently about the system that they worked in every retrospective. And it kept things fresh. The other thing that I've always talked to the team about is, especially in the retrospectives, inspecting and adapting, continuous improvement and finding things that we can iterate on to make things better tomorrow than they were today. Hopefully, if things are getting better, teams are feeling good about themselves, right? Even looking at things like your definition done in team agreements, not getting lazy with those as a scrum master or a coach and being like, hey, look, every quarter at least we got to, or somebody new joins the team, we got to look at these things on a continual basis and update them so they don't get stale. As things get stale in routine, that's when burnout starts. I also like to review the history because when you work on lots of small iterations to make things better, teams quickly forget they've done anything and think they haven't done anything. So I like to take them back and say, hey, six months ago, this is where we were. And over the last six months, we've improved this. We've iterated on them, we've improved that, all towards making life better for ourselves so that we can offer more quality in a more timely fashion to our customers. Many times you're like, oh, I didn't even think about that. And the other thing too is sometimes just have some fun. I have in the past played cahoots with a team every sprint, take an hour out of a sprint and play, do something that's not work-related to try to keep things light and introduce some things that aren't just pounding away at what's wrong.

Ray Arell: 13:55

I like all the suggestions and especially just going off and having fun with the team. I think sometimes when we look at the daunting backlogs, we we don't realize that we begin to slow down. And in order to speed back up, we might just need to take a break. So that's thank you for all those suggestions.

Jorg Pietruszka: 14:18

Yeah, multiple thoughts on this. Sometimes it's as was mentioned already by Scott, a bit it's a bit of if you're doing the same thing over and over again. People feel that the energy put into them as support or anything is missing. Grab the opportunities to do something different. Especially now with Christmas time, instead of looking back and improving, look forward and ask what's the best improvement we need to scale that mountain that's ahead of us. Or when the product owner is not present at the retrospective and is welcome, use that to talk about his contribution and make it a recognition of his contribution to the team, what's good. You can then add improvements to make his life easier or whatever. So that that's definitely one thing. And then looking from the personal point of view for satisfaction with what you're doing, you need some kind of autonomy. If you're not in control of your fate as a team, that's the first thing to change, then you need mastery, which means you still want to improve on the technical side. If you're doing everything the same way every day and there's no new technical challenge, that's as damaging as you can't do your work because you don't have the knowledge. So that you you might need to add some diverging responsibility, different perspective on the technical side as well. And then last but not least, there's purpose. Bring in people to the team who tell them why their work matters, for whom it matters and what the contribution is. Do it as often as possible and as emotional as possible. And that's one thing that I use to detect if a change is definitely needed. That's if emotions helps out of the team. If there's no laughing, joking, or even frustration, then something is definitely amiss because we we're not automatants, we're not just doing our work going home. We are spending a lot of time with all those people. So there needs to be a bit of human element there as well. In my very first company, the appraiser question that was to be asked, among five others, a really significant one, brings humor to the team. And everybody needed to provide examples, how they positively did this because this is so energizing and so positive. That's my last tip. I think I picked it up from Darius, maybe he's here. It's the happiness meter that ask people how happy do you feel about the job, about the team performance, how willing are you to work just on a scale of one to five. If that degrades, then it's a warning sign that something might be wrong. And it's a great conversation enhancer if you have trust in the team, because then people and I've happy to say I had that happen, step on and say, I'm really feeling bad this week for that and that reason. So bear with me if I'm not really constructive today. And as long as they deal like this with such a situation, it's really helpful. If they keep it to themselves, it's dangerous.

Ray Arell: 17:31

Those are good points. What are some examples of new technical challenges that you deal with?

Jorg Pietruszka: 17:37

For my people doing really low-level software on controllers, it's really getting all that data used somehow so they can play and they are not challenged directly for the direct work because they still need to make these devices work in a rather constraint-specified form. But learning from what they do and how the things work to improve it is something where they can be really creative and have a Hoi Rika moment just to give an example.

Ray Arell: 18:08

Also, one of the other things on sustaining work, where you just have to sustain the product. I've seen companies that they'll just create a team that does the sustaining work, and then there's other teams that do all the new cool stuff. Do you not recommend creating the sustaining team? Does that work shared with everyone?

Jorg Pietruszka: 18:27

Yeah, I believe in what you do your own. Normally, if you know there's a team that will iron out the last bug, you will leave much worse things behind, unless you have a really high respect. There are some situations where you get a lot of stuff incoming to have it pre-sorted by people just learning the system. So as a transitionary state, it can be very helpful. As a stable state, fixing other people's stuff is a is a skill and a capability. So if you have people who really excel in this, that might be something but you need to hire for and build a team and praise it. And they probably then need to be the service organization's technical backbone. So they're no longer really in research and development. But in another role, business sustainability would probably be a thing to really value what they do, but don't get low-paid people to fix the bugs of the high-paid people. That I think is rather disrespectful, especially for their learning, because you by construct of the teams don't want to elevate them to the next level, which is probably rather stupid.

Ray Arell: 19:41

I appreciate that. Kyle. Or I may not be pronouncing Kyle. You did great. Okay.

Caller 2: 19:49

It's smoke Hill, but it's pronounced Kyle. Any of our German friends might know much exactly how it's pronounced. I just wanted to share a couple of things on this topic. I've presented a number of times locally in my area around this issue. One of the things that I don't often hear other people share is focusing on, for lack of a better term, the scope of the retro. A lot of times we get into a retrospective meeting and we're focused on the last break. But teams have issues that are outside of the work of the last two weeks. Occasionally I'll have a retrospective where we cover either a longer period of time or focus on a specific area of the work that we're doing. One of my favorite ones is just to ask the team if you had a magic wand and could fix anything about the organization, what would that be? We talk about that. One of my favorite examples is to share that my organization, the team really wanted us to improve the development environment. But in order to do that, it's an organizational-wide problem. And so we set off after identifying that as the key problem and we worked at it for about a year. After about a year, everybody was on board and we upgraded the development environments. Everything went smooth. The team was really energized, but uh so that's one of the things we focus on. One of the things I've done to energize team members is to loan a team member out. Sometimes there's another team you're familiar with, and they're struggling with and they can use a boost. And you loan that team member out maybe for a sprint, but usually I try something a little bulker. The team member has to be on board with this. By doing that, they get exposure to different ways of working. When they come back to your team, they come back with new ideas, which can be energizing. Loaning a team member out may not work in every situation or for every organization. That's just another way to keep things fresh and keep momentum going and getting new and fresh ideas coming back to the team. And now in your role, what do you do? I'm an agile coach. I've been an agile project manager, agile scrum master, but most recently just an agile coach organization called NellNAT, which does do the loan servicing pressing.

Ray Arell: 21:51

Do you find that for your own coaching, rotation is also important?

Caller 2: 21:56

Yeah, in fact, one of the things that we and I was I was on a team with two other people, one of the things that we do is set a limit on the coaching engagement we're working on. When that limit gets hit, we get together a team and say, okay, should we still work with this team or do is it time to change things up? We have goals for everything. When those goals come out for team, maybe you're gonna finish that coaching relationship because the team's passed what they needed to do for. Or maybe you're gonna shift them to another coach because that coach brings you.

Ray Arell: 22:26

Yeah, no, I love that because I do believe it's the same thing with like leadership, any type of leadership, knowing what your skills are and knowing that you might not be the right person to fix that issue or to help. An important part of coaching is understanding that I'm not the right person to work on this, but I know the person. And we let's get them in.

Caller 2: 22:47

Yeah, I think burnout's about the rut, a lot of times. You're just in a rut. And identifying what that rut is probably the best first out and trying to make things crashy.

Ray Arell: 22:57

Tully agree. Yeah. Sheila, what do you have on this?

Sheila McGrath: 23:02

I think most of the teams I've worked with have been working with other teams that were not agile at all. So some of it is the challenge of finding a way that doesn't interfere with the team's goals. A lot of times it's teaching them how to interact with these teams themselves rather than having to escalate everything to management, understanding what the other team's priorities are requires some conversations within the team and with management to figure out how to work more effectively. Another thing that I keep running across is it used to be that you'd have a scarce resource in somebody who knew old mainframe systems that you had to interface with. But now there's so many new tools out there that you wind up with someone or two people who have the expertise in a newer tool, and they get spread across every project there is. And there isn't really any way to avoid that until you get other people up to speed. One of the tricks is to get management to allow time for knowledge sharing that's not specifically project related. That can be very motivational. Another thing that keeps happening every place I've been is meeting burnout. You need to have some period of time blocked off where you say, no meetings in this time frame unless someone on the team schedules it themselves. It can't be something organized between teams or by management to give them some focus time to actually work. The other thing that I see happen is people sometimes estimate higher consistently. Like they try to estimate three times the amount of time that they're actually going to need because they know management's gonna cut whatever they're given and say you have to deliver by this date, whether it makes any sense or not. And trying to get management, especially product management, to listen. If you want a product that's viable, you really have to give us time to develop it if it's something new. If it's just little tweaks and bells and whistles, then maybe that'll work. But if you're really bringing something new to market, you really have to not try to dictate the time frame, which is really hard when you're trying to organize marketing campaigns and make sure that customer care is ready, to not be able to plan way in advance and just say, okay, in six months we're going to do this and make it an immovable date where you're going to bring something out that nobody's going to be proud of if you're not careful. That's really a mindset that you have to change with management, internal to IT management, but also at the enterprise level, you need to make sure that the enterprise understands what agility means. Those are the things I think about.

Ray Arell: 26:08

So I'm curious along the line of deadlines. To me, deadlines exactly as the word says, it's a deadline. If we don't get it out there by this date, we won't have a product we won't eat. How do you push back on that? How do you discover whether the time frame is arbitrary or made up? How do you combat that within organizations?

Sheila McGrath: 26:33

Sometimes it's not movable. If it's something like regulatory deadlines, you must have this in place because there's a rule that takes effect then. Or you have a product that's going to hit this condition, and the development to support the product kept getting stuck in the backlog and wasn't getting done. And now you have a deadline. In one case, someone high up in the organization had gone out and said, by this date, we will have this product on the market. And it was a new product with new functionality, different than anything they had done before. Now the credibility of the organization is on the line because somebody spoke about it publicly before they asked if it could be done. And that can turn into a death march where you have to say, okay, you said that we must have it by this date. Therefore, you must support giving us the resources to get it done by this date. Can you even find the people to do it if there truly is an immovable date? Sometimes you can, sometimes you can't. And then you have to set up how are we going to triage the problems that we're going to have because we didn't have adequate time. And what are we going to do to fix it? How are we going to prioritize when we know we're going to have more problems than we would like and the product's not going to be as clean as we would want it to be. And then you just have to educate management about what it's going to look like when they're going to get customers complaining that problems wouldn't have been there if they'd allowed us more time to develop.

Ray Arell: 28:06

And that's the quality triangle, right? Quality cost and time. Something's got to give one way or another. One of the ways I deal with it is that the data is showing us that we're not going to hit that. We need to reduce scope. What I find a lot of times is the must-haves. A lot of these things are not must-haves. They were just someone had a whim that they thought that was going to look good on a sheet or because the competitor had it, but no one uses it. So that's always a challenge. Let's see, Isin, what do you have on this topic?

Caller 3: 28:37

Yes. So for me, it's the one of the biggest thing is the team dynamics that I've seen to cause burnouts. If you have a bunch of people working together that don't gel, have different approach to things, it can lead to very difficult conversations. And I think Agile just basically put that under the microscope just because it requires a lot of collaboration and teamwork. It turns what could be minor issues into a bigger problem if people have to interact every day and don't get along. To me, one of the examples, for example, the sustaining engineering guy was brought up earlier. I've I've was VP of engineering for a while. Big, I don't know, agile guy from the VP level, from the engineering side. Trying to build the sustaining engineering team, I had to basically ask the question who wants to be on that team. Sometimes it worked out well. Sometimes you have people that want to run it the same way it runs for new features using the same processes that cause issues with the team members. I think this is one of the big ones I had to keep an eye on, evaluate the teams, see how well they're doing as a unit and how they could improve, helping them either to improve or change if needed.

Ray Arell: 29:46

What's your role in your company?

Caller 3: 29:48

I'm a co-founder for a small startup, two people, but I ran the engineering for 10 years before that.

Ray Arell: 29:55

Okay. I'm curious. I've seen a downturn in investments of training people post-COVID. A lot of companies are saying, if you're going to go learn that, go learn it yourself. We're not going to make that investment. Do you think that's a bad choice by companies not to make those investments?

Caller 3: 30:12

I just came from a VP of engineering group where they were talking about AI and how they approached their teams about encouraging their teams to use it. I asked Do you guys train them on how to use AI? How does it help a junior engineer to a senior engineer? All looked at me like not really. I'm finding that to be less and less, and I don't know if AI is causing some of these issues, but for some reason there's not a lot of investment in that area, money-wise or effort-wise by leaders.

Ray Arell: 30:40

Yeah, I think it's a dangerous if you get to go to an external class someplace. That's one way of combating burnout because you're learning a new skill. The AI stuff, I think you're right. You hear it on YouTube all the time. They call the AI slop of people just producing something but have the AI just do it. I know some people in DevOps organizations who are doing nothing more than having to go fix AI code because that's all the junior developer checked in. They just got the result from the AI system. They didn't do any refactoring themselves. They don't even understand the code. And yeah, I think that's a huge challenge. So tell us just a little bit, a plug for your business. What's your founder? Congratulations. What are you, what do you what are you going to do?

Caller 3: 31:30

I'm building an AI-powered agent for agile and delivery coaching. Our goal is to help agile coaches scale in organizations. What I've seen, and I'm pretty sure a lot of you guys have seen it, is teams or companies hire very little number of coaches compared to the numbers teams that they want covered. We're hoping that the AI could help get them the visibility, help them push. Like one of our first virtual building is helping the team to prep and run stand-ups and give them coaching after. Look at the data they need to cover about the risk, anything that they have. And then when they have the conversation, try to give them feedback on how the conversation went and what they should have covered better or not.

Ray Arell: 32:11

Oh well, interesting. As long as it doesn't replace agile coaches, I'm on board with it.

Caller 3: 32:17

It is definitely one of my mission is not to do that, but in instead to help them cover. Because I don't believe an agile coach could be at every stand-up, at every planning, every meeting that the team is having. And they could actually coach us to coach them and they could be part of the conversation.

Ray Arell: 32:32

Thank you for that. April, congratulations on your keynote.

April Mills: 32:38

Thank you. It was a great time at the software quality conference in Portland last week.

Ray Arell: 32:44

What do you have on this subject?

April Mills: 32:47

I've been focusing a lot lately on the environment the teams are in and the things that the teams are running into outside of the development processes. One of the things that often wears out teams, it's the lack of the tools or resources or information they have. The reason they struggle without standard tools is because of the larger organizational bureaucracy. I've been focusing on how to help bureaucracy hack, as I call it, to help get the teams what they needed to be effective. I think one of the cruelest things I've seen over the decade I've been in this agile space is the mounting expectations on teams and the decline in training, the decline in training investment, the decline in infrastructure investment, with those mounting expectations. I'm trying to focus a lot on how to help burnout by how to help teams understand how they can hack the bureaucracy to get the training, the infrastructure they need, how to help leaders understand that just asking the teams to go faster and hoping that AI will somehow fix the things they've been avoiding all these years is not the path to sustainable, high-quality products and services.

Ray Arell: 34:12

Give me some examples of the unhealthiness of the bureaucracies that need to be hacked.

April Mills: 34:18

I think there's a great example of many teams in an infrastructure which is not modern. Let's say the contrast point is what developers at Amazon can do in terms of A-B testing or checking in their code. You'll find teams contrasted against, say, an Amazon delivery schedule, but they're operating without that infrastructure. When they bring that up, the conversation is usually we have to wait till the next budget cycle, or we have to wait until the next CIO onboards, or we have to give it another quarter. Teams are often left to go back to their work and wait. Bureaucracy hacking might be to say, okay, at the pace we're currently going, we will catch up to the current state of the industry in 50 years. Are we comfortable with that? If not, what can we do to carve out an investment here out of budget cycle? Or an allowance for this team to either use a new tool that actually works versus getting it bedded for the enterprise or other small carve-outs that might turn into larger system-wide changes, but small investments are small carve-outs so the teams can win versus being set up to lose slowly, which leads to burnout.

Ray Arell: 35:45

Bureaucracies fight back, right? If you push them, they push you back. I'm curious what the main in-road would be for doing some of that work. Beyond budgeting has been in existence for decades, but it doesn't get into the system, at least US businesses.

April Mills: 36:02

Yes. Rather than pushing against the bureaucracy because you will lose, what I like to do is make stone soup. Do you bring what you've got to the table and ask a person in that bureaucracy, hey, I'm looking for a small partnership with you. If I bring my team willing to try new things, can you bring a leftover portion of your development budget to give us some training? I'm not asking for a whole new program to level up all developers, but what could I do to partner with you so we could get maybe these five into this class or get access to this content? Or can we be the test team for this new tool within the enterprise? So you go looking to partner and parlay versus attack and defeat.

Ray Arell: 36:57

Okay.

April Mills: 37:04

And that's what we've seen with most successful agile implementations that did sustain people saying, I'm choosing to be agile. How can I carve out a space for agility even in a rigid bureaucracy? And then how can I parlay that bit of space for more and more so that I can deliver at the pace I want to in a way which makes me proud and energetic?

Caller 4: 37:28

Jeffrey, what do you have on this? Hello. This has been a great conversation so far. I had the question and then it was answered. We've been talking from the perspective of the dev teams. As any good agile person knows, we take the perspective of the team. But when it comes to burnout, my observations more with the actual agile coach, scrum master, the agile project manager, the program manager. And it's it's what we was really just was discussed earlier about how do you infect change. When we go in these retros, you're asking someone else to change, you're adding more to their plate. And then it's trapped almost like two weeks later, why didn't this change? That's not exactly how organizational change happens. I find my fellow coworkers in that space trying to physically push through changes, bugging the senior leadership with all the complaints the team has, and just trying to help the team, but not being strategic at all. In my experience, the best people in Agile know how to influence people. They know how to influence the decision makers. They know how to focus on the one or two things that will have the greatest impact rather than fight 50 battles. You're going to be so worn out and burnt out that you're not going to be able to fight the battles that you can win, that you find value in. So I find sometimes people in the change influence organizational world fight too many battles rather than focus on one or two and seeing that out to completion.

Ray Arell: 39:11

I agree with you. I've always had the philosophy don't take on the biggest, ugliest thing first. Take the thing that you can change today and celebrate that. Thank you for that advice. Your hand went up. What do you have?

Jorg Pietruszka: 39:22

Yeah, just to pick this question up because it's highly interesting. My first advice to any product owner, Scrum Master, coach, don't distance yourself from the team. Be somehow part of it. The closer the better. You need to be vulnerable. If the team sees that you are actually contributing a lot, and I've seen a lot of product owners who are not telling the team what they are doing in parallel to the work for the team. The team thinks they are just doing these few stories for us and they're not doing anything else in the rest of the day. And that is really toxic because there's no appreciation. But if you go in and say, I've actually had a long discussion with management, the outcome is I didn't move a step, I'm really frustrated today. Then people probably come up with other ideas to solve the problem. You're no longer alone. What really helps is if you're working with more than one team, there's normally one team that you get more energy from, and uh most likely they need your support less than the others. So keep the time with them really precious and go there if you have a hard time. Enjoy the wins. Go where the wins are. That really gives you energy to a huge proportion. And the the best thing is just be as human as you can. It invites a lot of help.

Ray Arell: 40:44

I like that. But real quick, we have a few minutes left. Karen posted what what's your own elevator pitch to IT management in order to be successful with business agility. Any of the panelists want to take a stab at that?

April Mills: 41:02

I'll start. I think so often in bureaucracies and corporate IT tends towards bureaucracy, that the prioritization of what matters most gets confused. Managing to their budget, complying with some internal decision about something gets often in the way of delivering greater value to the customer at the lowest possible production cost. And so it's really key to not emphasize a change you want in terms of team preference, but in terms of impact on delivering to the customer in the best way.

Ray Arell: 41:43

I agree with that. I think it's the most important thing. How does this affect the business's bottom line? Sometimes agile teams are talking points and velocities. At the end of the day, it's the business value that we've delivered. Changing the focus of the organization to be more value delivery focused versus a date hitting focus is one of the biggest key factors to it. And the other thing is experimentation. Sometimes we want to try this, and these are the parameters we are looking at. If it's successful, then we are going to scale it. That also helps management sometimes understand that it's not going to be something that we're going to pull up all the floorboards and not get something delivered. We are at the top of the hour, and I'm getting sad now because we have one more recording session left for the year. That's going to be on Friday, November 28th. I hope everyone can make it. Aside from this, I want to let people know that I just accepted a volunteer position as the sponsor chair for Agile Open Northwest. That's going to be happening in 2026. And I'm looking for sponsors. And if you have any interest in getting your company name and backing support for this great event, it's one of the oldest agile events that's out there. Please contact me through New Agility and let's get something going on that because one of the things I found with like these nonprofit organizations since COVID, I'm surprised that the quality conference that April spoke at used to be thousands of people. Now it's hundreds. I want to see these events grow back again, especially when these nonprofit organizations are focused on helping us. Now we need to help them because it is all about community. So with that, I hope you guys all have a tremendous month.