Retrospectives are supposed to help teams improve, but for many teams they slowly become rushed, repetitive, or skipped altogether. In this episode, Brian Milner and Cort Sharp unpack why retrospectives lose their value and what Scrum Masters and leaders can do to make them useful again.

Overview

When a team stops engaging in retrospectives, it is usually a symptom of something deeper. Sometimes the format has become stale. Sometimes the team no longer feels safe being honest. And sometimes the biggest issue is that retrospectives create plenty of discussion but very little meaningful change.

In this conversation, Brian and Cort explore the most common reasons retrospectives begin to fail and how teams can rebuild trust in the process. They discuss the importance of psychological safety, why teams should focus on fewer actions instead of trying to fix everything at once, and how Scrum Masters can better tailor retrospectives to the personalities and working styles of their teams. They also share practical ideas for making retrospectives more engaging, more actionable, and more valuable over time.

References and resources mentioned in the show:

Cort Sharp
Amy Edmonson, Psychological Safety
#139: The Retrospective Reset with Cort Sharp
#141: Cooking Up a Killer Retrospective with Brian Milner
The Empirical Retrospective Approach by Mike Cohn
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

• Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
• Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com

This episode’s presenters are:

Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Cort Sharp is the Scrum Master of the producing team and the Agile Mentors Community Manager. In addition to his love for Agile, Cort is also a serious swimmer and has been coaching swimmers for five years.

Auto-generated Transcript:

Brian Milner (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm here as always, Brian Milner, and today I have back with us friend of the show, close friend of the show, Mr. Cort Sharp. Welcome back in, Cort

Cort Sharp (00:13) Hey there, Brian. Close friend. I've been upgraded.

Brian Milner (00:15) close friend of

regular, ⁓ kind of the norm. If I use a Cheers reference, the norm of the podcast, I don't know. ⁓ That's probably way too dated for anyone who is listening to the show anymore. ⁓ But yeah, ⁓ that's a very old 80s reference. ⁓ Yeah. Which is...

Cort Sharp (00:19) Regular.

Techiega.

That's dated for me, Brian.

Brian Milner (00:42) Well, you're quite a bit younger than me. that's not that surprising, actually. ⁓ But we want to have Cort on because we had another one of those questions that have surfaced that have come in from listeners. And ⁓ Cort, why don't you just open us up? Tell us what the question was.

Cort Sharp (00:44) sorry that.

Yeah, absolutely. And I'm going to read it. So I want to make sure that I'm not botching it. Like I feel like I may have done in the past. I don't want to do anyone a disservice here, but they wrote in, Hey, my team has stopped prioritizing retrospectives. They're getting skipped or rushed. Why do you think that's happening? And how can I make them a priority again? And I wish there was a little more context onto what we were diving in here. So we're going to be making some assumptions here, Brian, but

Brian Milner (01:07) Ha ha ha.

That's okay. Yeah. Well, I mean, I feel like you come to the right place. ⁓ A ⁓ lot of listeners know I put together a couple of Retro's courses for Mountain Goats a while back and ⁓ really did some deep dives on retrospective. So you come to the right place. I think I've got some ⁓ advice for you. So teams are getting bored. ⁓ Symptoms like this, I've...

Cort Sharp (01:30) I think we can do it.

Retrospective,

Brian Milner (02:00) Say again, they want to skip the retrospectives. They feel rushed

Cort Sharp (02:00) they're being skipped. The retrospective is being skipped or rushed.

Brian Milner (02:05) sometimes, right? And they usually, this is like a sequence, it builds, right? So it starts from, ⁓ feel a little boring and they're getting stale. And then it's like, well, let's rush through them. Let's try to get over this as fast as possible. And then that turns into, we don't really need to have them every sprint, right? I mean, we can skip this and kind of keep going.

Yeah, ⁓ I feel your pain. I know that that happens and I've had that happen to me, know, early in my career as a Scrum Master. ⁓ So yeah, when I think about this, there's kind of three main things I think about that usually lead you to this place. ⁓ One is just boredom. And I think this is a lot of times our fault is Scrum Masters.

that sometimes you get really, maybe you do a retrospective in a certain format that goes over really well, everyone loves it. And then you punish them by doing that same format for the next year. ⁓ It's boring. I think you have to have variety. I think you have to get people's brains to work in different ways. So.

Yeah, think boredom is one of the things that'll kill your retros. ⁓ I think another thing is ⁓ when the content of it is just not honest. ⁓ It can be that people aren't being honest. It can be that they don't feel like they can be honest. ⁓ So there you get into whole things like the psychological safety of the team. ⁓

especially bad if you have managers that observe quote unquote ⁓ or worse interject and use this as a chance to instruct the team as to what they're doing wrong and here's what I need you to do instead. It's not the time and place for that. ⁓ Not saying that you can't have management of members of the team, but the team needs a safe.

space where they can have honest discussions and say, Hey, that didn't work out so well. What do we want to do about it? So if there's a lack of honesty in the room, that, that will make this feel not very useful. and the last thing I think is, is just the ineffectiveness sometimes of a retro, like there's a feeling of betrayal almost, that, Hey, I invested this time, but I don't see any results.

And you're telling me it's really important Scrum Master that we do this. And you saying it's a core part of our framework, but heck, I've said the same thing the last three retrospectives and nothing's changed about it. It's the same big problem. So yeah, I assume that you know that I'm not going to bring it up anymore. I guess I'm going to try to go find something else. That's a problem that we can address.

Cort Sharp (05:01) Right.

Brian Milner (05:24) And then you get down into things that are just not as impactful or people don't really care as much about, but you may not do anything about those either. And so now it's just a waste of time. ⁓ Yeah, there's, there really is no point, right? I mean, it's not a therapy session. I think that's a really important thing for people to understand, right? I mean, I think there is some benefit. I don't want to belittle that. I think there's a benefit to the shared experience and being able to

Cort Sharp (05:34) So what's the point? Yeah.

it.

Brian Milner (05:53) to sit there with your peers and say, man, it really sucks the way that we have to do this, right? I think that there's benefit to that, but that's not our purpose. Our purpose isn't to get in the room and bitch and moan a little bit. ⁓ Our purpose is to do something about it. And that's the thing that if we miss that step, then I think it quickly becomes everyone's least favorite.

Cort Sharp (06:12) Right.

I agree with that. I think there is a time and space to just get it all out there, right? Just to have a little vent time, that's fine. Use the first part of your retro for that. Get it out there, but then yes, okay, now that we've identified where it sucks in the way that we have to do stuff, what are we gonna do about it now? What can we do about it now? What's one action that we can take away and actually do and make an effort, or at least an honest effort to...

Brian Milner (06:27) Yeah.

Cort Sharp (06:51) make a change, right? So I want to take a couple steps back there, Brian, if that's okay. Sorry. Yeah.

Brian Milner (06:56) Well, before you get off of that,

I want to lean into what you just said, because I think that that's a really important point that I think a lot of teams will miss is that, yes, we identify a problem. And I think the team needs to take ownership of their part of any issue. And what I mean by this is,

I mean, we've all had these things come up in a retro where there's a problem, but it's a problem not with the people in this room. It's a problem with someone outside the room or the organization as a whole, or what they're forcing us to do or the way things are structured, right? And there can be ⁓ an attitude of, well, our action item is to go tell that person and change it. And I'm not saying that's wrong to bring it up to someone else.

but I am saying it's wrong to entirely place it in someone else's hands, right? I think the team needs to take ownership to say, all right, well, what if though we go and tell that person, hey, we need this to be changed and they say, sorry, you got to live with it. ⁓ I think that what I want a team to do at every retrospective is to say for any issue that's a major issue for them, what things can we do about this?

Cort Sharp (08:18) Mm-hmm.

Brian Milner (08:19) It may be someone else's fault or someone else's area or anything else, but how could we lessen the impact of that? How could we make sure that it's less likely that that's gonna be an issue? And there is almost always something in that area to say, yeah, we can take ownership of this portion of it. We can do something about it. And ⁓ it just...

It gets real easy for people to pass that ownership over to someone outside of the team and say, that's not our problem. We'll just tell them and they should fix it. No, own it yourself. What can we do about this issue?

Cort Sharp (08:59) Right. Absolutely. mean, and I don't hear enough conversation around that or even just anyone calling that out. So I'm really glad you did. I'm glad you stopped me, Brian, ⁓ from jumping back a little bit ⁓ because nobody, nobody calls out, hey, you're doing the work, you're living with it. There are absolutely things that are within your control, whether it's, you know, worst case scenario, you just have to have a little attitude change about a little mindset shift, mindset shift about it. That would be

Brian Milner (09:09) Yeah, yeah, yeah.

Cort Sharp (09:30) ⁓ the worst case scenario, OK, this is something we're going to have to live with and deal with. So let's expect it going forward. And at least we've identified it. now we can just, it's part of the process. We're going to have to go through that. It's just one of those things that we have to deal with. Or maybe there's a way that we are approaching this that we can shift, that we can change within our own development process or our own cycle of whatever it is that we're doing.

let's try to rethink that. Let's change something. Let's run an experiment and let's not be afraid to do that. So you called out there three really good things ⁓ right out of the gate here about why retrospectives tend to fail. You said, hey, it just gets bored. And I think you threw out a good ⁓ remedy for that, which is just mix it up a little bit, right? We all know we're all asking effectively the same three questions.

What do we want to start doing? What do we want to stop doing? What should we continue doing? Things like that, right? That's the core of most retrospectives or the core of the retrospective. So change it up a little bit, ask some more questions, dig into things a little bit differently. I think you gave a really good kind of remedy for that. But then the second one you were talking about was psychological safety, where people don't feel safe to actually bring up what's happening, what's going on.

I don't want to glaze over that. So I want to make sure we spend a little time actually helping out anyone who's struggling with retrospectives or going through this. ⁓ So what suggestions, what techniques, what have you done in the past ⁓ to remedy the psychological safety other than just saying, hey, everyone, we're here together, much like Las Vegas. What happens in Vegas stays in Vegas. What happens in our retrospective stays in our retrospective, right?

Let's, yes.

Brian Milner (11:25) Yeah, to an extent, right? mean, the conversations

for sure, outcomes, no, right? Like we want to make sure that we actually have outcomes that do leave this room and actually impact, right? ⁓ So yeah, I get what you're saying there. ⁓ Yeah, I mean, I don't want to go into too deep of a rabbit trail on this. And I probably have talked about these kinds of things in other podcast episodes in the past, but you know, I'll point you to the brilliant work of Dr. Amy Edmondson.

on psychological safety. has several books on this matter that you can search for. ⁓ She's brilliant and pioneer in this area of the, or this topic. ⁓ And yeah, it's, ⁓ think she kind of basically defined psychological safety is that I feel free to speak my mind ⁓ in my team, in my group, ⁓ without fear of retribution.

or belittlement, ⁓ that my opinion is heard, respected. ⁓ It doesn't mean that your idea is always gonna be taken or that that's gonna be the one that we do, but I know that I'm free to speak up and people won't just immediately dismiss me or punish me for the fact that I spoke up. That's a stupid idea. Why would anyone say that?

Right? That's the kind of thing that's really damaging to psychological safety. you know, there's a great, if you're not familiar with this, there's a great study that Google did called Project Aristotle, where they tried to determine what's the most ⁓ important factors to a high performing team. They thought for sure their hypothesis when they started was, it has to be about the skill level of the team members. Right? If I have a team of five people that are all 10 year veterans who have been doing this for a long time versus a team of

recent college grads, the 10 year veterans are always gonna be more likely to be high performing, right? Well, no, that hypothesis was blown out of the water. And the thing they found that was the most important was psychological safety. they basically said, this is not just one of a list of factors. This is the foundational factor, meaning that it doesn't matter what else you have if you don't have this, that you have no shot of being a high performing team.

if you don't have psychological safety on the team. So I talk about it a lot in my classes. I talk about it a lot when I'm on podcasts or in person, because it is that important. is something that as a scrum master, I think should be the top of your radar. ⁓ So what does that mean? Well, how do you feel about it as a scrum master? Check yourself first. Do you feel safe? Do you feel like if you say something, you're going to be belittled or you're going to have retribution?

for speaking up, if you feel that you're not safe, it's pretty likely the team feels that as well. ⁓ If you have that inkling that that's the situation in the team, run a quick little safety poll at the start of your retrospective and say anonymous, have anonymous ways of writing it, but one to five, how safe do you feel today in this room to say what you really feel?

And this is something that I will do periodically when I'm a Scrum Master, not just one time, but I want it as as a stat that I can refer back to and say, we're trending up or we're trending down in safety. ⁓ And if it's trending down, I want to pose it to the team and say, why do you think that is team? What do you think has happened that has affected our, sense of safety in this room? ⁓

Because at the end of the day, if we can't get into this room and be honest with each other, and if I can't say, hey, that's my bad, right? I made that mistake, ⁓ but here's what I learned from it. And I know that I don't do things this way and I'll make sure to do things this other way. No fault, no blame, no pointing fingers and saying you're a bad person, but just what did you learn?

And if that's the attitude that team starts to take about things, because we're all going to make mistakes. No team is perfect. No person on a team is perfect. Everyone makes mistakes. And the more that can be normalized. ⁓ So if you're a leader, if you're the scrum master, if you're a lead developer on the team or something like that, highly encourage you to set the example. ⁓ Find things you can say.

that you can say, hey, you know what, I messed up on this thing, but here's what I learned from it. And, you know, that's what, that's what I'm going to apply moving forward. The more you can set that expectation. Now you're, you're, you're helping the rest of the team go, ⁓ well, that's normal. it's okay for me to speak up and ask for help. It's okay for me to say I did something wrong because I'm not going to get knocked off of my performance review because my manager's not in this room. It's just my peers.

So we can feel safe to have that conversation, but that's where it starts to break is if, that's a great example, right? If I say something here, am I gonna hear that parroted back to me on my performance review? Well, then I'm not saying it, right?

Cort Sharp (16:43) Yeah.

Yeah, if anything can be weaponized against my career, my time at this company, my role, anything that puts my job in jeopardy, if that's gonna be the outcome of this time together, this meeting, sorry, ⁓ I'm gonna be pretty tight-lipped here. I'm not gonna be speaking up a lot. ⁓ But I do love that you called out, hey, leaders in the room, I was thinking just...

Brian Milner (17:17) Yeah.

Cort Sharp (17:28) Scrum Masters, because that's where my brain instantly goes, is Scrum Master. Model it, model that vulnerability, and also even kind of check the way that you respond to others when they're being vulnerable. But I love that you called out tech leads, lead developers, anyone in the room, anyone in this meeting here who has maybe a little bit more of that status or maybe that leadership type of ⁓ viewpoint, or I guess is in that leadership position. ⁓

It's more than just calling out, hey, here's where I messed up this last sprint. I'm owning it. I recognize that. Here's what I learned from it. So I'm going to take that into future sprints and just keep that in mind. I think it's also, how do you respond as a leader when maybe that junior developer goes, ⁓ gosh, I just didn't manage my time well this sprint? Do you say, well, lay the gauntlet down and

Brian Milner (18:25) Yeah.

Cort Sharp (18:27) Go to town like, gosh, what are you doing? Are you just sitting on Instagram all day or what's your deal, right? Or is it, okay, well, how do you feel like you could move forward, right? We wanna try to manage our time a little better. What can we do this upcoming sprint? Is there anything you need from me as someone who's maybe in that leadership role to help you manage your time a little bit better? Or here are some things that, you know, I struggled with it as well. So here are some things that I figured out along the way. Maybe one of these will work for you.

Brian Milner (18:32) Right.

Cort Sharp (18:56) something like that, right? Be receptive and understand the way you respond to people definitely is, I would say, one of the biggest indicators of psychological safety or builders of psychological safety.

Brian Milner (18:57) Yeah, no, I yeah.

Yeah, that's such an excellent point. And I agree completely. mean, if I go to my manager in a minute of fault and their response is more finger wagging at me, right? And saying, well, don't do that. That's unacceptable. Our standard is higher. You need to make sure you do this. Those things may be true. Hey, we have a higher standard for quality. We have a higher standard for what we expect from our employees. All those things can be true.

taking the risk of saying to you, hey, I'm struggling with this, or I had a problem with this, or this didn't work out the way that I thought it would. ⁓ I think you should start from a position of empathy always to say, wow, that's really tough. And yeah, I understand I've been in situations like that as well, and that's been a struggle for me, or I've had struggles similar in this other area.

Cort Sharp (20:08) Mm-hmm.

Brian Milner (20:09) You don't have to have the same problem, but you can say, yeah, I have a similar thing with this. And that's a problem for me. And I've had to find ways around it. now you've earned the credibility to then say, but let me help you with this. Let's tackle it together. Let's think through together. Let's think about this last sprint. If that's what happened in this last sprint, if we had a time machine and it could go back, what could we have done differently?

Cort Sharp (20:26) Yeah.

Brian Milner (20:36) What could I have done differently to support you or to help you in that? Now you've co-opted them and you've acknowledged them. You've said, hey, that you're not abnormal for this. Every one of us has struggles. I empathize with the fact that you're a human and I sympathize with the struggle you're going through. I have similar ones. Let's be proactive about this. And not only that, but I'm on your team.

Right? It's not me versus you of you're the problem. Let me fix you. It's let's team up, right? Let's both of us together, find the right solution to this and then move forward.

Cort Sharp (21:07) Yes.

Yes.

Yes, I love starting my retrospectives out. I like starting my reviews out this way too, but I love starting my retrospectives out with saying, hey, thank you everyone for taking the time to do this. This is really important. I just want to call out a little reminder here. We're all on the same team. We're all trying to accomplish great things together. So let's just keep that in mind when we're going through and figuring out how to improve together as a team. And just that same team mentality I've seen.

crazy shift right out of the gate as well to just be in like, yeah, that's right, I guess we are working together. It's not just me versus you or me trying to write more code than you or build stuff aside like just coincidentally together. We are on the same team, we do have the same goals. Let's work together to achieve and accomplish those goals.

Brian Milner (22:13) Yeah, or kind of put a different way from what you just said. I always like Norm Kerff's prime directive for retrospectives. It's something that I will often read out at the start of retrospective. Regardless of what we discover, we understand and truly believe that everyone did the best job they could given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

And if we set that as the paradigm, then now it's safe because it's not, well, that's all you. It's your problem. ⁓ It's no, you did the best you could given all these other things, because that's just where you were at the moment. But now let's talk about how we don't get to that moment again. And we actually can prevent that from happening another time. Yeah.

Cort Sharp (23:07) Yeah, I love

the call out there too of the three, three or four things are effectively just different levers that you can pull to help your team not learn from these mistakes, make them less likely to happen again. ⁓ Was it a knowledge issue? Was it a skill issue? Was it a resource issue? Which of these levers do we need to pull to ensure that you don't find yourself in this situation again? ⁓

And so even calling it out there beyond the, just the, Hey, we're all on the same team. Right. I love that. That's awesome. Yeah. That's a great call out.

Brian Milner (23:46) There are some things I think like if you find yourself in this situation, right, where things are not going well and you feel your retrospectives are going in the wrong direction. I do have a couple of practical things that I always like to give kind of some practical, know, here's actual things you can, steps you can take to actually start to right the ship a little bit. ⁓ One of the things I'd say is shrink the target. ⁓ You wanna...

Sometimes you're trying to do too much and you leave a retrospective with five things and don't make progress on any of them because there's five of them. Well, it's the same principle that we have inside of the sprint, which is limit your whip, limit your work in process. So, you know, I know Jeff Sutherland, I've heard him talk about this where he says that the Scrum Guide says one to three things, but I say find the one thing.

Kind of back to movie City Slickers, you what's the one thing? ⁓ You know, ⁓ if you can find the one biggest thing, and usually there's a pretty obvious biggest thing that people can all point to to say, yeah, if we could wave a magic wand and change one thing, it's this. Well, whatever that is, make progress on it. You don't have to solve it in the next rent, but lessen it.

take steps towards resolving it. So shrink your target. Sometimes you're trying to do too much out of a retrospective. Hone it in, right? Try to get down into fewer things. You agree with that?

Cort Sharp (25:17) Right.

I totally do. And it's not just because like, you know, the likelihood of one thing being changed is greater than 10 things being changed. ⁓ but you're also, I mean, it is, but you're through that, you're increasing the probability of it actually being changed because guess what? Now, instead of breaking your focus off into 10 different things, you're focused in on one thing. And when three, four, five, six, seven, eight, nine people tend to

focus on one thing, it's probably going to get done. Something's going to happen with it. It's going to change. And not even just identifying it, but also the act of making it the outcome, like you were saying earlier, the outcome is going to happen because we are all now making this, number one, the only thing that we're focusing on here. We're not breaking our resources up, splitting them up, so to speak there. So 100 % agree with that. One that I would throw out there.

Brian Milner (26:20) Yeah. Yeah.

Cort Sharp (26:25) if I may, ⁓ is think about who you're actually inviting to this meeting. If you're inviting any, I know I joked about it earlier, like with the Vegas thing, what happens in Vegas stays in Vegas. What happens in the retrospective stays in the retrospective. ⁓ I joked about that, but like when you're planning your Vegas trip, when you're planning your retrospective, you want to be pretty aware of who's going to be there and what.

Brian Milner (26:26) Yeah, please.

Yeah.

Cort Sharp (26:53) what role they play, where they stand within your company. So if you have maybe an outside manager that your team reports to, your team's going to be really quiet that retrospective. ⁓ But if you don't have an outside manager ⁓ out there and it's just your team, you're probably going to have a substantially more productive retrospective. So be intentional with who you're inviting to this and who's going to be there. ⁓ I think

I mean, I have an example to pull out of my hat. ⁓ I know you do, Brian, but the person that I see oftentimes get forgotten about who they report to directly is the product owner. And through that, you know, maybe we'll think, ⁓ let's bring in, you know, our product person, our head of product should be in here for whatever reason. Right. And there may be a very good reason to have them in there, but if you invite them, understand and recognize your product owner is probably going to be pretty quiet.

Even if the rest of your team doesn't directly report to that person, your product owner does. So we want to make sure that we're being aware of that and understand that. And truthfully, I would not invite anyone outside of the team to this because it should just be team only or focusing on us, focusing on what we can do, how we worked, what we got done, why, and what we can do to change it and make it better.

Brian Milner (28:17) Yeah, completely agree. The other thing I'd say is if you invite a manager of any person on the team to that retrospective, what do you think the other managers of people on that team are going to say? Right? Well, you let that manager in, why won't you let me in? ⁓ I should be in that room as well. I want to know what my people are saying. So you set a bad precedent then to say, yeah, it's fine to have people from outside the team in this. ⁓

I'll expand your analogy a little bit about the Vegas thing, right? About what happens in Vegas, stays in Vegas, to an extent, right? Because I think that the consequences, right, ⁓ live past the visit to Vegas, ⁓ right? I mean, if I go to Vegas and in a drunken fit get married to someone, I'm married when I leave Vegas, right? ⁓ Or if I have too much to drink, I have a hangover the next day.

Cort Sharp (28:48) You

They sure do, yep.

Right, right.

Brian Milner (29:13) like there are things that can happen that you have consequences of. And I think that same thing kind of happens from the retro. I, I don't want to share, well, this person said that, or that person said this, but I have as a scrum master send out a thing afterwards that said the team made these decisions. The team, ⁓ needs help with this. The team wants to address this because.

then I have no idea who said it, but it's the consequence, it's the conclusion that was reached, not how they made the sausage, but here's the sausage at the end of the day. And I think that is important to take out of a retro sometimes because a lot of times the team needs help from people outside the team. Yeah.

Cort Sharp (29:57) Yeah, yeah, absolutely.

Right. And I know you said it's not a therapy session, but I guess maybe a therapy session might be a better ⁓ analogy. That is true. That is true. But I think maybe therapy session might be a better analogy than Vegas. Because like, and I don't have kids, but I've heard, you know, ⁓ when kids go see a therapist or something, parent isn't allowed to know what was specifically talked

Brian Milner (30:05) Well, it's not just a therapy session, I guess I would say. Yeah. Yeah.

Cort Sharp (30:26) But a good therapist will say, know, just standard teenage stuff, standard kid stuff, nothing to be worried about, you're good. But if something big is happening and there's something that the parent should probably be worried about, a good therapist would probably call that out a little bit and be like, we should work on this thing here and let's figure out a solution towards this, whatever it may be, without specifically saying, here's word for word what was said there. Right?

Brian Milner (30:53) Yeah,

I do wanna throw another one out there that I think is, it's near and dear to my heart and it's one that I talk about a lot. ⁓ If you take the courses, you'll definitely hear me talk about this, but that's match the whatever format you're using to your team. If I have a team of introverts and the way I'm running my retro is one in which it really is more,

Cort Sharp (31:10) Mm-hmm.

Brian Milner (31:21) tuned toward extroverts or people who are more verbal processors, I could be setting myself up for failure because it's just uncomfortable for the people who are actually on your team. So yeah, this does mean that the starting point is knowing your team. And that's part of that individuals and interactions thing. Who are the people on your team? What makes them tick? What's their personality type? How do they prefer to work?

Cort Sharp (31:35) Right.

Right.

Brian Milner (31:50) How do they prefer to have discussions? Maybe your team needs some quiet writing time in a retro, where everyone takes a minute or two to think to themselves and write some stuff down. ⁓ Maybe they need to have a system whereby they can submit topics throughout the sprint. They're not forced just in that first few minutes of a sprint to, my gosh, let me think back to what happened. But hey, as it comes up along the way in the sprint, I'm gonna submit this and that way I'll remember it when we get to the retrospective.

Cort Sharp (32:08) Mm-hmm.

Brian Milner (32:20) ⁓ Match it to the actual kinds of people that you have on your team. And I think that's a big key to unlocking successful retro as well.

Cort Sharp (32:30) Absolutely, Yeah, ⁓ I can't tell you how many times I've been in a retro and the first 10 minutes are just silent. Just pure silent. Well, I like silence, but.

Brian Milner (32:35) Yeah.

Painful, right? Well, no, it is painful.

No, but when you throw out a question and even the kinds of questions you ask, right? That can be a ⁓ key to it as well, but you throw out a question and then no one talks and it sort of becomes this stubborn moment of who's gonna flinch first and.

Cort Sharp (32:53) Mm-hmm.

Right.

Brian Milner (33:05) Am

I going to wait forever or am I going to move on? I think you have to have a little bit of an internal timer as a scrum master to say, all right, well, maybe they're just not ready to engage in this way or they're not ready to engage in this topic. So let's move on. Let's move on to something else. ⁓ And kind of last thing I'd say is ⁓ don't be afraid to retrospect on your retro. ⁓ Get feedback from.

Cort Sharp (33:18) Yeah. Yeah. Yep.

Absolutely.

Brian Milner (33:33) your team on it, saying, what did you think of the format we used? Do you like how it's going? Do you not like how it's going? What would you change if you could change one thing about it? Ask them questions. It doesn't have to be in the retro, it can be, but you can send them that afterwards, or maybe have a permanent place where they can give feedback and just say, hey, just remember we have our whatever box that's over here. If, you know, I'm always interested in what you think about.

the format of this, if you like the way these work or if you don't like what you don't like about them. ⁓ I think it's really important because that again, it's practicing what you preach a little bit because you're saying, I wanna know feedback early and often so that I can make changes. But if you never ask your team for feedback, then they're gonna say, well, I'm gonna do as you do, not as you say.

Cort Sharp (34:21) Right, right. And at the end of the day, the retro is for the team. So if we're not serving our team well, again, what's the point? Why are we doing this? We should be here for the team. This is the team's meeting. Let's make it happen. Let's bring the true value and the true benefit for the team here. Absolutely.

Brian Milner (34:43) Yeah, absolutely

agree. Well, Cort, I really appreciate you ⁓ surfacing this and bringing the question and ⁓ participating in the discussion. It's always good to get your insights and thoughts on these things as well.

Cort Sharp (34:57) Absolutely, Brian. Thanks for having me on again. And ⁓ let's go retrospective about this. Let's do a little retro on how this went.

Brian Milner (35:02) Yeah, yeah, let's retrospect on this episode.