Key takeaways on inspecting and adapting

Is your team dreading retrospectives, or skipping them altogether? Mike Cohn joins Brian Milner to unpack what’s really going wrong (and how to fix it) so retros don’t just take up time… they actually make your team better.

Overview

In this candid conversation, Brian Milner welcomes back Mountain Goat Software co-founder Mike Cohn to talk about one of the most misunderstood parts of Scrum: the sprint retrospective.

Too many teams treat retros as boring, repetitive, or even pointless—and end up skipping them entirely. But retros are where the magic of continuous improvement actually happens… when they’re done right. Brian and Mike dig into the common reasons teams dread retros, how to spot the signs a retro isn’t working, and the practical ways to bring them back to life.

They also share their own lessons learned (including how Mike once argued retros shouldn’t be part of Scrum!) and walk through the real reason retros matter: giving teams space to inspect, adapt, and improve together.

References and resources mentioned in the show:

Mike Cohn
Your Fast Tract to a Fresher Retrospective Webinar
#141: Cooking Up a Killer Retrospective with Brian Milner
Overcoming Four Common Problems with Retrospectives by Mike Cohn
Retrospectives Broken? Fix Them for Good 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.

Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection.

Auto-generated Transcript:

Brian Milner (00:00)
Hey everyone, welcome back to the Agile Mentors Podcast. I'm here with you always, Brian Milner. But before we dive in today, I wanted to let you know that we're gonna have a free webinar that I'm gonna be running here for you. It's gonna be on September 24th at 9 a.m. Pacific. So do your adjustments wherever you are. It's called Your Fast Track to a Fresher Retrospective. It's just gonna be a little short 20 to 25 minute presentation. And then there's gonna be some open question and answer that we're gonna have after that. it's perfect if your team's retros are feeling a little stale, or if you're looking for practical ways to shake things up. We're gonna put a link to it our show notes, but wanted to make sure right up top that you guys knew about that. It's completely free, September 24th, 9 a.m. Pacific. We're gonna have that webinar on retrospectives. And joining me here today, also is the one and only Mike Cohn. Welcome in, Mike.

Mike (00:55)
Hey, Brian's good to be back.

Brian Milner (00:57)
Glad you're here. We wanted to have a conversation because I think we can probably all agree that not all retrospectives, we might even say are worth having. When you look back on them and you look back on the content of it, maybe we'd say it wasn't worth having. If your team isn't getting value from the meeting and skipping it might feel rational. But skipping the point of retrospective, continuous improvement, isn't something high performing teams really can afford. It's a main part of what we do. So we're going to talk a little bit more. We're going explore that about why some teams end up dropping retros. Because I hear that all the time. People ask that in classes. Is it OK to? Should we? Should we do it less often? So we're going to talk about why some teams might drop retros. What that really says about the team health itself. and how you can bring retros back in a way that reconnects to their purpose so that it's not just a ritual. And with that then, I'm going to pull Mike back in. So again, Mike, thanks for being here. I really appreciate you giving us your time for the episode today.

Mike (02:05)
Yeah, I appreciate it. I'm glad to be here. Before you jump in, I do want to point out that we've been on for about 15 minutes before we got ready to record. Just kind of haven't talked to each other for a bit. And I just want to point out for everybody listening that Brian did a mini retro on his podcast before we got started, talked about how we can change some editing on that, maybe get episodes out more quickly and also to get them out in video. So I guess I'm saying that to. make us commit to the video part of it, but to also point out that Brian did a retro on his podcast, right before we got started. So Brian is walking the walk.

Brian Milner (02:40)
Yeah, mean, it's always good to inspect and adapt, right? I mean, if you don't do that, then you're not questioning why things are happening the way they are and things get stale and eventually fall off. So yeah, I'm a big proponent in that, stopping down to inspect and adapt for sure.

Mike (02:56)
Brian, one of the things that does come up with retros is teams feel like skipping them when they're not getting anything out of it. Do you think it's okay to skip a retrospective?

Brian Milner (03:08)
Well, I'm probably not going to shock anyone here in my answer, but I'm not going to be someone who would support that. I'm not a proponent of that. I think that's a mistake. I try to be very careful about saying, hey, this is always this way. I do think that that's the Agile Manifesto talks about periodically, routinely. kind of having this kind of inspecting and adapting moments where we retrospect on how things went. And Scrum has this meeting built into it to happen every single sprint. The thing that kind of jumps out at me when I first thought about this is we kind of take this attitude sometimes that, this thing isn't working great. And so maybe we should skip it. Or least that's, I guess, the mentality behind skipping the retrospective.

Mike (03:55)
When you say skip it, I think about the guy skipping leg day, right?

Brian Milner (03:59)
Right, right. Well, that's exactly where I was going to go. It's like, where else in life do we say, that's not working, so I just won't do it. You know, like, I'm having a hard time getting my passport renewed, so I guess I just won't get my passport. You know, like we don't do that with other things. There are things that are hard. There are things that take more effort. And it doesn't mean that if it's harder or it's not working right now that we just don't do it. We got to figure out why and... you know, fix it and, you know, get better at it.

Mike (04:27)
Yeah, there's a I'm a big fan of the Lego Batman movie. And in there, there's a song where this says Batman never skips leg day. Right. And, you know, skip something if it's truly useless, but don't skip something because it's hard. Right. I would agree that. Brian, I'm curious what you think about this situation. What suppose you have a team doing one week, one week sprints and one week is.

Brian Milner (04:31)
Ha ha. Right.

Mike (04:51)
Awesome. It's the right length for the team. It's a right length for the business. Everybody agrees. It rocks. One week sprints rock. But the team hates retrospectives. Like literally, they'd rather go to the dentist and have a root canal instead of having a retro. And at some point, somebody on the team goes, huh, if we switched to four week sprints, we wouldn't have to do these darn retros as often. That's a tough one. What do you think about that?

Brian Milner (05:18)
Well, there's some truth in that. You know, they're not wrong, as they say. You know, if you do longer sprints, then you have meetings less often and included in that is a retrospective. So yeah, that's not wrong. You would do it less often. But on the other hand, your retro is gonna be a lot longer. If you're retrospecting over the past month versus over the past week,

Mike (05:28)
Mm-hmm.

Brian Milner (05:42)
A weekly retrospective is going to be very short. A monthly retrospective is going to be very long and no one likes longer meetings. So that's the trade-off is, yeah, we can do it less often, but do you really want to have those meetings double and triple and link?

Mike (05:46)
Okay. in double and triple perhaps, but I I gave it the example where it'd be one fourth as often. So it'd have to be four times as long. And I doubt that it would truly be four times as long. See, this is a case where we probably disagree on this a little bit, because I have had teams that have made that argument. Hey, if we went to longer sprints, we wouldn't have to do this as often. And I don't want them to go to longer sprints. I doubt you do either. But what I've told them is like, look, the rule is do a retrospective often at least once a month.

Brian Milner (06:20)
Yeah.

Mike (06:27)
If you're going to do it every four weeks and you want to do two weeks sprints, for example, do your two weeks sprints. But I'd rather have you do the retro every other sprint, but take it seriously. Because what they do is they just go through the motions. They're going to go through the motions for 10 minutes. They're going to go through the motions in 10 minutes in a four week sprint too. Just show up. Can we get better or anything? No, we're good. Done.

Brian Milner (06:37)
Right.

Mike (06:49)
I'll let them trade off if they want. If they will make the commitment to me, they'll take it seriously and really come with ideas and try to improve.

Brian Milner (06:56)
Yeah, well, I think this is a prime example as well why inspecting and adapting is so important because, all right, what's our issue? No one likes going to the retrospectives. We're jumping from that to, then let's just not do them as often. When what you need to do is stop and inspect and say, why don't any of us like coming to the retrospectives? What's the problem about our retrospectives? And that's really the core issue there is to say, Hey, are we doing the same thing every single retrospective? Are we saying, Hey, what went well? What didn't go well? Right. I mean, are we being asked the same questions every time? we never varying it up? Are we always doing kind of navel gazing kind of thing? Or sometimes are we doing team building stuff? Sometimes are we even just celebrating some things that happen from time to time? The root cause is the important part because otherwise, you know, it's like cutting off your leg because you you got to a little infection or something in your big toe. That's not the cure for it. The cure is find out what the disease is and treat the disease.

Mike (07:57)
'm back to it's leg day at the gym and I'm going to cut my legs off because I hate leg day that much. Right. It's like, no, no more leg day. Right. So you'd have to really hate leg day for that, for that to be the solution. What, what are some of the signs that you've seen that indicate a retro is not working and that the team needs to kind of rethink things? What are some of those signs?

Brian Milner (08:00)
All right. No more leg day. Thanks. Yeah, no, that's really good. Common things, people checking out, people just giving surface level answers. Here's a big one. There's obvious things that didn't go well in your sprint, and no one brings them up. You just kind of get there and it's like, for example, hey, we didn't finish everything in this sprint.

Mike (08:39)
Yeah.

Brian Milner (08:44)
But then we get into our retrospective and no one puts on the board. What's something that didn't go well this front? We didn't complete all our work, right? Sometimes people get to that point where they just feel like, it's so obvious. Why would I need to bring it up? Well, if it's so obvious, then we need to address it, right? We need to do something about it. So yeah, I think that's part of it is that sometimes people will just check out and you might be able to tell it that way. You might be a tell it because they're not really contributing things. People try to rush through it. You know, it's like you only get a team where only a couple of things are in each one. And it's almost like it feels like the team's colluding to sort of, well, you put these two things up there and that'll be enough. And then they'll leave us alone. We can go on. You know, so, you know, they're, they may not literally be doing that, but it's almost, you get that feel that it's almost like there's an implied, I guess we have to have this number of things up there. Yeah. I mean, it's just,

Mike (09:13)
Good.

Brian Milner (09:37)
In general, there's no investment. When people show up, they're not really engaging. They're marking the time. And when that's going on, yeah, that's usually a precursor to someone eventually saying, hey, let's just not do this then.

Mike (09:54)
One of the problems that I'd add or one of the symptoms that I'd add would be when the team is talking about things again and again, the same item again and again, right? And it's not gonna get fixed. You we might be in there talking about, you know, I hate the new building, right? The new building's farther from my home. This is a real team I worked with where they all moved. They were downtown and the company moved everybody out. near the airport in their city. And it wasn't better for anybody. I mean, it was probably better for the CFO writing the check for the landlord or to the landlord. But it was a bigger commute for everybody. The facility wasn't as nice. It wasn't your restaurants. I mean, it just kind of sucked. And they would grumble about it every week. It's like, we can't fix this, right? We can't fix this. Right. You know, and so sometimes talking about things that are out of a team's hands are are they're just frustrating. Right.

Brian Milner (10:34)
Ha ha ha ha. Yeah.

Mike (10:42)
It's like mention it one time. I hate the new building. It sucks. There's no good restaurants here. And you know, you're probably not going to fix that problem. Maybe you can agree that you're going to, know, on, you know, the last Friday of a sprint, everybody on the team is driving back downtown and we're all going to lunch together, right? Fix it that way a little bit. But, you know, don't grumble about things that are out of your hand, right? You know, I'm worried about climate change. It's like, yeah, but I don't hear about that. It seems retrospective, right?

Brian Milner (11:02)
Yeah. Yeah, that's completely outside our circle to do anything about, right? So yeah, I agree that there is that scope sometimes that happens. But on the other side of it too, I would say one of the other killers that can contribute to people kind of checking out is not feeling like it's making any difference. know, if we bring something up, let's say it's not completely out of our hands, but it is something that's a real issue. And we bring it up.

Mike (11:09)
You Yeah, we need to test earlier. We need to test earlier in the sprints, right?

Brian Milner (11:33)
Right. We need to test earlier. We think we'd be better if we had some test automation here and we want to put test automation software in place. Yeah, well, I asked the manager and he said no. So I guess we're done. Right. I mean, it's frustrating. We say these things. I think it's important that the team see progress. It doesn't mean that you have to solve it 100%. In that case, hey, the manager said no. OK.

Mike (11:46)
No. Frustrating.

Brian Milner (12:01)
Well then how can we raise the transparency of the issue it's causing for us not to have it? We can make it apparent that this is what's going on. I remember there was a team I had one time that they started to bring up the issue that they didn't have a coffee machine near them. Now this was an absurd case because I don't know any other place that would do this. for whatever reason, this place I was at, they had two floors. the programmers were on a floor without the coffee machine. The coffee machine was down the stairs on the lower floor. And so they were complaining because they were saying, hey, we have to walk up and down the stairs all these times a day. mean, there's a reason that we name our languages Java. They're coffee drinkers. So they brought it up, and we talked about it. And we said, oh, guess they kind of set up the office the way they set up the office. immediately put me into action to think, you know what, this may not be about coding or may not be about something that's kind of a day by day thing that's doing our work, but it is an important thing that they have access to this. And I was able to then kind of start to compile some data and show, look, they're spending this much time walking up and down the stairs and that's happening to each developer and you're losing this much time of their day walking up and down stairs. You think it's too much expense to put in this coffee machine, but you're paying this every week by not having a coffee machine up here. And we were able to get them to actually make that change. That was huge for those developers. They thought that was the best thing in the world that now the coffee machine was relatively easy to get to, and they could get refills anytime they wanted. So I think it's important that they see that progress happens. Right.

Mike (13:46)
Yeah, it showed that they were cared for, right? That somebody heard, right? Why do you think this is so prevalent? Because, mean, you we hear this all the time, right? You know, oh, our retro soccer. Oh, man, I'm going go to retro today. Why is this such a common thing? Why do so many teams feel like they don't need to do retrospectives?

Brian Milner (13:50)
Exactly. I'm not really sure why they jumped to that as the solution, because as I said, we don't really do that anywhere else in life. Other than to just think, you know, no one likes meetings. And when we come up against a meeting that we don't feel is going well, then that's sort of, that is sort of our instinct is, well, then let's just not have this meeting. But if they, maybe that gets back to purpose even a little bit then. If I don't understand the purpose of it, then now it's not just that it's not going well, it feels pointless. And why do I want to go through something that's painful to go through and I don't understand why you want me to go through it? You know, that's a double whammy that now the easy solution is, well, let's just not do it then.

Mike (14:34)
Right. think a lot of teams feel like, you they adopted just the bare beginnings of Agile or Scrum and they start to, they notice they're better, right? We've improved. And they, maybe they are 10, 20, 50 % better than they were before and got there pretty easily. And it's like, well, we don't need to keep improving. We just improved, right? ⁓ And you know, it's the Dunning-Kruger effect, right? This is like so much more you could get better at, but you you see that you got better. Why keep going, right?

Brian Milner (15:03)
Yeah. Yeah.

Mike (15:14)
So I think that's a factor. I'm curious what you would say to me 20 something years ago, because Esther Derby is the reason why retros got added as a standard thing in Scrum. They were not part of Scrum at the beginning. And she started lobbying that they should be a standard part of Scrum. And I disagreed. I said retros should not be part of Scrum. And I'm very big on admitting my mistakes. So I argued no. So I'm curious what you would say to me, because here's my argument. I don't want to wait until the end of a sprint to tell my team an opportunity to get better. If I notice an opportunity to get better, I need to bring that up in the next morning's Daily Scrumber. If it's a huge opportunity to go grab everybody that afternoon and mention it. How would you argue with me about that? Because in some ways, that is a better way to get better, right? Just bring it up in the moment. Why wait till the end of a sprint?

Brian Milner (16:03)
Well, I think what I'd say is, then if you recognize something in the moment, then absolutely bring it up in the moment. There's no need for you to wait till the end of the sprint. I don't think that you store it up or that you have to wait. I would say something similar about a sprint review. Why do I have to wait till the end of the sprint before I get feedback from a customer about something I just did? You don't, right? ⁓ There's no reason why you can't on day two or three

Mike (16:25)
Okay.

Brian Milner (16:28)
show it to somebody who's going to be using it and say, what do you think about this? In fact, it's better if you do that. What it becomes though is that, speaking now about the review, the review is the time everyone can count on every sprint to show up and examine the increment and give feedback. The retrospective is very similar. We can give feedback throughout the sprint. We can improve throughout the sprint.

Mike (16:52)
Right.

Brian Milner (16:52)
but it's the designated cadence. It's the time that we can count on every sprint that we're gonna set aside, right? We're gonna set that aside to do this because we think it's that important.

Mike (17:04)
I think it's that dedication, that dedicated time that is part of what persuaded me because suppose I come, I do come up with a brilliant insight. It's my idea. Of course it's a brilliant idea. I come up with this brilliant idea about how our team can get better, Brian. And I want to talk to about it right now. And I, I, I Slack you and I said, let's talk about this. No, your head's down in the middle of something else. You don't want to talk about it right now. It's not the right time, right? And if we set aside that time at the end of the sprint as a dedicated time, it's more likely to happen and it's everybody knows to have their brain ready for that conversation, right? It worked better, right?

Brian Milner (17:42)
Right, and the fact is, lots of people are heads down throughout the sprint, right? There's lots of time in the sprint where you're just so involved and busy and your brain's working on what we're building that unless you get told, unless you get that thing on the schedule that says, wait, I gotta stop, okay, time to retrospect, right? Unless you get that reminder that, hey, this is important too, right? We gotta do this thing. You could very easily just end up going for a long period of time with never doing it. And that's the danger. It falls off your radar and pretty soon you're never having any kind of time to retrospect. So it's not that there's something magic about, we've got this meeting that's called this. It's really what happens in it. And if that's happening on an ongoing basis, well, maybe you have another process that's not Scrum that would be as effective, but Scrum dedicates that time so that you make sure you don't miss it.

Mike (18:35)
Yeah, I just don't think it happens. If we told everybody, as soon as you come up with an opportunity to improve, interrupt your team and tell them about it right then. It's not going to happen because if I have a brilliant idea, OK, I might go talk to people. How many brilliant ways to improve a team do you come up with, right? Most of them are incremental, right? Hey, here's a way that we do a little bit better. And I'm going to go, well, this will all be a little bit better, but everybody looks busy. I'm not going to go bother them right now, right? And I noticed that I would do this. I would have an idea. I wouldn't bring it up. And then tomorrow I'd forget about it. What was that brilliant idea I had yesterday? And so I became a very strong advocate of the retro, despite at the beginning, and being very honest with that, not thinking that it should be part of Scrum. It should be something that we just do on a more ad hoc basis.

Brian Milner (19:21)
Yeah, that's very interesting. And I'm glad you shared that because it's interesting about the evolution of things and how things have changed over time as far as that's concerned. But you know, the other kind of aspect there it also is, you know, if my if I'm heads down and I'm going through, there are some things I'm going to notice just in the course of doing my work, because, hey, I would have been better if I could have done it this way versus that way. But I also feel like I'm going to miss so much if I don't actually pause and and redirect my brain from, I'm just plowing forward to let me actually turn my attention towards what's happened over this recent past and really think through it. Well, what did happen this last sprint? Let me think through everything that's happened. Yeah, that wasn't great. That was okay. That was actually pretty good.

Mike (20:07)
Do you have a structure you use for helping teams find ways to get better?

Brian Milner (20:13)
You mean as far as a retrospective is concerned?

Mike (20:16)
Yeah, I you mentioned earlier asking people like, you know, what went well, what didn't. Is there a structure, even a higher level framework you use?

Brian Milner (20:24)
Yeah, mean, the way I, Astrodurby and Dinah Larson's book has a really great five step kind of process for it. But I even tend to kind of distill it down even a little bit more than that, to just say that, you if you think about this thing that we talk about as the three pillars of Scrum, that, we talk about in Scrum classes, transparency, inspection, adaptation. I think that's actually a good pattern for retrospective transparency. What actually happened? I mean, let's try to be clear about what the reality was from this past sprint. Inspection, why did those things happen? What was the root cause of why those things happened? And then adaptation, what are you going to do about it? We don't want to just keep doing the same things and let's hope everything gets better. No, hope is not a strategy, right? We have to figure out the root cause and then have a plan. What are we going to do differently?

Mike (21:12)
Yeah. What advice do you have for somebody listening right now that wants to fix their retrospectives, wants to stop them feeling useless and be productive in their retros?

Brian Milner (21:29)
Yeah, it's, you know, I sound like a broken record. It's the, it's time to inspect and adapt, right? You need to find the truth of what's behind that resistance, right? What's causing the team to not want to do retrospectives. And, and if you're a scrum master, you know, that, that could be a hard look in the mirror for yourself to kind of look and say, well, maybe I'm not doing a great job facilitating this. Maybe that's the root cause of this. Or maybe there's mistrust on the team. Maybe there's some safety issues. Do we feel safe enough to say things that actually went not so well here? Sense of fear. Or maybe the root cause is it just doesn't matter. It doesn't feel like it matters to anyone on the team. It kind of feels futile and that we're just saying the same things every time, but nothing's actually changing. So I think there's different solutions depending on what that root cause is. And I think that's where I'd probably try to focus is if it feels broken, that's the symptom. What's the root cause of it? Why is it feeling broken to everyone? And then we can come up with a plan for what to do.

Mike (22:31)
OK, that's good. Inspect and adapt at a meta level, right? mean, why is our retro broken? Inspect and adapt over that, and then inspect and adapt within the retro. So for somebody who's listening today, I want to start to wrap this up. I know we're kind of at the target limit for our podcast episodes. For somebody who's listening right now and maybe is thinking about or has skipped retros, maybe wants to get back to it, are there any things you'd like them to know?

Brian Milner (22:35)
Yeah.

Mike (22:57)
What takeaways would you give people as we start to wrap up here?

Brian Milner (23:01)
Yeah, I think that some of the big takeaways are it's important to always inspect and adapt no matter what we're doing. And that's what the retrospective is, is a chance every sprint to actually inspect and adapt. It's just a tool, right? It's important to understand the retrospective. There's nothing magic there. It's a tool. And we always say, know, individuals and interactions over processes and tools. it's not that that's a magic thing. It's a tool. But if the tool isn't working for you, then inspect and adapt on it, change it to make it work. If you feel like you've lost sight of the job the tool is meant to do, that's a big problem. And that's something that maybe should be a focus not just for you personally, but for the team. Does everyone understand what we're here for, what the purpose is, what we're trying to do with this, and why this is an important use of our time? If not, then Again, maybe you're asking me to go through something that right now is painful and I don't understand why you're asking me to go through it. A lot of these things, when we put together our Better Retrospectives course, we try to address a lot of these common kind of concerns behind why people might skip a retrospective. And as I said, there's various cures to various diseases and you have to be able to really diagnose it. and get to the heart of it before you can apply the proper one to it.

Mike (24:23)
You mentioned you're doing a webinar. you tell us about that so I can put that on my calendar? I want to join that and listen.

Brian Milner (24:29)
Yeah, absolutely. And anyone listening can. doesn't cost you a thing. It's a free live session we're going to have September 24th at 9 a.m. Pacific. So 9 Pacific, 10 Mountain, 11 Central, 12 Eastern. So it'll hit right around lunchtime if you're on the East Coast or first thing in the morning if you're on the West Coast. But yeah, it's going to be September 24th. We call this webinar, your fast track to a fresher retrospective because that's the idea. want to try to freshen it up. We want to try to give you some practical concrete ideas in just a short little 20 to 25 minute session. We want to give you some practical steps and things that you can apply immediately and take advantage of. And we're also going to give time afterwards for open Q &A. So if you have a question that's You have a burning question about retros. You feel like you have a situation you need help with. Yeah, bring it to that session and you can ask us. we're not going to be able to get through every question, but we'll be able to get through a good handful of them and try to deal with the things that we think are going to be the most popular questions there in the group.

Mike (25:41)
Good. I just put it in my calendar and notice it's September 24th is National Punctuation Day. I think the National Punctuation Day celebrations are at the bar that night. that shouldn't conflict with participating in your webinar.

Brian Milner (25:54)
Is there a sub group that has a party for celebrating the Oxford Comma during this National Punctuation Day?

Mike (25:58)
You Probably I want to see who is out celebrating National Punctuation Day. So I'll have to have to start looking for that look for look for the parties but

Brian Milner (26:08)
You I don't know who it is, but I know they are celebrating it! Exclamation point, exclamation point.

Mike (26:15)
With a few exclamation points. So thanks for letting me on here to talk to about retros, Brian. I learned a lot. I'll turn it back over to you.

Brian Milner (26:23)
Yeah, no, this was a great conversation. I appreciate you coming on and kind of driving this a little bit for us, Mike. yeah, just a reminder, we'll say that again, September 24th, at 9 a.m. Pacific. You can go to the Mountain Goat website and we'll put a link in our show notes as well where you can kind of find out more information about it and put it in your calendar.

Mike (26:45)
Perfect.