Agile Mentors Podcast

• #143: What Still Makes Teams Work (and Win) with Jim York

  What does soccer, soda, and software have in common? According to Jim York—everything. In this episode, he and Brian Milner break down what great teamwork really means, why shared goals matter more than job titles, and how understanding your team’s unique contribution can unlock better flow and results. Overview In this episode of the Agile Mentors Podcast, Brian Milner sits down with veteran Agile coach and trainer Jim York for a deep dive into what makes real teamwork tick. They unpack what separates a group of coworkers from a high-functioning team, explore the role of shared goals in driving motivation, and walk through value stream thinking using vivid analogies from sports and soda cans alike. Whether you're part of a Scrum team or leading cross-functional initiatives, this episode will help you think differently about collaboration, flow, and how teams can work better together. References and resources mentioned in the show: Jim York Jim's Blog Jim's Video Library Lean Thinking: Banish Waste and Create Wealth in Your Corporation by James Womack & Daniel Jones Liftoff Vision: Launching Agile Teams and Projects by Diana Larsen & Ainsley Nies GoatBot Join the Agile Mentors Community 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 [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and 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. Jim York is a business owner helping teams discover how to delight their customers. He uses systems thinking, agile and lean to co-create resilient, learning teams. As a coach, he works with his clients to help them grow in directions that matter to them to achieve their goals. Jim is a Certified Agile Coach®️, holding both the Certified Enterprise Coach and Certified Team Coach credentials; Certified Scrum Trainer®️; Agile Fluency®️ facilitator; LeSS Practitioner. In 2007, Jim co-foundered FoxHedge Ltd with his wife, Melissa York. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We're back here for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have the very distinguished gentleman, Mr. Jim York with us. Welcome in, Jim. Jim York (00:12) Well, thank you, Brian. Glad to be here. Brian Milner (00:15) Very excited to have Jim with us. We were just chatting before and Jim and I met years ago at a conference. We got introduced by a mutual friend, Mr. Kurt Peterson, who has been on the show. He came on a little bit earlier to talk about Kanban. And just for those people who aren't familiar with Jim, Jim is a co-founder of a company called Fox Hedge. And he has been an Agile coach, a Scrum trainer for quite a while now and I give him the title Luminary, kind of scrum luminary, thought leader, been around doing this for a while. I hope that doesn't sound insulting in any way, Jim, to call you that. Jim York (00:55) Nope, nope, just trying to shine my light and help others shine theirs. So that's what a coach does. So. Brian Milner (01:00) Awesome, Cool, well, we wanted to have Jim on because we had this topic that it's kind of a broad topic, but it's, I think, actually crucial to today's world. And that's just the broad topic of teamwork itself. So I'll start this way, Jim. I want to get your opinion. In today's world, with the changing kind of landscape with AI and everything else that we see that's kind of influencing how we work, has teamwork had its day? Is it time now for something new or is teamwork still the best way to build things? Jim York (01:34) Yeah, well, teams are universal. I think once you get more than one single individual and you get some task that requires more than what one person can do, it's inevitable. We've to work together. And so I don't see that going away. It might change a bit. But in many ways, think the things that we face today are, in many ways, things that we faced before. They might be showing up in a different way, but I think there's some universality. universality to teamwork. Brian Milner (02:03) Yeah, I agree. And so what do we mean by teamwork? Why don't we define that a little bit for everyone? Jim York (02:09) Yeah, I guess we have to step back and start looking at what's a team. If we talk about teamwork, there's this whole expression, teamwork makes the teamwork. So what's a team? And the classic definition of a team is it's a group of individuals working on a shared goal. And so it's kind of like built into the definition, we're working on a shared goal. So teamwork is that combined action. Brian Milner (02:13) Yeah. Yeah. Jim York (02:32) And so that's kind of the general concept. It's, you know, some of the parts, you know, is greater than the whole. And so it's taking that mix of experiences, knowledge, skills, and bringing them together and having that dynamic, that energy, and kind of focusing it in the same direction. You know, that's really what teamwork is about. Brian Milner (02:55) Yeah, it's good to clarify it, because I think the word team gets quite widely used in today's world. you'll hear people describe that, hey, that's my sales team. When you look at it and how they actually work together, there's not really a lot of teaming actually happening. It's just a group of individuals who have the same job and that. that format. I do think you're right. It's important to understand the difference between that kind of a team and what we're talking about here as a team. Jim York (03:25) Yeah, there are different kinds of teams and people in a sales team, even if they're not working with each other, the fact that they have a shared goal does create some sense of team. And there's different teamwork where everybody's providing kind of their unique thing. And then you have, I think like a team in a rowing, when you have like four people in a rowboat. they might have somebody who's steering the boat, you know, but they have the four people holding onto the oars and, you know, they're working at a similar cadence. You can say to a certain degree they're individuals. I don't know if they're fungible. I don't think they're necessarily fungible, but they're working together to accomplish that shared goal. know, the people in rowing, that's different from people on like a soccer team. You know, on a soccer team, you're... You got the whole pitch, you know, you're all over the place and the ball's moving around and there's this kind of coming together and going apart of various team members interacting at different places and at different times throughout the game. You're kind of acting dynamically to where the ball is and where the opponents are and where they are on the field. And so there's this creativity that occurs there that's kind of a different kind of creativity than you might see in a rowing type of competition. Brian Milner (04:18) Yeah. Jim York (04:42) But yeah, I think there are different kinds of teams, but I think that universal theme of being a group of individuals that are having that shared goal, I think that's the thing that's in common. It's not the nature of the work that some people might call agile versus predictive or planned work. mean, the concept of a team is more universal thing. Brian Milner (04:43) Yeah. Yeah. I like the example of kind of the crew, right? Of rowing and stuff. I think that's a good picture because you're right. I mean, it's very subtle, but there's a lot of combined movement. And if one person is off a little bit, it really affects how others are working. I've used the example sometimes in my classes as a contrast to think about like a golf team. You know, like the idea that you have the group of people who, again, I say this in classes. So anyone listening to this who's a golf expert, it really loves golf. Please, email in and tell me if I'm wrong about this. But this is what I say in my classes. You know, if you're on a golf team, it's a group of individuals who are each shooting their own 18 holes. But then at the end of the round, you just total up the score. And if you have the lowest lower score than another team, then you win, right? But it's, When I'm shooting my 18 holes, I'm not necessarily aware of what everyone else on my team has done or what they're doing at the same time. We don't play off each other, right? I don't take the first shot and then they take the second shot. It's all on me to do my best. And then hopefully everyone else has done their best and we just kind of see how it works out at the very last second. Yeah. Jim York (06:17) Yeah, so teams are different. know, teams are definitely different. And I think it's that idea of the shared goal that is the thing that kind of the glue that holds the team together and that shared goal that can be at various levels. I mean, it can be at this grand big picture level. You know, sometimes what's referred to as a product vision, it can be at a more discrete team level. Sometimes that's referred to as, you know, our our unique contribution to the product division. So that would be like our team mission. And then there's maybe, you know, a specific task. And so, you know, we might be working on a specific, very small, discrete task. And, you know, there's a potentially a group of people working on that thing. And, and, and those people have that shared goal of moving that task, you know, through a process to a completion state. And so there's, there's some variability here in the different kind of levels and Hopefully, there's some alignment between those different levels when you're talking about a team. Brian Milner (07:14) All right, so there's some different kinds of teams and it kind of is wide ranging in how we would describe it. There's different configurations, but we have a single purpose. We're working together towards a single purpose. That's kind of our unifying factor there. So then what makes teams work? What's the glue other than our purpose? How do we actually... Combine efforts, how do we play off each other's strengths? How does that happen? Jim York (07:47) Yeah, well, it depends, right? I mean, that's the classic consultant's answer. It depends. How do we play off of each other? If you're in an environment where you've got a known solution to a known problem and you're just executing steps in a plan, those dynamics are pretty well understood. People in that process can be trained to do different types of activities. They can gain experience in that. Brian Milner (07:50) Yeah. Jim York (08:08) That's a fairly predictable kind of process, but then there are others where it's emergent. And so we have to kind of figure it out on the fly as we go. And even those environments where it seems that we've got a pre-existing solution, there is a very clear variable there, and that's people. People show up different every day. I might have had a poor night's sleep, and people might think, well, Jim's normally fairly easy to work with, but wow, today he's... got a short temper or whatever it might be. And so we have to of figure out on the fly how we adapt to those variables. anything that has to do with people, you're going to have some variability. think stepping back, Brian, I think one of the things that is important to kind of understand or get a sense of what part of the system that we want to understand when we're talking about a team and they are dynamics, they actually are fitting within some sort of product ecosystem. And so where are the boundaries of what we mean by our shared purpose, our shared vision within that ecosystem? There's a classic book called Lean Thinking by James and Womack. And there's a really interesting example, simple diagram in the book of a value stream. And it's a value stream of a cola can. And it's kind of fascinating. You kind of see this very simple value stream in there and it starts with aluminum being, well, not the aluminum, but the bauxite actually being mined. And it goes through a reduction mill and then to a smelter. And then it goes through some hot rolling and cold rolling process. And so finally you get basically rolls of sheet aluminum that go to a can maker and the can maker is cutting the cans that are then formed into the cola can. You know, and that can maker is actually the middle of the value stream because all the things I've described so far are upstream. Downstream of the can maker, once they've made the cans, the cans go to a can warehouse somewhere and they sit there until a bottler says, hey, we need some cans because somebody's ordered some cola. And so, you know, the cans make their journey to the bottler and they get filled and then they get... Brian Milner (10:01) Hmm. Jim York (10:17) go to a bottling warehouse and of course there's transportation, there's trucks carrying these empty cans from the can maker to the bottler and then the filled cans from the bottler to the bottler warehouse and then ultimately they go to some wholesale operation and then to a retail store and then you and I perhaps will go into the store and buy a six pack of cola and we go home and we drink the cola. And so you see this very simple kind of journey, this little value stream. from the perspective of the can maker. And so, first time I encountered that value stream, I'm sitting there looking at the can maker and I'm asking myself the classic question that I ask my clients. One of the first questions I ask is, who's your customer? And so for the can maker, it can be very easy to look at that and go, well, it's the bottler because the bottler is the one who places the orders for the cans. So clearly the customer for the can maker is the bottler. Of course from a lean perspective we look further down the stream We were looking at the end of the stream to see you know, what's what's it all for? What's it all for? And if you look at the diagram you get to you know finally to the end of the stream and there's the home where the person's potentially sitting on their couch and enjoying you know that that cola and so you know if you think about all the different steps along the value stream from the mining to the to the smelting to the bottler and Brian Milner (11:17) Ha Yeah. Jim York (11:38) the can maker themselves, the retail store that's selling the cola. The thing that you would ask them that would be the glue that would hold them together for this would be what Diana Larsson and Ainsley Nees call in their lift off book, the product vision. And so the product vision is really kind of what's it all for? And the cool thing about a product vision is it's very concise, it's very succinct and everybody can hold it in their heads very easily because of that. It's typically one sentence. And so I'm going to speculate this because I'm not a, I'm not part of this value stream where Cola makes its journey to people in their homes. But I'm guessing the product vision for all of these various people along the value stream boils down to something along the lines of our customers enjoy a convenient, refreshing beverage. And so the cool thing about that simple statement is that Brian Milner (12:23) Mm-hmm. Jim York (12:28) If you were to go to the mine and ask a miner and say, some of this bauxite that you're mining, in the context of this soda, what's it all for? Now, they're probably mining bauxite for a variety of different customers and a variety of different products. But in the context of this particular value stream, they could look down to the end of the stream and say, it's all about that person sitting on their couch at the end of a long day who simply wants to have a convenient, refreshing beverage. And so that's what you know, this particular product vision is. And so that kind of calls into view a couple of things. One is context is important. So when we're talking about the product, we have to be very specific about what it is that we mean, who is that customer at the end of the stream, and what is the experience that we want them to have. And so this product vision is, as I said, very simple. our customers experience a convenient, refreshing beverage. Now, that makes it simple in terms of this particular value stream, but it also makes us aware that it's very complex for the miners because they've got to deal with competing interests from a whole lot of different customers. And so if they've got limited capacity, they may be trying to figure out, which customer do we satisfy? And so the usefulness of the product vision is being able to go to that mining company and say, do you find value in, do you want to support this activity of creating this experience for this customer with convenient refreshing beverage? And if they buy into that, if they agree with that, that's your leverage, that's your argument. why you should deliver against this value stream versus some other value stream. Now, you don't always win that argument, which is really what life is about, is we're always dealing with trade-offs and we're dealing with different options or opportunities. And so I think that's one aspect of this. But when we talk about the team in the context of a product vision, The team is huge. The team is absolutely huge because it's not just a can maker and the can maker team. It's also the bottler and the bottler team. It's maybe the truckers union that's providing transportation between these different things. the retail store. It's the retail warehouse. All of them potentially have their own concept of team. And in order to create value, it's not just what you do and provide to your next partner on the value stream. You have to really pay attention to the entire value stream because ultimately anything that doesn't come together in the right way at the right in the right place right time It puts it all at risk It puts it all at risk. So I think it's important that we kind of understand the product vision this highest level glue that holds us together and then at a more discrete level look at your team, for example the can maker and What is their unique contribution? In Liftoff, Diana Larsson and Ainsley Niece call this the team mission. And so what is the team's unique contribution to the product vision? And so for the can maker, it's also fairly simple. It's like, we make the cans. And they could flavor that a bit with, they use the latest technology and they use environment. sensitive manufacturing processes, know, they source things using sustainable, you know, approaches and the like. at the team mission level, we're getting a little bit more discreet in terms of what it is that that team is contributing to the greater whole. So think part of this is just kind of stepping back and thinking about what it means to be a team. Brian Milner (16:12) Hmm. Jim York (16:24) You know, are we talking about we're a team that's the collection of all of these things? At times that might be a useful way of thinking about it. At other times we need to kind put our heads down and focus on what our unique contribution is and make sure that we're doing the appropriate job there. Brian Milner (16:24) Hmm. Yeah, this is fascinating because so what I'm hearing is that really we have to expand our thinking a little bit about teams because teaming teams are, know, in one sense, the small group that you're working with on a on a regular basis, but it's there's a larger team concept as well of the entire value stream from end to end. All the people who are contributing, they all are are working towards that ultimate goal of, in your example, someone having a refreshing beverage at the end of their long, day at work? And how often do we actually realize that or look at that? Are the miners really even aware of the fact that they're contributing to that sort of a larger team goal? I think that's a great question. Jim York (17:21) Yeah, that's an excellent point. And what are the implications of either that awareness or lack of awareness? And I think this kind of comes to play when we think about what motivates teams. If all I know is that I'm mining bauxite, that might work for some folks. That's enough motivation. Sometimes people say my paycheck is enough motivation. Brian Milner (17:44) Ha ha. Jim York (17:45) But if you really understand what it's all about, that maybe ties into a bit of self-worth, that I'm a contributing member of society. It could also help you make the right decisions and perform the right actions if you know ultimately what this is gonna lead to. And sometimes that's a calculation that's done in terms of the quality. of the work that you're doing or the output that you're creating. For certain applications, the quality might have certain characteristics where the quality has turned up very, very high in some areas or maybe it's lower in other areas because it's good enough. And if you overbuild quality, you might be introducing some waste because it's not. It's not necessary for the job at hand. In other places, if you deliver below quality, you introduce some risk that the product is not going to be, or the ultimate customer experience is not going to be what it is. I don't know about you, but I've occasionally gotten one of these plastic soda bottles where they've made the plastic so thin for the soda bottle that the liquid is actually needed inside the bottle to maintain the structural integrity of the bottle. Brian Milner (18:54) Yeah. Jim York (18:54) And if I were that customer sitting on the couch at the end of a long hot day, let's imagine it's a white cloth couch and I'm drinking orange soda and I reach over to pick up the soda and my hand, you know, grasping around the soda bottle, all of sudden the soda bottle just collapses in my hand and orange soda goes all over me and the couch and everything else. mean, that's, you know, there's some quality characteristics, some specifications around that. Brian Milner (19:02) Ha ha ha. Jim York (19:18) container that that plastic container that has to integrate well into the rest of the process. It has to work with the bottler and it has to work with the consumer when they're actually using it. So it's understanding the whole can certainly help teams feel a sense of purpose and also can guide that decision making in those actions around it. Brian Milner (19:30) Yeah. Yeah, I think that's an important thing to keep in mind and remember because, you you mentioned, you know, some people would say paycheck is a motivator. And I, you know, I, I kind of subscribe to the Dan Pink kind of motivation philosophy that, know, that, can only do it so far that it is a motivator, but it is a motivator only to a certain point. Beyond that point, we need more. We need more to motivate what we're going to do. Cause you know, there's a million things out there that can give me a paycheck. I could work in a lot of different places, but I've chosen to do what I do for a reason. There's something that fulfills me from doing that, or I prefer it in some way to what my other options might be. I know I've heard people say this in classes before, the idea of how do you have a vision for somebody who builds clothes hangers? We have this talk about vision, this grand design. Big purpose. Well, how do you do that for someone who has clothes hangers? You know, like I get that, you know, there's not everything, every product in the world has, you know, a save the world kind of vision, right? But I think you can, in your example of kind of the mining thing, I think is a good example of this because you can connect it to that ultimate value. And when you connect to that ultimate value, it doesn't that motivate people more to think, hey, I'm helping someone who's had a hard day. I know what that's like. Have a hard day, sit down on your couch and you just want to relax a little bit. Yeah, I want to help that person. Like that, is something that that'll gets me out of bed, you know? Jim York (21:06) Mm-hmm. Yeah, and I think that does require you to think beyond what we often think of as being the team. Because to make it all come together and result in that ultimate product vision, that, you know, the person having the convenient refreshing beverage, in my example, you know, all of those different parts have to come together. And any one of them, if it doesn't happen, you know, that we don't have that value that's realized at the end of the value stream. And so having that connection to what it's really ultimately about is critically important. And understanding where you fit into that and what your value add work is, I think is critically important. And so we talked about like at high level product vision, we talked about this unique contribution of your team like the can maker, and so our team mission, we make the cans. And then we get to the practicalities of the task that's in flight, the work that we're doing right now. And I think that's a critical piece of this puzzle. What is it that's the thing that's being acted upon right now? The work in process or the work in flight. And depending on what the nature of that is, I think that drives a lot of... decisions and one of them is around, you know, who do we need? So who are the actual people, you know, that have the right skills, knowledge, experience in order to do that work? And also it informs our process and so, know, again, that process could be something where it's a known process and we're just, you know, turning the crank or it might be something where we're having to figure it out on the fly. Regardless of the nature of the work, there's going to be a workflow. When we're trying to get something done, the work is going to be flowing through some sort of process. And it's that flow that really intrigues me. we want to look at the flow, especially if speed matters. And why would speed matter? Sometimes speed matters because customers want what we are building yesterday. So they want it as soon as possible. So time to value is often what's considered there. If we're something new that hasn't existed before, sometimes we're also building quickly so we can get it in front of someone to get their reaction to see whether it's fit for purpose. So we might think of that as being time to feedback. But the flow itself is there's the workflow. And so work, the nature of it is a piece of work is something that maybe an individual can go work on. Other times there's a piece of work that requires more than one person to work on. So there's an element of collaboration with that. Even when it's an individual that can work on a piece of work, usually they've received something from somebody that allows them to start that piece of work. And when they're done with that piece of work, they're passing what they've done along to somebody else and that other person is picking up. So even if... there's an ability to work on a discrete task by yourself, there's still an interaction often on the front end of that and the back end of that. So work is still flowing and we have to figure out how to collaborate in such a way that the work that is not being held up in some queue somewhere where we're getting some bottlenecks and that they're constraints. so figuring out how do you enable the work to flow and how do you enable the people to flow? Years ago, I had an opportunity to coach soccer and on my team, I taught them, in addition to like skills, I taught them three concepts. And so the first one was, everybody on the team should know where the ball is. And so it seems pretty obvious, you should know where the ball is. But if you look at this from a team building software perspective, does everybody know where the ball is? You know, what is the work that's in flight and what's the current state of that? I mean, we use information radiators to try to help people understand where the ball is, but often I don't think we use them as effectively as we might. So I'm always challenging teams to figure out, you know, how do you use your communication systems, your information radiators to enable everyone in your ecosystem to understand, you know, what's the work in flight and what is its current state? And why do you need to know that? Brian Milner (24:55) Hmm. Yeah. Jim York (25:24) Well, if you know where the ball is, you can get a sense of what are the things that are in the way of that ball moving forward. So my second rule for the team was know where your obstacles are. And so in a soccer game, you're seeing your opponents. And so you might have a great plan on how you're going to advance the ball from where it is currently down the field towards the goal. But little problem with that. You've got people on the other team trying to keep you from getting there. So you're having to react real time in the moment to those obstacles. And so in addition to everybody on the team knowing where the ball is, everyone on the team needs to know where the obstacles are. And so when you have that information, and again, for a team building software, this is the kind of thing that should be readily available in some sort of information radiator, real time ability to see where the ball is and to see what's in the way. Why is that important? Well, if you know where the ball is and you know where the obstacles are, you can position yourself as a team member to be what I called the help. And so by the help, that's the one or two people on your soccer team that if you're the one with the ball, you know you can pass to them easily. You know, that they are constantly moving around and positioning themselves to be in the place where it's possible for you to get the ball to them. So who are those two people? Well, it changes depending on where the ball is. And so what the team has to do is kind of get a mental mob. Brian Milner (26:41) Ha ha. Jim York (26:47) in their heads of the actual position of people on the field and get a sense of if the ball's here and the obstacles are here, then I should put myself here. Now, it isn't for all the team members to position themselves to be the help because that would be crazy. Just as we see on Agile teams, when somebody picks up a task, the whole team typically doesn't swarm on that task. It would be too many people on the task. Brian Milner (27:06) haha Jim York (27:16) So who shows up to work the task? The right number of people with the right skills and knowledge. So how do they know to come? It's because the work is made visible. And so they come because they see that they're needed. How fast do they come? Ideally, they're there instantly. Now, why might they not be there instantly? Because they might be working on some other tasks. And so if this were to happen in soccer game, you would see the other opponent, you know, they would be... basically scoring goals against you right and left because when you try to pass the ball, you wouldn't have somebody there to receive the ball. So knowing where your help is, if you've got the ball and passing it to that person helps you continue the flow down towards the goal. So if you're not the person who has the ball and you're not one of those two people that are the help currently, What you're doing as another team member is you are. orienting yourself on the field so that you will be the help when it's needed. And so there's this constant movement of people down the field. And where this really brings it home, I'll use this example, and I'm coaching agile teams, is they'll talk about how all their work and stuff, and I'll use the example of the soccer game and the one ball, and they say, now let's imagine you put two balls in flight. Brian Milner (28:16) Hmm, that makes sense, yeah. Jim York (28:36) Can you optimally move those balls down the field towards your opponent's goal? And typically, there is a limit, right? How many balls can you put on the field? Two, three, 15? It's like, yeah, it really drives home the point of limiting the work in process. the teamwork is made more effective and efficient if we have some sense of where the work is, what is the nature of it so that people can come and go, I call this people flow. so we're looking at things like the, well, out of... Brian Milner (29:05) Yeah. Jim York (29:09) out of the concept of open space, the law of mobility. It's like within our organizations, within our teams, can we have people flow to where the work is needed and also have people flow away from the work when they're not needed? And so enabling that autonomy of the individual to be able to go where they need to go in order to optimize the flow is a... Brian Milner (29:13) Yeah, yeah. Jim York (29:34) is a key organizational design problem. Brian Milner (29:37) Yeah, yeah, this is fascinating stuff. mean, I love the analogy with the soccer teams and that I mean, I, that makes sense to me. I love kind of where you're going with this. If people are hearing this and thinking, well, I like to hear more about this stuff. We're going to put links in our show notes back to Jim's site on this because he's got a lot of blog posts. They're kind of around the same theme on this. And we'll link to those specific blog posts for you so that you can find them. But Jim, I want to be respectful of your time and our listeners' time. So thank you so much for taking your time out to share this with us. Jim York (30:08) Well, I've been very pleased to join you, Brian. Thank you for the opportunity. Brian Milner (30:13) Absolutely.

  --------  

  32:32
• #142: Communication Patterns Keeping Your Team Stuck with Marsha Acker

  If your team keeps revisiting the same issues over and over again, Groundhog Day-style, this episode is for you. Leadership coach Marsha Acker shares why it happens, how to recognize hidden conversational patterns, and what to do when you feel stuck. Overview In this episode, Brian Milner sits down with executive team coach and author Marsha Acker to unpack one of the most frustrating challenges teams face: circular conversations that never seem to resolve. You know the ones; same issue, different day. Marsha introduces a practical framework, structural dynamics, to help leaders and Scrum Masters decode what’s actually happening beneath the surface of their team’s conversations. From identifying communication patterns to creating space for dissent and inquiry, they explore how to break out of those conversational loops, build psychological safety, and foster real change. Whether you're leading meetings or just stuck in too many of them, this episode will help you shift the dynamic for good. References and resources mentioned in the show: Marsha Acker The Art and Science of Facilitation by Marsha Acker Build Your Model for Leading Change: A guided workbook to catalyze clarity and confidence in leading yourself and others by Marsha Acker #137: Stop Wasting Time with Guests Kate Megaw #94: Connecting Teams and Leadership with Anthony Coppedge Retrospectives Repair Guide Better Retrospectives Join the Agile Mentors Community 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 [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and 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. Marsha Acker is an executive coach, author, and the founder of TeamCatapult, where she helps leadership teams break out of communication ruts and lead real, lasting change. With two decades of experience guiding everyone from startups to Fortune 500s, Marsha specializes in transforming how teams talk, decide, and grow—one conversation at a time. Auto-generated Transcript: Brian Milner (00:00) Welcome back, Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have the honor of having Ms. Marcia Acker with us. So welcome in, Marcia. Marsha Acker (00:12) Hi Brian, it's good to be here. Brian Milner (00:14) Very very happy to have Marcia with us. Marcia is the CEO of a group called Team Catapult and she is a team coach. She does a lot of work with teams and leaders. She's an author. She's a speaker and we wanted to have her come on because of a book that she has out recently called Build Your Model for Leading Change. She also has another book called The Art and Science of Facilitation, which I'm sure is really appealing to a lot of people here as well. You know, as Scrum Masters, if you're a Scrum Master out there, we do a lot of facilitating. So that's probably a really interesting pickup for you also. But we wanted to have Marsha on because we wanted to talk about an issue that I hear a lot about in classes. This is something that I hear a lot of questions around, and it can be a really big source of issues when you think about working together in close, tight units as a team. And that's how teams communicate. kind of the issues and problems that we have with communication amongst teams. So, you know, when we're talking about this, we're talking about teams not listening to each other, not understanding each other, misunderstanding someone's motives, something like that. And one of the things I know that I've seen a lot, I've encountered this a lot, and this is one of the things that I know you talk about quite a bit in your book, is this kind of loop that we get in a little bit, right? We have these conversations where... It just feels like we're stuck in a loop. We're saying the same things over and over again. it's like, I in Groundhog Day? Am I reliving the same thing we just went through? So let's start there and just say, why do you think that that happens? Why do you think that teams have this kind of Groundhog Day effect where you might have these conversations that just kind of keep popping up over and over again? Marsha Acker (01:35) Mm-hmm. It's a great question, Brian. think a number of years ago, I had a background in facilitation, but I got really interested in this particular question because I found not only in my own experience, I had multiple examples that I could give you of conversations that I felt like I'd have with somebody. then we would be, a week or two later, we'd be back talking about the same thing. And I'd think, I, you know, from my perspective, I thought we resolved that. So, so why are we talking about it again? And then I noticed in my work with teams that they would do the same thing. So, you know, I'd be in a session with a team, I'd help them facilitate a decision. They'd make the decision and then I'd be back with them a month later and the same topic would be up. And I'm I just found myself confused. So I think, I think there are many reasons why that happens. But if I were to, If I were to create a theme for that, think there's a couple of big themes that I see play out. I think there are many places on our teams today where we stay at the surface level of the conversation. Like we get super focused on what we're talking about. So whether it's the tool that we're using, the features that are gonna be in the next release, like we get so super focused on it. And then we're hyper. aware of time boxes. So we want to make sure we talk about the thing, get the decision, and we want to do it in 30 minutes or less. I saw a post on LinkedIn the other day where someone was advocating that there shouldn't be any meeting that would need to go past 25 minutes. And I thought, see it really differently because I think while there are places where we absolutely do need to maybe just quickly exchange information or keep things moving along, or we just want to hear briefly from people. I think if we're advocating that every meeting should only take 25 minutes, we are likely going to have those Groundhog Day conversations because it doesn't give us the space to get to the real topic. So I think that's where we spend a lot of time talking about the thing, the topic, and we really don't create enough time to drop down into focus on are we really, there space here for me to share what I really think or do you just want me to show up here in this meeting that you're running? You clearly have maybe your own agenda. You feel like you've already got the decision made. And so you'd really like my role to be to just receive your information and go off and do it. So I think there's a complexity here of Brian Milner (04:27) Yeah. Marsha Acker (04:32) What's the topic we're talking about? Is it the real topic that we need to talk about? Or is there, is it sort of the mask for what we might be able to drop into a deeper conversation to have? Are we being super focused on a time box? And are we creating enough range in our meetings that we've got spaces where we are efficient and fast and very deliberate about the conversation and then other spaces where, you know, those topics that keep returning. They're great places to go, there's data here for us. I think of them as yellow flags. there's something here for us to explore further. So let's take this topic and let's carve out a little bit more time for it. I'm curious what you see. Brian Milner (05:15) Yeah. No, that's a great observation. And I think you're right. It is a frustration. Looking back over my career and looking back through corporate meetings and things I've been a part of, there is frustration with someone who's coming in and not really having a meeting planned and not really having an agenda. But I think there is another kind of side issue there that can cause a lot of misunderstanding about Marsha Acker (05:33) Yeah. Brian Milner (05:44) what we're trying to achieve and that's the purpose. If we're here for a certain topic, I can understand that, but then what is it that's expected of me in this meeting? Am I here to just receive information? Is this a knowledge dump or a status update from someone else? is this, we have an issue and we need to talk through it and fully understand it. Marsha Acker (05:47) Yeah. Mm-hmm. Yeah. Brian Milner (06:13) And I think sometimes that's what I've kind of seen is that there's this mismatch of, well, I thought I was here for this. And now it's clear that you don't really want my opinion. You just want to tell me what it is. And so now I'm refocused or the opposite. I thought I was here just to receive information, but now I'm realizing that you really need me to dig in and give you my educated advice on this. Well, I wasn't prepared to do that. Marsha Acker (06:20) Yeah. Yeah. Yeah. I think this notion, and I see it happen a lot with Agile teams, like somewhere in our professional careers, and I think there's very good reason for, like we get rewarded for, know, from the time we're in very early school all the way through the end of school, we get rewarded for having answers. And then we end up in the workplace and we find ourselves in collaborative spaces. And so I think there's this belief that, you know, someone who's calling the meeting, they will have a little bit of this internal story that if I come with only questions and no solutions, then what value am I adding? Like that's, how am I useful to this organization? I've actually had people say to me, why would this organization hire me to come in and ask other people questions? Brian Milner (07:28) Wow. Marsha Acker (07:29) And so I think that's really, I love giving voice to that because I do think that there's a narrative that sits in our organizations that I, and a little bit of a fear. Like if I come to a meeting and I'm asking people to collaborate or I'm truly asking them open ended questions and I want to hear what they have to say and we're going to listen to, you know, I talk a lot about wanting to create this collective intelligence. And I think it takes a while to access that in a group of people. that it requires us to be able to suspend this idea that we're not adding value if we're asking questions and to reframe our value as helping to tap into a collective. And you can certainly have a point of view or a perspective, but if you're really wanting to tap into that intelligence, then I think it requires something different of us if we're the meeting host or the meeting leader. I think the other thing that will happen too is depending on who's in charge, like senior architects or somebody senior in the team can also get caught in that trap. Like, well, I'm supposed to come with answers. And I think we can come with ideas. But if we're really wanting to collaborate, and then this gets to your point about why are we gathering? Because sometimes I think there will be places where somebody has already made the decision and they're not asking for input on the decision. Brian Milner (08:42) Yeah. Marsha Acker (08:50) but they're wanting to share the decision that's been made and enroll people in the decision that's been made and invite them into collaborating on actually how that's gonna get implemented. But we're not opening this conversation up for what's been decided about architecture, what's been decided about what's going into a release. So I think this clarity and intentionality like you talk about around purpose, why am I here? What do you want from me? It's huge. And I think it's really tied to also some of our thinking about how are we adding value. Brian Milner (09:23) Yeah. The comment about, know, people not feeling like they're adding value if they're just asking questions that, kind of, maybe it's just for my recent experience with coaching and everything, but to me that, that just, it's so contrary, you know, to, to my way of thinking now, I guess I would say in that, you know, when I've been a part of discussion, when I've been part of a meeting, that I've looking back, that I feel like has gone really well. Marsha Acker (09:26) . Mm-hmm. Brian Milner (09:48) Uh, or, or a person that I feel like has really contributed to the meeting. Oftentimes it, it is that person who is asking questions that get us to think in a different way to get us to consider from a different perspective. So, you know, that that's why it feels a little strange to think about it. I agree with you. I agree that that's, you know, the attitude of some people or that's the way they see, you know, how I contribute to a meeting, but it just feels like it's such the opposite of that. That might be the most valuable thing we could do is to get people to see things from a different perspective or consider maybe things they haven't considered about this issue. Marsha Acker (10:25) Yeah, I think it's one of the first mindset shifts in a transition from being a contributor to maybe managing or leading, whether it's you're just leading a team or whether you're leading a whole organization. I think this idea of where does value come from and what's my role in the value creation, it's a shift, I think, for us. I love when people can get to a place of thinking about creating containers in organizations where people get to be their best. And then it does, your thinking does shift from, what's the piece of content that I can contribute to? What's the question that would really unlock different perspectives? And I think the other piece about that is what's the question that would elicit a... I talk about it being opposed, but you know, a contrarian perspective or point of view, because I think that's the other thing that can keep us in these circular conversations is when what we're really thinking doesn't get said. So if I don't feel like I can tell you in the room what I'm really thinking, I'll tell everybody else offline. Brian Milner (11:34) Right. The meeting after the meeting, right? Yeah. Yeah. And that, course, gets to the heart of psychological safety and kind of those dynamics within a team. We started this off talking about kind of this feeling of getting stuck. And so I want to kind of come back to that a little bit and say, I want to ask you, what are some of the causes of that? Why do we find ourselves trapped in these loops? Marsha Acker (11:36) Yes. You Mm. Brian Milner (11:59) that just, know, whatever we decide doesn't actually do anything or we find ourselves right back in the same place. Why do these, what's causing this? Marsha Acker (12:08) Yeah, well, let's play around with a bit of a framework to help us think about what's happening in the conversation. Yeah. So there is a theory of structural dynamics. It comes from work of David Cantor. And what it allows us to do is sort of think about being able to code the conversation that we're happening. And by code, I mean it helps us focus not on the topic. So whatever the topic might be. It doesn't matter. It helps us focus on how we're engaging in that conversation more of the how. And so there are four actions. Everything that we say could actually be coded into one of four actions, which I think is really kind of fascinating. So you just made a move by taking us back and pointing to the topic about stuck conversations, right? So what keeps us stuck? And that's a move because you're pointing in a direction. So moves kind of set direction in the conversation. I could make a new move and say, you know, let's talk about, yeah, where we might meet at a conference sometime, Brian. But that's a totally different topic. So moves set direction in a conversation. The second action is a follow, which gets behind and supports. So I followed your move by saying, yes, that's great. Let's do that. Here's, and then. Brian Milner (13:12) Right. Yeah. Marsha Acker (13:26) And then a bit of a new move from me, let me introduce a language for thinking about that. So you made a move, I followed, and then brought in another move. So now we're starting to, by being able to name actions, we're starting to get a sense of patterns. So there's two more actions, the action of a pose. So a pose offers like really clear pushback. It says, no, hang on, stop. Let's not go off the bridge or. I really disagree with this piece about what you're saying. So it offers a clear pushback or constraint to what's been said. And then the fourth action is a bystand. And a bystand is a morally neutral comment that names what's happening in the conversation. So I could bystand on myself in a conversation and say, you know, I'm really feeling engaged by the dialogue, or I might say I'm really confused. or if we're noticing a pattern, somebody might say, I notice we're getting stuck. So a bystand is a way for people to name what's happening or bridge competing ideas. But the other thing, the benefit of the bystand is that sometimes it also slows down the conversation. So to your question about what gets us stuck, it's really helpful if we can separate. what we're talking about and start to briefly look at how we're talking because what gets us stuck in conversations is when one or more of those actions is missing over the course of time. So we need all four of them to be voiced. One of the biggest problems in our stuck conversations is that a pose goes offline. Not in every team. There will be teams for whom a pose is stronger. But in my experience in American business, for sure, a pose is often the thing that is missing or it goes offline. So the way it will play out, there's a couple of different patterns. One will be what we call serial moving. And those are teams. Like a meeting with serial moving will have lots of fast pace. So somebody says this. then we're talking about this topic, now we're talking about this. And it will, like, you'll have a feeling like we accomplished a lot, but then you walk out at the end of the session and you go. So we talked about, exactly, we talked about this, this and this, and I don't know what we decided. Brian Milner (15:52) What just happened, right? Marsha Acker (15:58) So people that leave those kinds of meetings, they'll have this sort of false sense of, yeah, we got somewhere when we really didn't, we didn't close things out. So serial moving can be a pattern that can keep us stuck because we don't close things. There can be another pattern where there's a lot of move and follow. We call it courteous compliance. Another word for it would just, I forget the other label that we can give to it, but there's the sense that somebody makes a move and everybody else just says, sure, fine. So it's lacking the energy of the dynamics that you would get if the other actions were active and being voiced. And then there's a pattern where we might have too much bystand. So in a team that starts to complain about why did we use this tool or, know, I'm noticing nobody's using Slack or I'm noticing, you know, when we, when something gets posted in Slack, nobody acknowledges it. So if you find yourself in a meeting where, people are sharing a lot of context or perspective, maybe we can, I call it a hall of mirrors. Like we've got lots of perspective, but what's needed is for somebody to really make a move and say, all right, so given that now, what do we want to do about it? So what's really fascinating about those, we can also get locked in a move and a pose, a really strong advocacy or argument. And what's needed in that kind of argument is we need more follow and bystand. But what I find fascinating, so a pattern that I see play out over and over again will be one of two, the serial moving or the courteous compliance. So we've got a lot of moves or we've got move and follow. Brian Milner (17:25) Yeah. Marsha Acker (17:45) And if I'm someone in the meeting that either doesn't feel like my voice is welcomed or that it would be a career limiting move to oppose you, what I'll do is start to use one of the other actions in place of my oppose. So if it's not okay for me to push back and say, Brian, I don't want to talk about that, or I disagree, I think we're going off track, then what I might start doing is just making new moves. Brian Milner (18:02) Hmm. Marsha Acker (18:15) So rather than say to you, hey, Brian, I don't want to do that, you'll be talking about something, and now I'm introducing another topic. Hey, can we talk about where we're going for lunch next week? Or can we talk about the meaning behind that word over there that we were using last week? we don't do it intentionally. It comes for really good reason. Brian Milner (18:36) Right. Marsha Acker (18:39) We will all have our own reasons about why we do or don't do that. But I think some of the greatest work to do in teams is to talk about those four actions, to normalize them, and to invite them. Brian Milner (18:52) I love this. what kind of fascinated me, caught my attention the most about what you were saying is when I saw these, and kind of reading up here and reading through your work prior to our discussion, those four modes, when I read it, the first time it seemed to make sense, move, follow, oppose, bystand. But when I saw bystand, it really did seem, my first initial gut response was, yeah. That makes sense. There are bystanders that are happening in meetings that just do nothing. They just kind of sit back and they're not going to be, you know, they're not going to get in the way of the flow of something. But the way you described it is really fascinating because it's not a passive thing. It is an active participation. Marsha Acker (19:35) Yeah. Yeah. Yeah. Actually, if somebody is, well, I love that you're naming that because I get asked that question all the time. So again, American business trends. So if you step into the mind of someone who believes that I'm really only adding value if I'm bringing ideas and the way we would code that would be often you're making moves. So people will tend to value. making moves and opposes because a lot of times that's what the culture values. If you're in an organization that says, bring me problems, bring me solutions, you will find a cultural pattern in there of people showing up and making moves and opposes throughout their whole meeting. It'll be a stuck pattern. It'll be overused actions. But if we think about, so bystand could be questions, asking powerful questions. what's that mean to us falls along the line of bringing inquiry into the conversation. And so it gives us a way to balance advocacy and inquiry. But bystand is, bystand and follow are active. If somebody was not saying anything in the conversation, we wouldn't know, we wouldn't be able to code them because they're not speaking. And those four relate to speech acts. So, We have to speak in order for it to be coded as something. But those people who are sitting back often have some of the best bystands. Like if you were to tap that person on the shoulder and say, hey, I would love to know what you see right now in the conversation, they'd probably be able to tell you. Brian Milner (20:57) Yeah. Yeah. Yeah. I love this. And, you know, one of the things we teach in our advanced Scrum Masterclass is having people kind of understand how to deal with conflict in their teams and stuff. And we talk about the Thomas Killman kind of five responses to conflict. And I'm seeing a lot of overlap here in these modes too of, some of these things sound like a certain response to conflict in certain ways as well. But before we run out of time, I want to... Marsha Acker (21:30) Mm. Yeah. Brian Milner (21:43) I want to make sure that we get to, if we're in this situation, what are some steps, what are some things we can do to break that chain and not just have the same conversation again next week. Marsha Acker (21:48) Yeah. Yeah. So I would love for people to just think about using those four actions, especially if you work with a team on a fairly frequent basis, right? You will likely, even as I describe those, you will likely start to be able to identify what's the pattern that might be showing up. So I think the first step is can you identify or create a hypothesis for yourself about what might our structural pattern be? So do I hear like really clear poses? You know, do we make a lot of moves? So if you can find the actions that are predominant in your conversation, that's really the first step. And then the second step, there are a couple of different things to counteract each of them. So if move is really strong and it's coming from certain people, designing your facilitated session or even inviting participants to other participants to be the ones to make the move. So inviting others to speak first is one way to do it. limiting the number of moves that people can make. So sometimes if I'm working with a team that has that pattern, I'll give them some kind of, I'll give them a poker chip or I'll give them a card that says move on it. And I will limit everybody to one move per meeting. So structurally, I'm asking people to start to constrain their own moves. And then asking them to then step into, know, if somebody makes a move, staying with it long enough. as, so as a facilitator, you might say, if you noticed that you've got multiple moves on the table, you might just say, Hey, we've got four topics. This, this, this, and this, which is the one that we want to dive into first. So that's another way of just prompting a group to follow a move that they've made. And I think if you're noticing, you don't have a pose. You. chances are that is not going to come naturally. So I think you've really got to design questions that surface it. asking for what are the risks or who sees this differently. A lot of times if I'm leading a session, I will ask people, where did I get it wrong or what do I have wrong? Brian Milner (23:47) Yeah. Marsha Acker (24:12) What am I missing? What might I not be seen? So those are all ways for me to prompt. And I think if you've got some hierarchy in the room or differentials about that, that's really got to come from the person who's sort of holding some of that positional power maybe. Brian Milner (24:29) Yeah, I love that because there's there's sort of a maybe it's an American culture thing. I don't know. But but I know in the business world I've experienced if you call a meeting if it's your meeting there there's sort of an expectation that you're in control, you know, you know, it feels like there's there's sort of a you're not invited to say something like, what am I missing? Marsha Acker (24:52) Yeah. Yep. Brian Milner (24:53) because that's sort of admitting that you weren't prepared for this meeting. But I agree completely with you, that's not really the case. It's just saying, I can't know everything, so what don't I know about this, I should. Marsha Acker (25:09) Yeah. And it's hard. That can be a hard question. And I often say to people, don't ask the question. Don't elicit a pose if you're not really ready to hear it. It can be hard when somebody says, I think it's a two-ee. I totally disagree with the direction that we're going. Because if I, as the person who's asked the question and now receiving that feedback, If it starts to show on my face or I disconnect from it, what's gonna happen is that gets registered across everybody in that room. And that'll be the last time anybody steps up to answer that kind of question. Brian Milner (25:36) Right. Yeah, I love as well when you were talking about, you know, the actions and maybe having tokens or stuff for people to have actions. think I don't, I'm sure this is maybe part of the intention of this as well, but I love the side effect of that, that yes, I'm limiting people who would be controlling to not, not take control of the entire meeting, but once they've spent theirs, now I'm in a situation where the people who maybe wouldn't be those people that would normally step up. They're the only ones who have that ability left. So you have that side benefit of I'm kind of making space for the quieter voices in this group to have a chance to speak up. And I think that's a really important thing in these kind of meetings too. Marsha Acker (26:35) Yeah, when we find ourselves in stuck patterns, there will be very good reason for, or the Groundhog Day conversation. There will be a pattern to the structure of that conversation that keeps repeating itself. And a lot of times what will be happening is somebody will make a move and very often the person that follows them will be the same person every time. So if Marsha speaks and then Brian follows and that's a pattern that gets set up. every single time. All it does is reinforce me to make more moves because I know you're going to be right behind me. And then over time, we're really unconscious, I think about it, as a structural pattern. But the rest of the team will start to fall back and be like, well, they seem to have it. There's no need. No need. So yes, what we're trying to do is change the behavior by looking at structure and finding ways to invite it. Brian Milner (27:34) That's awesome. This is fascinating. I want to be respectful of your time and everyone's time listening, I could go on for another hour in this conversation. This is just really fascinating stuff for me. And I want to point out to everyone again, if this is fascinating to you, we're going to put all the links to this stuff in our show notes so that you can easily just click on that and find it. But just to call it out again. Marsha Acker (27:41) You Brian Milner (27:55) Marcia has a couple of books out there that are in this topic area that could be really useful to you. One is the art and science of facilitation. And the one that I kind of took a deep dive into is called Build Your Model for Leading Change, which by the way, there's a subtitle of this, a guided workbook to catalyze clarity and confidence and leading yourself and others. And I just, would underline the workbook. Right? Because I think it's true. It is something to kind of work your way through. And it's not just a beach read. Yeah. Yeah. Marsha Acker (28:27) No, it's not. I like to think of it as a Sunday morning, maybe with a cup of coffee and a little bit of quiet space. Brian Milner (28:36) Yeah, love that. I love that picture. Well, Marsha, I can't thank you enough. You know, we've been kind of trading schedules and trying to align this to get Marsha on for a while. And, you know, when that kind of thing happens, for whatever reason, it always seems to be like, when the person comes on, it's like, wow, that was worth it. I'm really, really glad we went through that because this was a great conversation. So thanks so much. Thanks so much for sharing your research and wisdom here on this. Marsha Acker (28:56) I appreciate it. Brian Milner (29:02) and for coming on the show. Marsha Acker (29:04) Thank you for having me. It was great.

  --------  

  36:33
• #141: Cooking Up a Killer Retrospective with Brian Milner

  Tired of “What went well?” and “What didn’t”? Brian Milner is here to help you cook up retrospectives that actually get your team thinking, collaborating, and improving. From creative themes to actionable frameworks, this is your behind-the-scenes guide to better retros. Overview Do your retrospectives feel more “check-the-box” than game-changing? Brian Milner shares his full recipe for planning and facilitating retrospectives that actually matter. Whether your team is stuck in repetition, tuning out, or phoning it in, Brian’s step-by-step approach will show you how to bring structure, creativity, and energy back into the room. Brian walks you through the five essential components of a retrospective, including how to match formats to your team’s personality, align activities with Agile's three pillars (transparency, inspection, and adaptation), and spark meaningful change with every session. References and resources mentioned in the show: Stranger Things Retrospective Download Agile Retrospectives by Esther Derby & Diana Larsen Retromat Blog: Overcoming Four Common Problems with Retrospectives by Mike Cohn Blog: Does a Scrum Team Need a Retrospective Every Sprint? By Mike Cohn #139 The Retrospective Reset with Cort Sharp Retrospectives Repair Guide Better Retrospectives 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 [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and 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. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast, like we always do. And I'm with you as always, Brian Milner. Today we have with us, me, just me. Now, before you get frustrated with that or think we're copping out in some way, this is intentional. I wanted to have an episode to myself because and working through all this stuff around retrospectives, I thought that it might be good to take an episode here. And I kind of thought of it sort of like a cooking episode, right? Like if you watch a cooking show, you know, Gordon Ramsay show or something, they'll walk you through how they make something. And it's from start to finish. They show you the ingredients. They show you how everything's put together. And then you see this beautiful dish at the end. Well, I've often compared the way that you can format a retrospective to a little bit like a meal, because a meal has different courses in it. And a retrospective should have these themed areas or repeatable sections of it. And so I thought of it a little bit like making a meal. So I thought I'd just walk you through a little bit step by step. what I'm thinking here and how I would go about doing it. this is, you know, we're cooking up something special here. It's a kind of a recipe here that's, you know, equal parts creative and effective. It's a way to try to keep your retrospectives interesting, but also keep them to be solid and where you can have an actual outcome that comes from this. And you actually make definitive changes here with your team as a result. So there's a couple of retrospective courses that I have coming out where I go into detail about all these things, but I wanted to take an episode where I could walk you through and just have you kind of peer over my shoulder a little bit about how I might do this if I was going to create a retrospective for a team. So first starters, I think we have to understand that there is a menu to follow, right? And I kind of use this menu metaphor because one of the great things about when you go out and you have a meal at a nice restaurant is there's a repeatable pattern to it. You kind of expect that they're gonna bring you a drink first and then maybe you have, if it's a really fancy restaurant, maybe you have appetizers first or hors d'oeuvres even before appetizers, then you maybe have appetizers or not. Then you have a main course and maybe you have a salad even before the main course and then you have a a meal, and then you have some kind of a dessert afterwards, maybe even some kind of a cocktail at the end of the meal or coffee at the end of the meal. But there's sort of a pattern to it. And regardless of what restaurant you go to, you kind of repeat that same pattern. Now, I know that there's times you'll be, this is where the metaphor kind of breaks down a little bit, I get it. You may not have the same pieces every time. And what we're going to be talking about here as a retrospective pattern is that, yes, you should sort of follow the same pattern. You can't really get to, let's say, dessert. You can't just skip and go to dessert, right? You've got to go through this journey of the other sections so that you can end up at dessert and really fully appreciate it, right, and get the most out of it. So that's where this metaphor is a little bit of a, starts to break down a little tiny bit. But. I want to talk about here first why retrospectives matter and why they often go stale. I think they often go stale for a lot of reasons, but one of the chief reasons I've encountered when I work with teams is that the Scrum Master on the team really only has a small amount of formats and styles that they have to work with. They have a small little set in their toolbox. And they may even rotate through a few of them. But at the end of the day, it's kind of a small toolbox. There's only a few tools in there. And if I'm a team, if I'm a member of that team, you can imagine how I might get bored. And I might think this is not really worthwhile if I'm showing up every single time and I'm hearing the same exact questions. What did I do? What do we do well? What do we not do so well? Do I have any roadblocks? If I'm just asked that same thing every time, then I might not feel like this is a very worthwhile thing. Or I might get to the point where I feel like, gosh, I've answered the same question, you know, three sprints in a row. I just, got nothing more for you Scrum Master. I just, I can't dig any deeper. I've given you everything and it just feels like this is the, you know, groundhog day. We're doing the same thing over and over again, but nothing's really changing. So. I think it's important that we be able to switch things up, but it's not change just for change sake. That's why I think that having a structure of some kind can give you that pattern to fall back on that can make it effective, but then also can provide variety, can make it something that changes over time as you do this with your team. Doesn't mean that you can't ever repeat a format that you've used. I don't think that's a bad thing. I just wouldn't want to repeat the same, just handful, small little number of them over and over again. That's going to get repetitive and it's going to make people a little frustrated. The other thing is I think you have to match these to the personality of your team. Your team might be more outgoing or they might be more introverted. You might have people who prefer activities or little more, you know, kind of quiet activities or some that are more verbal, you know, require more discussion. That's really an individual thing for your team. So I think you have to think as you go through this, what's going to work for these people, right? For this set of individuals that I am working with. You know, I always say there's kind of a first commandment for Scrum Masters, know thy team. And I think that's really something that's important for us to grasp onto is we have to know our team. can't coach to the average. Right? We have to coach to the individual, to what we have on our team, because your team is unique. That set of individuals has never come together anywhere else in the world. Right? Those personalities. And what you want is to find out how to make that set of people work well together. Right? How do they work best together? Not how does every other team in the world work best or how does the average team work best? How does your team work best? Right? So with all of this is sort of setting this and saying that there should be a pattern. I do want to give the hat tip here and say that the Esther Derby Dinah Larson book on retrospectives is one I strongly recommend. In fact, pretty much my whole career as a trainer, I have said, when people say if there's one book, if I'm to be a Scrum Master, if there's one book that you would say would be really impactful to me from pretty much day one, I have pointed to that book. It's called Agile Retrospectives, Esther Derby, Dinah Larson. And in that book, they lay out a pattern of kind of five phases that go through it. I'm going to distill it down because to me, it's sort of the three middle ones that are the most important. I will talk about the two on the ends here as well and kind of put that on top of these three. But sometimes I find people find it easier if they just remember what I'm gonna teach you here about the three that are in the middle. So in Scrum Master classes, we will talk often about how there's these three pillars of the Agile process or three pillars of empiricism. Empiricism says that we learn through experience. Well, I always say in class, it's not enough to just do the wrong thing over and over again. I gain a lot of experience by doing the wrong thing over and over, but I don't learn from it. And the three pillars are what's needed to make sure you learn from them. And I'm sure you've heard these before, but if you haven't, transparency, inspection, adaptation. Those are the three. Transparency meaning we're not going to be clouded about how we do the work. We're going to be very transparent, open about it. We're going to try to reveal how we work best as much as possible. Inspection, that we're going to actually take time and pause and try to figure out not just what happened, that would be transparency, right? What's the reality of what just happened? But inspecting says, why did this happen? Right? What's the root cause of it? I don't want to just deal with the symptoms, right? If we just try to cure the symptoms over and over again, we still have the same disease, we still have the same illness, and we're not really getting to the root cause. So inspection says, we're going to take time out to actually get to the root cause. And then adaptation, the last one, is probably the most important step here, because if you figure out what's wrong, but you don't ever do anything about it, well, we're doomed to have the same exact discussion again. So adaptation says, now that you know what the problem is, what are you going to try different? We may not even know exactly what the right thing to do is, but we got to try something. What we know for certain is what we did didn't work. That's the one thing we absolutely can't do again, is exactly what we did. We've got to try something new so that we move on, right? So that we find out more information and get closer to whatever our final solution is. So transparency, inspection, adaptation, those three actually serve as a good guideline or three phases you can think about for your retrospectives. There needs to be a transparency phase where you try to figure out what happened this last sprint. there needs to be an inspection phase where now that we know what happened, we got to ask the question, why did it happen? And we need to get to the root cause of why it happened. Now that we know what that is, then we have to move on to adaptation to say, what are we going to do about it? How are we going to take this knowledge we just gained and actually make a change? So we need activities around all three. And what I'm saying here to you is that can serve as your menu. I can do lots of different activities that would match these three areas. Now, I do, again, want to go back to the Esther Derby, Dinah Larson book, because their five phases adds one on the beginning, one on the end, which I actually do think are very helpful. The first one is kind of opening the retrospective. It's a way of trying to just start to get voices in the room. And this is something I will often do as well. Just a quick, quick exercise to just get people to start talking. And that's one of the ways you can start to get a quieter group to get involved is throw them something really easy to respond to right out of the gate. And then the last one is to close the retrospective. Closing the retrospective is a great way to then try to sum it all up and say, well, here's the takeaways, here's the things we're going to do about it, and we're going to move forward from here. Opening the retrospective to that introduction can also then review what you talked about at the end of the last. retrospective. You can say, here are the things that we decided, and let's talk about what's been done about them before you start to inspect the current retrospective. So given that, right, I know I'm going fast here, but you can rewind and listen back to this if you need to. But if you think about that, that you have these kind of phased approaches, and think of it like a menu, right? There's different courses to my menu. Well, I'm not going to serve the same meal every time. That would be boring. So I got to find out different things I can serve for each course of my retrospective. Now, here's where it gets interesting, right? Because there are lots of tools out there. And there's a website that I often recommend called RetroMAT. RetroMAT is a great site where you can go to, and it has those five phases. You can kind of scroll through different exercises for each of the five phases. they sort of have, you you can kind of mix and match and create your own menu based off of that. And doing that is absolutely free. Now they have paid things there as well. They're not a sponsor. I don't get any kickbacks or anything from them. But they have some paid activities as well as far as having things like Mural and Miro templates that you can use if you want to do that as well. So there's lots of things you can do there to thank them for what they put together. But there are times when Maybe you're trying to fit this to your team specifically, or you've grown tired of the exercises that you're used to, and you want to find some new dynamic to add into your retrospective. So what I'm going to do is kind of walk you through what I would do if I wanted to take some kind of a theme and create a new retrospective that's themed around a certain topic. Now I will say that this theme is gonna go just in one of our sections. So it's not going to go throughout it. I'm not gonna be that creative here with you on it, because I don't think you need to be. I don't think you need to have this, it's not like a theme to party, right? You can just take the theme and use it in one of the sections. So what would I do for something like this? Well, I'd start with, as I said, some way to kind of open the retrospective. And I like to have little quick activities as I said, that just get voices in the room. an example of things I've done in the past. Ask the team a quick question like, if this last sprint were a song title, what song title would you use to describe this last sprint? And people can use whatever kind of music they like, right? It doesn't matter. They can just call it any songs that they're familiar with. Or do movie titles. I've had a lot of fun in the past doing that with teams where I'll say, hey, shout out a movie title that might represent this last sprint. You just want to find something quick that people can shout out like one or two word answers, right? Or a small sentence in the case of a song title or movie title or something like that. But something that they can tie it into, right? And it doesn't have to be anything that makes perfect sense, right? It can be kind of crazy. It can be... You know, if this last sprint were a flavor of Starburst or, you know, an color, what color would it be and why? And just have people, you know, shout out whatever they think the answer would be. They might have to be a little creative with their answers when they do that. But that's okay. You're just giving them an opportunity to have a few voices start to enter the conversation. Don't force anyone, right? Don't force anyone to shout out, but give them an opportunity to. So I'm going to open the retrospective with some kind of fun, quick exercise like that. Probably won't take more than five minutes, okay? Then I want to move into that transparency section. And the way I frame transparency is what actually happened this last sprint? What was the reality of what happened this last sprint? So here's where I'm going to inject a themed kind of approach. And I just, I go through a couple of examples in our courses where I talk about doing this, but I picked a different one here for this podcast episode that I've put together right before this recording to try to walk you through a little bit of how I did this. So I tried to pick something that was a little more relevant to today. I know that this is popular and people are looking forward to the next season, which is about to come out. sometime soon, I know they've been shooting it, but I picked the theme, Stranger Things. And I just thought, what if my team, you know, had, I knew there were some people on my team really into Stranger Things, or what if I just knew they were aware of it, they knew what it was, and I wanted to have a theme built around this. So here's how easy it is to do this. I went to chat GPT, and I asked it to give me some, you know, putting together a retrospective that I want to theme it around stranger things. And give me some major themes from Stranger Things that might align to Some different ways of collecting information around what actually happened this last sprint. And. They gave me a long list of different things. And I read through these and kind of tweaked them, talked back and forth with it a little bit, kind of refined. And I distilled it down to five sort of themes or categories I thought would be fun and would kind of challenge the group to think along different lines of thought. So here's what I came up with with Chat GPT's help. My first category. I called running up that hill. And what I put for the prompt for this one is what felt like an uphill battle this sprint? Now just think about that, right? In traditional sprints, there's lots of things that are just, I'm essentially asking what was the obstacles? What were the hurdles in this sprint? But I'm getting them to think about it in little different way by saying, what was an uphill battle in this sprint? And even that subtle rewording, of that prompt can trigger people's brains to work in a different way and get them to think along different lines. If I just ask over and over again, you know, what was a blocker of this sprint or what blockers do we encounter this sprint? If I use those same words over and over, I get sort of immunized against them and I can't really think about anything new. But just phrasing it that little slightly different way, what felt like an uphill battle this sprint I think can really trigger some new ways of thinking. So that was my first category. The second one that I came up with, big theme here in Stranger Things, was the upside down. And I related it this way to say, what is completely upside down right now? What is the opposite of what it should be right now? Now here, I'm trying to get them to think about things that are not really going well, right? Things that are going the opposite direction that they should, and it's upside down from what should be the normal. Right? And again, we're just thinking along this theme of stranger things and I'm tricking their brains a little bit into thinking along a different line, right? To examine it from a different point of view. My third category that I thought would be fun was I titled Vecna's Curse. And what I prompted here for this one was what haunted the team this sprint or kept coming back up to bite us. And The idea here is to get them to think about things that were maybe decisions we wish we had made differently. These could have been decisions in the past. It didn't have to be a decision from this sprint. But what are those things that we felt kind of like was like Vecna's curse? It was just something that kept rearing its ugly head. And it was just a struggle for us to get around. My fourth one, just to have a little fun. I call the fourth one Surfer Boy Pizza. And what I put as a prompt on this one was, where did we bring the chill? Where did we bring the creative spin to a tough solution during the sprint? So here I'm wanting to celebrate good things, right? And I'm asking that in a funny way. So it brings some humor to it, puts them in a better mood, and also gets them to think along a maybe a little bit of a different line in this area to think, all right, well, what do we get really creative about? What do we have to be really creative about in this sprint? What kind of tough solutions did we really conquer? Did we really nail in this sprint? And I'm just theming around that loose theme of that surfer boy pizza from the last season. And then the last one, I couldn't have categories here without mentioning Hellfire Club. So the last one was Hellfire Club. And the prompt I put for it was, where could we bring more of kind of that Hellfire Club vibe, planning, teamwork, shared adventure, right? Just the fun. Where could we put more of that vibe into our team and to how we operate? Now, this is getting them to think about something that might otherwise be a little bit of a uncomfortable thing to think about, right? Because Now we're getting into interpersonal dynamics. We're getting into how the team actually works and fits together. And that's why I chose this theme, because I wanted it to be just kind of a, even maybe a sneaky back doorway of getting their brains to start to examine, yeah, what would have made this more fun? Or what would have made this, how could we have, I've asked often in retrospectives, what would it take for us to be the team that everyone else wishes they were on? Well, That's what I'm asking here, essentially. So I've got my five themes. And I even then went forward and created and kind of get some images for each one of those, like icons for each one of those things. Just created a board and mural for this and put each of those things up. Had a big block space next to each one where people could put Post-it notes. So what I would do here in the retrospective is I'd introduce this. I'd give them the prompts for each of the section and say, all right, let's take a few minutes. Everyone can add Post-its to any of these sections, but try to think through several of them and put several of them up here on the screen or physical board if we're in the same space. But take a few moments here to think through each category and see if there's anything that you can think of that you would add to each area. So we take, I don't know, five, 10 minutes to do that. normally time that, I just see when it starts to slow down. And there's generally a point there where you can kind of intuitively feel it and feel like, you know, the group's ready to move on. So whenever that time comes, I'll call a halt to it and I'll say, all right, now that we've done this, I want us to try to narrow down what's on the board. So let's give you each three votes. And I do this usually with dot voting or something along that line. where they have three dots they can place on three different sticky notes across all five categories. And what I tell them is find the three that are the most important of all the things here, what are the three that are most important and put your vote on those top three. And by doing this, having the team vote on it, then we surface the most important three out of the entire group, right? It's not to say we ignore the others, but we're going to try, we can't focus on everything in our time that we have. So, whether our top three, and then I start with the first one, right? So right now, all we've done is kind of the introduction of the sprint. We've done a transparency section. Now we move into the inspection. Now there's lots of different things you can do here, but what I put together for this retrospective was taking them through sort of a five whys activity. So I would take that first one, I'd have them examine it and look at it and say, all right, let's ask the question why five times for this one. Why did this happen? whatever they answer, then we say, all right, well, why did that happen then? And we ask why, it doesn't have to technically be five times, but you need to ask it enough to where you get down to something that you can say, yeah, that's definitely the root cause, right? That's what's underneath all this. All that followed it, all that came afterwards was all stuff that came as a result of us making that decision. So once we have our root cause, we can repeat that again for the other two. if we have time, but if we're starting to run out of time, I kind of watch my time box there. And once I realize we need to move into solutioning, then we'll move on into the adaptation portion. In adaptation, we just take each single one, and we kind of repeat this process of getting possible answers across the team. So for the number one issue that you guys identified, here's our root cause. Let's take some post-its here. or let's take some suggestions of what we might possibly do to counteract this in the next sprint. So we get those things that come up. Then we'll talk through each one, and we'll try to build consensus as a team as to the most important step to take. So for each item, I want what's the one most important thing to do. So we'll identify that, again, as time allows, I want to at least do the most important thing. If we have time for more than that, great, we'll get to the second and third. But I think it's so important to just, whatever the biggest, most important thing is, make sure you have an action item for that thing. And here's where I just caution you. It doesn't have to be, hey, we've knocked it out. We've cleared it. We've solved it in the next sprint. It just has to be that we've taken a step towards solving it, right? What's the old phrase, a journey of a thousand miles starts with a single step. Well, the same thing goes for our teams. And this is oftentimes why teams get stuck, is they just feel paralyzed. Hey, there's nothing we can do about this. It's such a huge issue. Well, that's not true. What's the next step you can take? So take the next step. Make sure that the team understands what it is. And make sure we understand who is going to be responsible for that. And do that for as many as you can get through. Then get to the closing the retrospective part of it. Kind of wrap up. Remind them, here's the journey we've taken, here's what we've uncovered, and here's what we're gonna do differently for next time. And now those items, they should go straight into your next sprint backlog, not product backlog, sprint backlog, right? They don't need to be prioritized because the product owner has been with you, they should have been with you in this meeting, it's the entire Scrum team. So the product owner has weighed in as well. This has been a team collective decision. So now those items should go into your sprint backlog, and you should do something about them in this next sprint. That's the whole concept of the Kaizen comes first, right? The good change should happen before we do anything else so we can get the benefit of it over a longer period of time. So that's kind of the idea here. And I wanted to give you that kind of really quick flyby to help you kind of see how to go about doing something like this, right? And I just picked one theme. I just picked Stranger Things because I thought it would be fun to work on. I thought it would be a fun kind of theme. And it might be fun for a team I was working with. But maybe that's not something that aligns to your team. Maybe your team has a bunch of people who are really into cricket. Well, do a cricket-themed one. Maybe you have a team that's around the Academy Awards time. And everyone's talking about, and now people don't do this as much anymore, but. Maybe they're all talking about who's going to Oscars this year or something. Well, do an Oscar-themed one. Or it can be around anything. Do it around award shows in general. It doesn't have to be just Oscars, but do it around any kind of award show. And you can pick up different themes. Again, if you're stuck, ask your favorite large language model and see what it comes up with. It's not all going to be gems that comes from that, but you can pick and choose and refine it, which is exactly what I did with my five themes for this. So I hope you see how easy it is to do that. It doesn't have to be complicated. You don't have to be extremely creative to do this. You can make use of the tools that you have available to you. And as a Scrum Master, you can keep this fresh. You can tailor this to the team that you have. What is your team really into? What's the theme that they would really resonate with? Choose that. Go with that. Create a theme around that and see what they think about it. Afterwards, ask them, hey, did this work all right? Did you like this? I hope that's been useful to you. If you like this and you want to hear more like this, come to our website to mountngoatsoftware.com and check out our courses that we're launching actually this week, Better Retrospectives and the Retrospective Repair Guide. Those are the two that we really want to have you kind of think about. Come to our site, find out more about them. Better Retrospectives is all about just the expert level retrospectives course really gets into the heart of a lot of these issues at a very, very deep level. The retrospectives repair guide is taking the 10 most asked questions that we have about retrospectives at Mountain Goat Software and giving you really deep dives on how to solution those, how to problem solve those top 10 issues. And the great news for you is if you're listening to this in real time, right, when we've launched this, We're launching this as a two-for-one special. We'll not have that special again. So it's $99 that you get both of those courses. You don't have to pick and choose from them. You can give $99. They're prerecorded. You can watch them at your own pace. This is for people who want this knowledge, who want these answers. And I know when I was a Scrum Master starting out, there was a lot of, I followed a kind of the pattern that Mike established with his sprint repair guide. I bought that when I was coming up as a scrum master because I needed answers to some of the questions that he had in that scrum repair guide. Well, take a look at the 10 that we have for our retrospective repair guide. Maybe you'll find one of those things that's really tripping you up and maybe just getting the answer to one of those is going to be worth the money for you. I encourage you to go to our site, check it out. Don't miss this. It's a limited time cart that's opened. It's only going to be open for a week. So if you're listening to this when we launch it, don't delay, don't wait until next week. If you hear this next week, then you're running out of time. So make sure that you take advantage of the time that you have here so that you can get these two courses, two for the price of one here at our launch. Again, we won't do that again. So I hope you found this to be useful. It's just a little taste of the kind of thing that's in those courses for you. And if retrospectives are something that you're struggling with, or if retrospectives are something that you just feel like, man, it really could be more. It really could deliver more for my team. Check out these two courses. I really think they're gonna help a lot of teams out there. That's why we put them together. So that'll wrap it up. I hope you've enjoyed this and we'll talk to you next time. on another episode of the Agile Mentors Podcast.

  --------  

  30:20
• #140: The Power of Emotional Delight in Product Design with Dr. Nesrine Changuel

  What do Spotify, Google Meet, and your expense report tool have in common? They could all delight your users—if you design for more than just function. In this episode, Dr. Nesrine Changuel breaks down the emotional motivators that transform average products into unforgettable ones. Overview What separates a good product from a great one? According to Dr. Nesrine Changuel, it's not just meeting functional needs—it's creating emotional delight. In this episode of the Agile Mentors Podcast, Brian Milner sits down with Nesrine, a former product leader at Google, Spotify, and Microsoft, to explore how emotional connection is the secret sauce behind the world’s most beloved products. They dive into Nesrine’s “Delight Framework,” reveal how seemingly mundane tools (like time-tracking software or toothbrush apps!) can create joy, and explain why delight isn’t a nice-to-have—it’s a competitive edge. Whether you're a product owner, product manager, or just want to build better user experiences, this episode will change how you think about your backlog forever. References and resources mentioned in the show: Dr. Nesrine Changuel Product Delight by Dr. Nesrine Changuel Blog: What is a Product? by Mike Cohn #116: Turning Weird User Actions into Big Wins with Gojko Adzic #124: How to Avoid Common Product Team Pitfalls with David Pereira Join the Agile Mentors Community 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 [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and 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. Dr. Nesrine Changuel is a product coach, advisor, and speaker with over a decade of senior product management experience at Google, Spotify, and Microsoft, where she led major consumer products like Chrome, Meet, Spotify, and Skype. She holds a Master’s in Electrical Engineering and a PhD in Media Processing and Telecommunications and is based in Paris. Auto-generated Transcript: Brian Milner (00:00) Welcome back Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always Brian Milner and today I have a very special guest with me. I have Dr. Nesrine Changuel with me. Welcome in Nesrine. Nesrine (00:14) Hi, Brian. Thanks for having me. Brian Milner (00:16) I'm very excited to have Nesreen with us. I think this is going to be a really, really great episode for all of you product owners out there or product specialists, anybody who works in the product area. I think you're going to find this really interesting and you're going to want to bookmark this one. Maybe even come back to this a little bit. Nesreen is a coach, a speaker, particularly in the product area. She has previously worked at Google. She's worked at Spotify, at Microsoft, so no stranger to large enterprise, very high profile products that she's worked on in the past. She has a book coming out in May, so look for this book. It's called Product Delight. And that's really what we're going to be focusing on here is the concept of eliciting or generating kind of an emotional response to our product. I guess I'll start by, did you stumble upon this? What drew your interest to people's emotional response to products? Nesrine (01:19) Yes, so maybe I can share the story how I came to this topic and how I became so vocal about it. So in addition to being a product manager and leader over the last decade, I was always and I always enjoyed being a speaker. So I always wanted to go on stage and share insight. This is probably coming from my research background, because when I used to be a researcher, I traveled the world to go and present my research work and When I became a product manager, I kept this habit with me. So I always been on stage and I spoke about different topics like product discovery, product operation, different topics. Until one day I got reached out by a conference organizer and he said, Hey, Nisri, we want you on stage, but we have an idea for a topic for you. I'm not that used. Usually I come up with idea myself, but I said, okay, what do want me to talk about? And he said, Hey, Nusreen, you have been working for Spotify, for Microsoft, for Google Chrome and Google Meet, and we all admire those products and we consider them very successful products. What if you come and tell us what's the common thing that probably is there any common thing that made those products successful? Being an insider, being within those company, could you share with us something that you consider in common between those products? To be honest with you, I found it challenging at the same time interesting as an exercise. I was not, by the way, able at that time to answer the question, what's in common? So I sat down and I did the exercise myself and I started to think what was really in common? What made Skype Skype? What made Spotify Spotify and those Google products so successful? And I came to the following conclusion. I found that what made those products so successful is that they don't only solve for functional needs, but they also solve for emotional needs. So when we use a particular product, we use it for a certain functional need, but we also use it for an emotional need. And without even knowing that I have been doing it for more than 12 years, I came to the conclusion that, my God, during all those years, I have been focusing so much into users need from both angle, functional and emotional. So I came on stage and I spoke about that topic and from that day, I started to give it a name. I'm calling it emotional connection. I'm calling it product delight. And I'm here to share more about it as well. Brian Milner (03:50) That's awesome, yeah. I mean, I think we do hear a lot and we focus a lot on that functional kind of need, the way you differentiate there. think that's a good differentiation, functional and emotional kind of needs or motivators there. yeah, I mean, I've always heard, know, kind of that kind of general product advice is, you know, find the things that... people really, really have as huge needs, the things they would pay someone to do for them. And that's the key to success is finding those huge needs. But we're actually going beyond that to say, yeah, those are important. It's not to say that we should skip that, but it's when there's the emotional connection to a feature or to something that we do that really the light bulb kind of comes on for our customers. Is that kind of what your research is leading to? Nesrine (04:40) you're getting it right. Don't get me wrong. Of course you have to honor the functional needs and serve the functional feature, but the delight or the emotional connection happens when you go beyond exactly how you said it. Let me explain. If you serve only functional needs, you know what you get? You get satisfied users because they are asking for something and they are satisfied about what they are receiving. Now, Brian Milner (04:41) Okay, okay. Haha. Nesrine (05:05) If you surprise them by going beyond, by anticipating their need, by exceeding their expectation, you're not only satisfying them, you're surprising them in a positive way and delight is the combination of surprise and joy. Actually, the theoretical definition of delight is a combination of two emotions, surprise and joy. So going beyond, anticipate need and exceed expectation. is what we should aim for in addition to the functional needs. Brian Milner (05:35) That's awesome. Yeah, I use this example sometimes in, we use this example in the agile world to talk about, you know, the part of the agile manifesto that says customer collaboration over contract negotiation. And, you know, there's an example I use from my past where I used to work at a company that was very contract driven. And, you know, the thing that I always used to kind of take away from that was the very best we could ever do or hope to do. was to meet our customers' expectations. We could never, ever exceed it because we were only doing exactly what they told us to do. So I think this is a really important distinction here to make that just meeting the customer's needs, just meeting the minimal customer satisfaction bar, that's not going to keep you with loyal customers. That's not going to have repeat customers, or they're not going to tell their friends about, you know. That product did exactly what I hoped it would do. But it didn't really surprise me. It didn't really go beyond that. I know you talked about, because I've read your blog and a little bit of the discussion about this. So I know you talk about in the blog kind of the connection to Kano analysis. And I've always thought that's a really great way to try to determine things to target and go after. So talk to us a little bit about that, about Kano analysis and kind of what that uncovers and how that connects to what your research has shown. Nesrine (06:51) Yes. I love Kano by the way. I, I mean, that's one of the framework I have been considering throughout most of my product career. But this framework comes with a limitation and let me explain. So first of all, for those who are not very familiar with Kano, Kano is a visualization or categorization, let's call it. It's a categorization framework that allows to categorize features among different categories. One of them is must have. So these are the things that absolutely have to be in the product. Other that are performances, which are the more you have, the more satisfied users are, the less they less satisfied they are. And of course there are the delighters and delighters are those feature that when they are in the product, users are surprisingly happy. And when they are not, are not even the satisfaction is not even impacted. So the limitation of Kano is that it doesn't tell you how to achieve delight. Let me explain. I think we live in a world that everyone agree that we should delight our users. I mean, this, this concept is now globalized and everyone is talking about delighting users. The issue is that we don't know how to delight them. So we know category, there's a category that called delight, but we don't know how to. So the, the framework that I'm introducing and I'm calling it the delight framework is the framework that allows to first identify. So it's usually, represented into three steps. The first step is to start by identifying the emotional and functional motivators. So let me give you an example. I've been working at Spotify for about four years and as a Spotify user, imagine yourself, you are a Spotify user. You do have, of course, functional motivators. What could be the functional motivators? Listening to music, listening to podcasts, maybe listening to an audiobook. So all those are functional motivators. Now, what could be the emotional motivators as a Spotify user? It could be feeling less lonely. It could be feeling more productive because when you're working you need to listen to something. It could be about changing your mood. It could be about feeling connected. So all those are emotional motivators that drive users to use a product like Spotify. So what I encourage every product manager or every product team to do at first is to dig into identifying, of course, the functional need. And everyone is good, by the way, in identifying the functional needs. But also, while doing that exercise, pay attention to what could be the emotional motivators. So that's step number one is about listing the functional and the emotional motivators. Once you have those, Now we get to the second part of the framework, which is look at your backlog. And I guess you have a very busy backlog and take those features one by one and see for this particular feature, which motivator am I solving for among the functional ones and among the emotional ones as well. So the delight grid, for example, is a visualization tool that I came and created in order to allow product teams to visualize their backlog and see how many of my features are only solving for functional motivators. In that case, we call that category low delight. How many of my features are only solving for emotional motivators? These are very rare, but the best example I would call is, for example, I'm having an Apple watch and one month ago it was New Year Eve and at midnight I get fireworks popping out of my Brian Milner (10:35) Ha Nesrine (10:36) Apple watch and it was a happy new year there's nothing functional in there but it's all about creating some smile I call this surface delight and then how many of your features are solving for both functional and emotional motivators and I call this deep delight so maybe I deviated a bit from your question compared to canoe but it's actually about adding this dimension of connecting features to the real motivators of the users. Brian Milner (11:07) No, maybe a little bit, but you connected it to where we end up going anyway. So I think that's a great connection there. And by the way, for anyone listening, we'll link to all of this so that you can find this and follow up. But I like that differentiation between surface delight and deep delight. I know some of the examples that I've heard used kind of frequently in looking at Kano analysis and kind of trying to find those delighters. And that is kind of the area that it specifies there in Canoe, right? You're trying to find those things that are not expected, but when people find that they're there, they like that it's there, but they don't expect it's there. So if it's not there, there's no negative response that it's not there, but there's a positive response if it's there because they like seeing it. And my boss, Mike Cohn, tells this story about this Nesrine (11:59) Yes. Brian Milner (12:03) There's a hotel in California that became famous because at the pool, they have a phone that's by the pool that's the Popsicle Hotline. And you can pick up the phone and you can order a Popsicle to be brought to the pool. And it's the kind of thing where you're not going to go search for a hotel. Does this hotel have a Popsicle Hotline? I'm only going to stay at hotels with Popsicle Hotlines. It's not that kind of a normal feature. It's a delight feature because when you see it and you find out it's there, it's like, that's really cool. And it can be the kind of thing that says, yeah, I want to search that hotel out again next time I'm in this area because I really thought that was a nice little attention to detail and it was fun. But I think what I'm hearing from you is that might be more of what we would classify as a surface delight. It's not really meeting a deep need. Nesrine (12:35) Yes. Brian Milner (12:56) But it's fun, it's exciting, it's not expected, but it doesn't really cross that threshold into, but it also meets kind of functional delights. Is that kind of what you're saying there? Okay. Okay. Nesrine (13:08) Yes, actually I heard about that hotel story just to tell you how much viral it went. It came to me. So actually you get it correct that I consider that as surface delight and I have nothing against by the way, surface delight. You can add surface delight. The issue is you can end up doing only surface delight and that's not enough. So the idea is to do a combination and I do have two stories to share with you just to compliment on this hotel story. One is personal and one is professional. Brian Milner (13:21) Yeah. Okay. Nesrine (13:37) The personal one just happened to me a month ago. I went to Sweden and I went to Stockholm. That's where I worked for eight years. And I went there for business and I decided to meet some friends and some ex-colleagues. So we all gathered and went to a restaurant, a very nice restaurant in Sweden. And came the time where we had to say goodbye and to pay. And I guess you can feel it immediately when it's about paying and we are a large group and you start to get that anxiety about who's paying what and what did I order? What did I drink? What? I mean, I honestly hate that moment, especially in a large group where you don't necessarily have a lot of affinity with us. Like, should we split in 10? Should we pay each one paying its piece anyway? So that was a moment of frustration, of anxiety. Brian Milner (14:09) right. Yeah. Nesrine (14:28) And I loved how the restaurant solved it for it. You know how they solve for it? I mean, maybe it exists in the U.S., but for me, that's something I never seen before. The waiter came with a QR code on a piece of paper and you scan the QR code. And when you scan your QR code, you get the list of items that got purchased by the table. And all you have is to pick, and that happens automatically real time. Everyone is picking at the same time. You pick the things from the list and you pay. for the things that you order. You can even tip on the bottom. You can give feedback. Everything happened on that QR code. And you can guess how much that anxiety could be removed. So that's the personal story I wanted to share. The second story, which is more professional, I want to share how we try to improve experience at Google Chrome. So I've been the product manager at Google Chrome. Brian Milner (15:13) Yeah. Nesrine (15:25) And we started from the observation that people do have plenty of open tabs. I guess you are one of them, especially on mobile. Like on mobile, you go and check how many open tabs you do have on Chrome and you realize that they are have, we realized at least out of numbers, out of data that people do have plenty of open tabs. So it started as Brian Milner (15:32) You Nesrine (15:47) technical issue. Of course, the more tab you have, the heavier the app is, the slower the app could be, et cetera. So we wanted to reduce the number of unnecessary open tabs in Chrome. So we interviewed users and we started to check with them, why do they even leave their tabs open? So some of them leave tabs because they consider them as a reminder. I mean, if tab is open, it means that you need to finish a task there. Some people really leave tabs just for ignorance. mean, they moved from a tab to another and they completely forget about them. Actually, we realized that the fact of leaving tab open, the reason for leaving tab could be completely different from a person to another. And the other interesting observation, and when I say identify emotional motivators, you will realize that people feel a bit ashamed when they show to us that they do have plenty of open tabs. Some of them would say, sorry, I usually don't even have so many open tabs. It's only now. And I'm like, it's okay. But the point is, if you have this mindset of trying to track the emotional insight from your users, you will take note. And the note was anxiety, feeling ashamed, blah, blah, blah, blah, blah. And that was in introduction for in... Brian Milner (16:42) You Yeah, right. Nesrine (17:04) improving the tab management experience later on in Chrome. Brian Milner (17:07) That's actually a really good parallel, though. I think that's a good example because it reminds me, too, even going back, I remember one of the things, and I'm going way back here, but I remember one of the things about Gmail that was kind of a selling point initially was the concept there of you don't have to worry about maintaining an inbox. keep all your mails and search. And you can search through your mails and find whatever it is. And I remember prior to that, most people would use something like Outlook or something like that to have their mail, there was always this constant struggle of, I've got to keep it down. I've got to delete things. I've got to categorize things. And Google had this different approach of, don't worry about it. Just leave it. And that's a good, I think, example as well of kind of that emotional response of, Nesrine (17:48) Yes. Brian Milner (17:56) Gosh, I'm kind of anxious. I feel bad that my inbox is so big. And I know that's bad, but Google comes along and says, don't worry about it. You're not bad. It's OK. Yeah. Nesrine (18:05) Yeah, yeah. And by the way, I think Gmail is filled with plenty of deep delight features. One of them I can quickly highlight is, you know, when you send an email, we're saying attached file and the file is not there. And when you try to hit send, you get that pop up like a be careful or like a mind, there is no attached file inside. These are for me like very attached to the fact that You don't want to feel ashamed. You don't want to look stupid later on saying, Hey, sorry, I forgot the file. Here's the file. That's, that's a great example. And the other example that come to mind again in Gmail, you know, that smart compose when you're trying to answer an email and you can just hit tab, tab, tab to complete the sentence. I mean, the functional need is to write an email. The emotional need is to get it in a relaxed way. And the combination would allow for something like. Brian Milner (18:49) Yeah. Nesrine (19:00) Smart Compose. Brian Milner (19:01) That's awesome. Yeah, so I guess that leads to the question though, when we're talking about something like Spotify, mean, music intrinsically is emotional anyway, right? It's something that you have an emotional connection to and you feel a certain way when you hear music. But if my product is a, I don't know, expense reporting software, right? Nesrine (19:23) Mm-hmm. Brian Milner (19:25) I can just hear people out there kind of asking, know, and kind of thinking to themselves, yeah, but my product, right, my product is not that kind of, it doesn't elicit that kind of emotional response in people the same way music would. So does this apply to me as well? So how would you answer those people who feel like my products might be a little bit more bland or boring and don't really intrinsically have an emotional connection to them? Nesrine (19:47) Mm-hmm. So my answer is that if your product is boring, then it's even more priority now to focus on emotional connection. But let me elaborate. So that's one of the reflections that came to my mind while writing the book. So while writing the book, I wanted the book to be a storytelling book. So I was writing a lot of my stories, stories from Skype at the time, Spotify and all the Google product. But at some point I said, hey, hey, Nisreen, you need to get more insight from other people and other experiences. So I get to interview product leaders from completely different industries and completely different domain. I interviewed leaders from B2B like Atlassian or Intuit and so many other companies that I don't have so much insight from. I even interviewed people from hardware, like I interviewed someone from Dyson and I was, hey, what makes Dyson so emotionally attractive for me? Cause I love my Dyson vacuum cleaner. But let me get to your point because when I interviewed someone from Intuit, that person told me something super interesting. She told me that at some point she was working at a tool called Tsheet. And Tsheet is a tool that allows you to enter your time report. There is nothing more boring than that. I think I'm picking the one that you're looking for here because it's, it's as a user. The only reason I would use this tool is to report my time so I can get paid. Brian Milner (21:06) Hmm. Right. Yeah. Nesrine (21:19) There is nothing exciting, nothing emotional. And what I got out of that product leader who used to be the head of product at the time, she told me that they were completely aware about the fact that the product is not that attractive. And instead of living with that observation, they did all what they could do to make it even more attractive. So they added some fun. They made the messaging less aggressive and less about enter your time. report but rather into more playful and even the images are more playful. When you press the enter time report you get the congratulation and some confetti if needed. So they explicitly turned and that's a strategy. They turned that boring moment into something even more attractive and they had to do that otherwise the experience will keep on becoming more more boring and the perception of users toward the product will be even less, more and more gray, I would say. Brian Milner (22:22) Yeah, yeah, just that little dopamine kind of kick, right? Just that little bit of chemical reaction in your brain can make a huge difference. That's awesome. That's a great story and a great answer to that question. So I'm curious, we're talking about trying to find these things and trying to see, your matrix here, it thinks about the emotional motivators, the functional motivators, and trying to find those things that kind of cross both planes. Nesrine (22:24) Yep. Brian Milner (22:52) How do you verify at the end? Because if you're lining your features up and think, I think this solves this emotional thing. I think this solves this functional thing. Is there a way to follow up to ensure that it actually is doing that? How do you follow up to make sure it's really doing what you thought it would do? Nesrine (23:09) Yes, so let's imagine you did the exercise well, you filled in the delight grade and you observed that you do have plenty of low delights, which is most of the cases by the way. The very first thing I recommend is to see opportunities for moving or transforming these features into deep delight. And in the book, for example, I talk about the nine delighters. Nine delighters are ways that could be sometimes cheap even to introduce. in order to make those low delight features into more deep delight. This could be, for example, through personalization. We love when the features are personalized, and that's one of the reasons, for example, why Spotify is so successful, is through features like Discover Weekly or RAPT or these kinds of super personalization related features. It could be through seasonality. That's, for me, the cheapest and the most delightful feature you can or aspect of feature you can add to your product. So for example, when I worked at Google Meet, I've been working at the background replace features. So we have been, of course, introducing static image. We have been introducing video backgrounds as well. But from time to time, we always use seasonality to introduce what we call seasonal background. So when it's Easter, we introduce Easter background. When it's Christmas, we introduce Christmas background. Guess what? Even like for Olympic game, we introduce Olympic game background. When it's the Earth Day, we introduced Earth Day background. So there is always an opportunity to introduce some seasonality to the product. And guess what? We relate to those, especially if the product is global. We relate like last, when was it? Like last Wednesday. It was the new year, the Chinese new year. And I was checking when is exactly the exact date for the new year, the Chinese new day. And I put that and you know what happened in Chrome? It got these dragons and those like the celebration within the product, like within Chrome. These of course are surface delight, but you know what? Why not? You see? So there are some tools. Some of them are not that... Brian Milner (25:17) Right. Nesrine (25:22) expensive to introduce to the product. Some would require a bit more thoughtful and thought into it, but there are ways that I detail in the book in order to introduce more delight. And then if you want to validate through metrics, and I guess that's your question where it's heading to, then the good news, and that's something that I discovered recently because there's been a study that was conducted by McKinsey. And you know what they studied? They studied the impact of emotional connection on product adoption. So they actually studied over, I don't know how many industries die, like tourism, IT, energy, whatever. And they interviewed more than 100,000 users or whatever. So the conclusion that they found out of that very interesting study is that emotionally connected users will get you more twice as more revenue, twice as more referral, and twice as more retention compared to satisfied users. I'm not talking about the non-satisfied. So if you take two groups of users, those that you satisfy their needs and those that you go beyond and they are emotionally connected, those that are emotionally connected get you twice revenue, referral and retention. Brian Milner (26:19) Hmm. Nesrine (26:43) So this is just to highlight that for people who say, no, but this is the cherry on the top. This is just like the extra. It's not the extra, it's the way to stand out. I don't know any company that is standing out nowadays without investing into emotional connection, none. Brian Milner (26:54) Yeah. That's a really good point. Yeah, I mean, the example that comes to my mind when you talked about seasonality and other things like that, know, I love my, you know, they're not a sponsor, Oral-B toothbrush, you know, the electronic toothbrush, and you know, there's an app with it and it keeps track of, you know, did you get all the areas of your teeth and did you hold it there long enough and... One of the things I always love about it is when it gets to December, the opening screen when you open up the app starts having snowfall. It's kind of a funny little emotional response, but you look at that and you think, that's cool. Yeah, it is kind of that season where now it's time to get ready for Christmas and it's that special. It's only this month that it's going to be like that. It's going to go away at the end of the month. Nesrine (27:45) Yes. Brian Milner (27:49) feel little sad when it's gone, it's back to normal. But it's such a silly little thing. Does that make any difference in really brushing my teeth at all? Does it change how well I brush my Not really. It's just a fun little thing that when it pops up there. And think how little that took from someone to do that. It's a little animation that they just pop up on a loading screen. But that little tiny bit, think, again, maybe a little bit surface. Nesrine (28:10) Yes. Brian Milner (28:16) but it takes something that would have been routine. It takes something that would have been kind of boring otherwise, and it just added a little bit of fun to it, you know? And I think you're right, that emotional connection is really, really important in situations like that, yeah. Nesrine (28:21) Yes. Yes. Yes, yeah. And the thing that I'm very vocal about nowadays is the fact that this emotional connection is actually not a new topic. It's something that has been extremely popular among marketers. For example, if you think about the best marketing campaign, they are all very emotional. The most successful marketing campaign are. If you think about designers, there are plenty of resources about emotional design. There is a great book by Don Norman. It was called emotional design. Aaron Walter as well wrote something called Designing for Emotion. But you know, the problem is that among engineers and among product manager, we don't talk that much about that. And you know what happened when we are not informed about this topic? There is a gap between the language of marketers, designers, and the engineers and product manager. And that gap doesn't allow things to succeed. I'm trying to educate the engineers and the product world towards this well-known domain outside of the product in order to have this consistency and start making real impactful products. Brian Milner (29:40) Yeah, yeah, this is such a really deep topic and it just encourages me, think, even more to recommend the book there. It's not out yet, time of this recording it's not out, but it's going to be in May of 2025. That's when this book is coming out. And I know it's gonna have a lot of really good information in it. Again, the book is gonna be called Product Delight. by Nesrine Changuel, Dr. Nesrine Changuel. I should make sure I say that. But I really appreciate you coming on because this is fascinating stuff. And I think the product managers, the product owners that are listening here are going to find this really fascinating. So I appreciate you sharing your time and your insights with us, Nesrine. Nesrine (30:26) Thank you, it's my pleasure. I love talking about this topic. Brian Milner (30:29) Ha

  --------  

  36:15
• #139: The Retrospective Reset with Cort Sharp

  Retrospectives shouldn’t suck the energy out of your team—or get skipped entirely. In this episode, Brian and Cort share how to fix the most common retro fails and announce two brand-new tools to help you run retros that actually work. Overview In this episode of the Agile Mentors Podcast, Brian Milner and Cort Sharp break down why retrospectives are more than just a “Scrum box to check.” They’re the powerhouse behind continuous team improvement. From battling retro fatigue and quiet-room energy to creating psychologically safe environments and tying retrospectives to real results, they cover it all. Plus, Brian reveals the launch of two new on-demand courses—Better Retrospectives and The Retrospectives Repair Guide—designed to help teams stop skipping and start optimizing their retros. Whether you're a Scrum Master, coach, or facilitator, this episode is your practical guide to making retrospectives worth everyone’s time again. References and resources mentioned in the show: Cort Sharp Blog: Retrospectives With a Quiet Team Blog: Does a Scrum Team Need a Retrospective Every Sprint Mike Cohn’s Better User Stories Course Scrum Repair Guide 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 [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and 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. Welcome back for another episode of Agile Mentors podcast. I'm with you as always, Brian Milner, but today we're gonna have a continuation of something we tried, a little experiment we tried a few weeks back here. I've got Mr. Court Sharp back with us. Welcome back in court. Cort Sharp (00:18) Hey, Brian, thanks for having me on again. I had lot of fun last time I was on here and it was a great discussion. So thanks for bringing me back. Brian Milner (00:21) Yeah. Yeah, it's, oh, absolutely. Yeah, know, got a lot of people said, hey, we kind of like that court guy. Kind of like hearing from court. So we wanted to have court back, you know, because you guys told us that you liked him. And we also wanted to have him back because we just thought this format kind of worked for various reasons. And last time we kind of hit on some things that were kind of more hot button issues of the day. things that have been flowing through social media or other things around Agile. But we wanted to have a little bit more of a focus for today's episode. And we're going to focus really on the topic of retrospectives. And maybe make a little announcement here along the way as we go along. But we're actually going to switch roles here a little bit. I'm going to kind of pass the ball over to Court. And I'm going let Court drive this, just like he did in the last episode. Ball's in your court. Ha ha, get it? Cort Sharp (01:18) Ha ha, court, there you go. Well thanks, Brian. Once again, I love coming on here, I love chatting with you. And like you said, yeah, we're gonna be talking about retrospectives today, mostly because I have been struggling with answering questions about retrospectives. I think this is one of the more common meetings within Scrum that just gets skipped over, just people don't find value in it. Brian Milner (01:42) Yeah. Cort Sharp (01:43) or people just struggle with understanding why we have retrospectives. And sometimes I get a little slipped up and I struggle with answering the questions about why do we do this? So can you give me some clarification? Why do we have retrospectives? Why do they matter? Brian Milner (01:58) Yeah. Yeah. I mean, it's a great question. And I think everyone should, should, you know, want to know that answer. If you're doing this, you one of things I say in class all the time is, you know, it's important to know the purpose behind the meetings that we have in scrum. If you don't know the purpose, then, you know, that, how are we gonna, how are we gonna have a successful meeting? How are we gonna get the most out of it? so yeah, it's, it's a funny kind of meeting, because all the other meetings and scrum are, are really, around one ultimate purpose and that's building the increment. This is not, right? This is sort of a timeout. It's an intentional kind of timeout to step away and say, all right, now that we've done that, how did it go? What kind of happened along the way? I think it's a vitally important meeting. And when I hear people sometimes say, is it okay to skip it or should we do it once ever so often? you know, again, I try to be pragmatic and say, you know, I don't, I don't know any possible situation out there, but, you know, I would tell you, I would advise you not to, I don't think that's the right path to go. I know scrum doesn't teach to do that. I think it's really, really important because it is that, that moment of let's pause for a little bit. Let's figure out what we need to do differently and then let's actually take a step to do it. There's actually an interesting little background for this. So I'm going to take a little side trip here. Retrospectives actually come from an idea that has been around for a while that actually started kind of in lean manufacturing, some of the things that came out of Japan. There was actually a phrase that they would use on the assembly line at the auto assembly plants there in Japan. They referred to this concept of Kaizen. Kaizen was kind of a, I don't speak Japanese, but what I understand is the word loosely kind of translates to good change. And they had this concept there on the assembly line floor that anyone who was on the floor had access to the big red button that could stop the entire thing. They could stop the entire assembly line, which you know, on an auto assembly plant, that's a huge deal to stop the entire production. And they were very deliberate about it and said, no, we want everyone to have access to that because the phrase they use was the Kaizen comes first. And what they instructed the employees was if you along the way, as you're doing your job, if you see something that we could change that would make it more efficient, that would be a better way of doing this, then we want you to hit the red button because we want to implement whatever that change is as soon as possible. The sooner we implement the change, the longer we have as a benefit, like an investment. The earlier I invest, the more I get as a return. So the same thing here, the earlier I invest in this good change, the longer I have to have a return from it. So that phrase, the Kaizen comes first, is sort of a central thing that we think about here with retrospectives. It's identifying those good changes. there's actually even an intention behind it that it doesn't go on the product backlog. It goes in the next sprint backlog. Because we don't want to have any even inkling of deprioritizing something that comes out of a retrospective. It's that Kaizen portion. So we want to make sure that comes first. So yeah, it absolutely is going to go into the next sprint. Whatever we decide is the most important thing, we're going to make an impact on it in the next sprint. So that's why I think that it's the most important thing for us is it's the engine that really drives continual improvement. And without it, I think teams stagnate. I think they just get kind of stuck in a rut. problems that we have, we just continually repeat. if we don't have the time to stop an exam. Cort Sharp (06:00) Yeah. All right. So I kind of got one bigger idea from there. And for whatever reason, when you were like, we gave everyone the red button to stop the assembly line. And that's kind of, we're stopping, we're pausing, we're inspecting, and then we're going to come up with a plan to adapt. Whatever reason, this phrase stuck in my head, it just popped out to me. But it sounds like we're giving power to the people. Brian Milner (06:06) Okay. Cort Sharp (06:26) where we're, you know, the team has the power, the people have the power to say, whoa, let's stop here. Let's hang on a second. Let's take some time and let's figure out a better way to move forward. And from that, I just think of sports. I think of sports teams. We're in the middle of March Madness as we're recording this right now. And I can pretty much guarantee you that every single one of those teams who's advancing on past, I think round one is going on right now, so passing on through round one, they're probably watching some film on their opponents. They're trying to see, what are they gonna do? What are some plays? How can we kind of counteract it? But more often than not, I would wager, I'm not a gambling man, but I'd wager, that they're looking at their own film and they're trying to see what did we do well in this game that got us the win? What can we improve? so that we could maybe have a little bit more of a bigger margin of victory. And what is it that we should probably stop doing? What is there that wasn't working out? Maybe our pick and rolls were not good, maybe we weren't executing well on those, or not to get too into basketball terms there, but maybe we should stop shooting so many threes or something like that. I don't know, right? But yeah, that's, yeah. Brian Milner (07:42) I think you're right. I think you're absolutely right that, you know, sometimes we think this retrospective thing is maybe, is this just a weird thing that we do in software development? No, this happens in a lot of professions. There's a lot of different professions out there that take time to analyze. And by the way, I'll throw this out there as well, because you mentioned kind of sports. Sometimes people will, I've encountered teams at times that think, You know what, we're good enough. We don't need to do this anymore. This is really only for teams when they're starting. We don't need to have retrospectives once we've become mature. Well, to them, I'd say, well, then why do championship teams continue to watch their film? Right? If a team won the Super Bowl last year, don't you think that they still go through training camp and get ready for the season? Yeah, they absolutely do. But they're on top of their game. So if they think it's necessary when they're on top of their game, is there really a moment that we would be so on top of our game that we have nothing left to learn and get better at? I'd say no. I think that there's always something that we can get better at. And I think that's a great analogy to kind of drive that home. Cort Sharp (08:54) Yeah, awesome. I totally agree with you there. Even just outside of the team sports world, I come from a more individual sport background. And it's so important to take some time and just reflect on, how did I perform? How was my performance, even on an individual level, so that I can take some action steps throughout this next period of training or work or whatever it is that I'm doing so that I can make the next next performance or the next time I race or the next time I get out there on the court or on the field or whatever. That's how I can make that next time better than this last time. So awesome. Thanks for clarifying. Thanks for. Brian Milner (09:28) Yeah. Well, yeah, yeah, no, no, it's a great question. I think this is, probably time for us to kind of let the cat out of the bag here a little bit and just say, one of the reasons we wanted to focus on it for the episode is, drum roll, we kind of have a couple of courses coming out. here that we're going to offer at Mountain Goat Software that you can take around retrospectives. They're on demand videos that I worked on. They're two different separate courses. And we just thought this was an area that really needed some focus and attention and we were getting lots of questions around it. So we always try to listen to what you guys are telling us. And what we were hearing was, this is where you wanted us to focus. yeah, not a lot of details that I'm going to say right out of the gate. But yeah, we do want to kind of announce that those are coming here very, very soon. Cort Sharp (10:22) Yeah, so if I heard you right, I think you said this, but there's two courses coming out, right? Okay, cool. We're letting that out of the bag. Brian Milner (10:28) That's correct, yeah, two. right, right. I mean, you might think, one course I can understand, but two? Yeah, there's so much material that there was too much for one. And people could not consume all that in one go. And so we created two and kind of found different aims, different goals for both of them. to target what people were really asking for. So yeah, there are two separate courses. One that's going to be called Better Retrospectives, and another one that's called Retrospectives Repair Guide. So yeah, you can sell just from the names, kind of taking two different approaches here on focusing on retros. Cort Sharp (11:07) That's so awesome to hear that we have two separate types of courses that solve kind of two problems. So what were the reasons why you decided or Mountain Goat decided, hey, we probably need to make these to help solve some pain points. What were those pain points and what are these common struggles that you're seeing? Brian Milner (11:19) Yeah. Yeah, completely fair question, right? I mean, why didn't we do one on sprint planning? Or why didn't we do one on daily scrums or whatever, right? Well, maybe we will in the future. I think the kind of genesis of this idea or why we decided to focus on it was we periodically survey users. We watch what people do when they come to the site, what they search for. And one of our top search terms and one of the top search areas that we've seen over the years, really, it's been consistent, is around retrospectives. So we know that's an area people want to know more about and want to get help with. So that gave us the first little inkling that this might be something to focus on. That led us to doing just a free open webinar that we did. I hosted that, I put together a presentation to give some tips around it and help people, just a short little presentation, but wanted to just give some really quick tips people could apply. And we had over a thousand people sign up for that. not, I shouldn't say that. We had over a thousand people attend that. just, lots of people sign up and don't come, but. We had over thousand people who showed up and attended to hear that. And that kind of blew us away. think, wow, this is really, know, people made time in their day to come and listen to this, you know, short little webinar on it. There's interest here. And with a thousand people, we didn't have nearly enough time there on that webinar to answer everyone's questions and get through everything that was coming at us. But, you know, we love data. So. We pulled all that data from all the questions that had been submitted and people had presented to us and grouped them, categorized them, tried to sort them through and try to find what's the biggest kind of pressure, pain points that people are having that they wanna know answers to. And that's what led us to really create these courses is there were reoccurring themes, right? There was a kind of set of things that are common amongst people. common issues, common problems that people are having, common root causes of those problems. And we just thought, this is doable. It's not an impossible thing to fix. There are actually practical, real ways of solving these things. And we wanted to give people solutions to the things they wanted to hear about. So that's why we decided to focus on retrospectives. Cort Sharp (13:50) Awesome, sweet. That's still crazy to hear. I knew that you had a thousand people or a little over a thousand people attend that live stream, I think is what you did, right? Because it was like a YouTube live stream or something like that. That's still mind blowing to me that there was that much turnout and... Brian Milner (14:09) Actually, I just wanna say, I don't know that it actually even was on YouTube. That's what makes it even more kind of impressive to me is people had to like get a link and go into it. So it wasn't just, hey, I'm flipping through YouTube on my lunch break and it turned up. It was people who deliberately said, no, I'm making an appointment to go to that. Yeah. Cort Sharp (14:29) Man, that's even, yeah, that's crazier to me too. That's awesome. That tells me, yeah, there's a ton of demand for this, right? So can you give me just a brief overview without oversharing or sharing a little too much about what each course kind of offers and what problems they're working to solve or we're solving within each course? Brian Milner (14:31) Yeah. Sure. Yeah, I guess it's probably important to know the strategy of both of them and why there's two. As I said, there's just a lot of material, so it was too much to fit into one. But I tried to follow the pattern in creating these that we've established at Mountain Goat with previous classes. So the first one that I put together, we titled Better Retrospectives. And that's following the pattern that we've done with other things like better user stories. So better retrospectives, the focus is sort of the expert deep dive on retrospectives. We go deep on the meaning behind things and kind of facilitation techniques that are useful to do, patterns you can use in creating a retrospective, ways you can create brand new. themes for your retrospective that no one's ever done before in the past because it's yours. It's something you created on your own. And just kind of all the ins and outs of how to really make a retrospective work and be productive, produce things that actually make differences on your team. So that was better retrospectives. But we wanted to then address head on those most common questions that people have. Again, try to follow the pattern that we've established with some previous things here at Mountain Goat. Mike has a course that I took years ago called Scrum Repair Guide. And it was about the most common problems that Scrum teams have. so I follow that pattern here. And the second course is called Retrospective's Repair Guide. And what we did was we took those highest volume asked questions, the most common questions we got from that webinar. got just the top 10 and said, these are the biggies. These are the big ones that people are asking about that really want to know the answer to. And we put together a repair guide course for it so that people can maybe consume that in a little bit different way. If I'm having one big problem right now and I need an answer to that, or maybe I have two or three problems, I'm not having all the problems, but I need an answer. I need help with this big thing that's going on with my team. We wanted to get that to them as soon as possible. So the retrospective repair guide is that ability for someone to look at our list of top 10 questions. And you'll probably find three or four of them on there that you'd say, oh, yeah, that's one I've experienced. Yeah, that's one we're having right now. And then you can just kind of to the chase and get right to where it is that you need to get help. And then practically go and make those changes immediately. So better retrospectives. The expert course, Deep Dive on Retrospectives, makes you an expert at delivering them and working with them. Retrospectives Repair Guide, more for those finding the solutions to the problems you're having right now. Cort Sharp (17:37) Awesome. I want to kind of double click a little bit into the retrospective repair guide. Man, tongue twister, right? The retro repair guide. Can you share just like one or two, maybe three of those questions that are answered or some of those bigger questions that were asked that are answered and that you give a solution to and a very clear solution to within that course? Brian Milner (17:43) Yeah, it is a little. Yeah. Yeah. Yeah, absolutely. just know for each one of these, it's not a, the answer is, here's a sentence. Each one of these, we go really deep on how to answer that and strategies. And I give you multiple things that you can do. Because a lot of these maybe even have multiple root causes to them that could be causing them. And there could be something different you might need to do to solve that for your team. But you know, Like one of the biggest questions that we heard, probably the most popular question that we got was, how do you handle retrospectives when you have a quiet team? When you have a team of people that are a little more introverted or shy, not uncommon with a group of software developers. So how do you get them a little bit out of their shell or how do you get them to just feel safe enough there to actually contribute? That was a big one. Um, you know, a big one for our, our day and age is how do you handle retrospectives when you have people that are remote? Uh, you know, do you have an entirely remote team? Do you have people that are, uh, you know, parked your team? Part of your team is, is in-house part of your team is remote. Uh, how do you, how do you handle that split? Um, that was another big one. Um, you know, how do you handle it when you're, you have a team that just hates retrospectives? Um, you know, how do you, how do you, uh, How do you get your team to start really making progress, real progress, from the things that you talk about in your retrospectives? So these are just a couple of them. we really thought that these, for each one of them, as I went through each one of them, I thought, yeah, this is a big one. This is one I get questions about all the time in class. So there was none of them that I looked at and thought, this is a filler. Am I going to make it to 10? No, mean, it was hard to limit it to 10, you know? But yeah, we limited it to 10 and all of them are really, really important ones. Cort Sharp (19:47) You Yeah, nothing but heavy hitters here. Nothing but bangers. Here you go. Yeah, that's it. Awesome. OK, well, thanks for the overview. Thanks for introducing these courses. That last question there, what do I do? How do I manage a team within my retrospectives when they hate going to retrospectives or despise that? That'd be super useful for me. Man, I might buy this course right now. Brian Milner (19:55) Yeah, yeah. Yeah. Ha Yeah. Cort Sharp (20:23) But I would like to, we strive to have some pragmatic approaches. We strive to provide practical, immediately useful tips on this podcast. I know that's a big point for this podcast that you really work on and you really focus on. Do you have any just practical, immediately useful tips? Let's start out, I guess. This might be a little teaser, a little preview. You might repeat something that you gave out into the Retro's course there, the Retro Repair Guide. With quiet teams, can you just share something that I can immediately take away and go off if I have a really quiet team and it's like pulling teeth to get them to talk and participate in Retro's? Can you give me just some useful tips or something that I can go away with? Brian Milner (21:08) Yeah. Cort Sharp (21:13) after listening to this episode and go off and use with my team to help my quiet team be a little more active and a little more beneficial. Show them that, this retro is for you. What can I do to work with my quiet team here? Brian Milner (21:29) Yeah, yeah, no, mean, how can I tease the number one thing without giving any kind of advice on it, right? And no, I mean, we're doing this because we want to get this information out route. We want to help teams to be successful with this. So no, I don't mind at all going into some things that might help there on it. There'll be much more in the course because I just have more time to do that. I think that the number one thing when you have a quiet team is trying to understand the why behind it. So for starters, I think it's important for us to understand that there are different personality types. I mentioned things like introvertedness. There are people who are more introverted than others. And if that's a of a spectrum in itself. There are people who are extremely introverted, and there's people who are only mildly introverted. Not to mention, one of my favorite topics, thinking about kind of different neurodivergent traits and how they interact and participate and things of that nature. So all that's to say, that I think the number one thing that we have to do is know our team. We have to understand who is in the room. Because I think we make the mistake a lot of the times of, I'm gonna just put together a retrospective. Let me go find out what that guy on YouTube said about doing a retrospective. yeah, that was a fun little theme that he came up with. Let me go put that in place. But that may not match at all. the personality of your team. It may not match the way that they prefer to interact. If I have a team full of introverts, I'm not gonna do a big role play kind of exercise in my retrospectives, because everyone's gonna be uncomfortable and everyone's gonna shut down. They're gonna go into defensive kind of stance, right? So I think that's the number one thing I'd say is, first of all, just understand and respect. respect the differences there in personalities to understand that they're not broken or in need of repair in any way. If they are quieter, that's just who they are. That's just how they're made. So I think that's part of it, right? I think part is that you have to understand your team. But there are other possible root causes here as well. One of the biggest is they could be quiet because they don't feel safe to actually speak in that room. That's a huge one, right? And it's so important. If they come into that room and they are fearful that what they say in that room is going to be reported outside the room to someone else, or they're going to be made fun of in that room for voicing their opinion or belittled in some way for it, well, That's a killer to a retrospective. If there's not that sense of safety in the room, doesn't matter how brilliant your pattern is for the retrospective or what great idea you came up with for it. If I don't feel like this is a safe space where I can speak up and not be made fun of or not fear retribution for something I've said, I'm not gonna speak up. whether I'm an extrovert or an introvert. It doesn't really matter my personality type at that point because the fear is what's driving everyone in that room. So I think you have to maybe even gauge the team. Maybe even ask them in an anonymous poll. I've done this before by just giving slips of paper and everyone puts in a hat. And you can do something like a safety check where you say, give me a number from one to five. five being the highest and one being the lowest, how safe do you feel today in this room to speak honestly without fear of retribution or being made fun of, that sort of thing? And it could very much surprise you what the answer is. That's actually an activity that I repeat periodically when I have a team because I want to chart it. I want to see where they are now. I want to see if it goes up or down. If there's some kind of a change, how does that affect it? We had, we lost a team member or two team members and we had new people come on. Safety is going to drop because we have new people. God forbid if we have somebody who's an outsider who insists on coming into it. I try my best to keep them out, but hey, if my boss says, well, I'm overruling you, I'm coming in. Well, are you gonna quit immediately because that happens? Probably not. What can you do? Make it transparent, the effect. You can say, hey, we periodically take these safety checks. So here today, I took another safety check. Our normal average is 4.2. Today, it dropped to 2.1. Why do you think that happened? It's data. So I think safety is another big reason. Cort Sharp (26:13) Right. Right. Brian Milner (26:18) So let's, personality type, gotta understand personality type, gotta make sure the environment's safe. And by the way, kind of corollary to that is not only that it's safe, but that their opinion matters. So if they speak up and say things and no one pays attention to them, no one listens to them, well again, you're telling them your idea doesn't matter, learn this lesson, next time don't speak up, right? Cort Sharp (26:30) Mm-hmm. Brian Milner (26:44) So they've got to have a safe space. And then I think you've got to match your activities to your team. You've got to find ways of connecting to them that will feel comfortable for them, that make them feel. I say this all the time in classes, facilitation, the root word in facilitation is facilis. It's a Latin word. means to make easy. So we're facilitating a retrospective. Make it easy. If your team doesn't want to role play, and you've got an activity that's a role play thing, then that's not easy. That's difficult for who they are. But if your team, another kind of difference, are they verbal processors? Do they need to talk things out to find a solution? Or do they need quiet space? that they need introspective time to find solutions. If that's the case, well, maybe I start with something like quiet writing. I don't even have an activity where they're talking to each other at the beginning. So I think that's third thing I'd throw out there is to say, Once you know your team, make sure you are matching the format, matching what you come up with for that retrospective to the personality of your team. It's hard, right? Someone can't walk in off the street and deliver a great retrospective to a team they don't know. But the good news is you know your team, right? You work with them all the time. You're the expert on this. Cort Sharp (28:08) you Yeah, yeah, as a more introverted person, nothing sounds worse to me than trying to, to do any kind of role playing, putting myself in some position that I just don't normally put myself into and I'm not comfortable with right that that is not my jam. That is not my thing. Brian Milner (28:27) Yeah. Yeah, and can you blame it when, if that happens, can you blame the team for saying they hate the retrospectives and that they don't want to do them anymore? Yeah. Cort Sharp (28:39) No, not at all. Not at all. If my scrum master came to me and said, right, we're going to, Brian, you're acting as this person, Court, you're acting as this, and we're going to reenact little Romeo and Juliet, bring that into there in this. And it's like, what? No, this isn't valuable. Brian Milner (28:47) You Right. Yeah, it's one thing to say, we're going to pretend to be each other and talk through. But it's another thing to say, pretend you are a peanut. you're like, that kind of thing. When you're an employee, you're like, god, really? I have to be a peanut now? Great, great. Yeah, no, this is fun. It's that kind of thing that if you don't, maybe your team would enjoy that kind of thing. If so, then match it to them. Cort Sharp (29:10) Yeah. Yeah. Brian Milner (29:19) They're not in that mode. No, no, no, no, no, no. Cort Sharp (29:23) Yep. Well, awesome. think I have a couple more questions for you here. Should be relatively quickly, right? Thanks for giving a little preview and giving some practical advice for what we can do to help our more quiet teams. But I want to take a step back. I know we double clicked into that one course, but I just want to take a step back a little bit. how do I decide which courses is right for me? Brian Milner (29:28) Yeah, yeah. Yeah. Cort Sharp (29:48) Do you have any guidelines for that? Any advice for if I'm interested in both courses, but I don't know which one would be a little more beneficial for me? How do I make that choice? Brian Milner (29:58) Yeah, that would be an extremely difficult decision to make because you have to really know these courses intimately, think, to make that, or maybe not intimately, but you probably have to dive a little bit deeper into what the agenda is for each one to kind of know the answer. But here's the good thing. When we're launching these, I can tell you this as well. We're going to be launching it as sort of a two for one. So. The good news is when we, know, for the initial launch of this, that's going to be the bonus for being in the first group is you don't have to decide. You'll get them both and you can then, you know, choose on your own. can dip in and see, you know, if one's better for you than the other, great. But you can consume it any way you want. And, you know, I'm just really excited for people to get to see the stuff and to hear it. I think there's some. there's some stuff that's really gonna help people in it. Cort Sharp (30:47) Awesome, great. Helping my decision fatigue there, Brian. That's great. Wonderful. One less choice that I have to make. Well, great. Awesome. That's kind all the questions that I have for you. Are there any kind of key takeaways or anything that you want to single out about retrospectives as a whole or anything about these courses that are going to be offered here anytime soon or anything like that? Brian Milner (30:50) Yeah, exactly. Exactly. Yeah, I wanted to do this kind of an episode about this because, you know, I feel like the listeners here to our podcast, you guys know me, you know, the kind of stuff that I talk about. And, you know, I wanted you to be the ones who kind of heard this and knew about it first. I think it's going to be really beneficial and it's going to really kind of turbo charge a lot of teams. We talked about why retrospectives are important. Well, as I said, it's the engine for that continual improvement. If you don't have it, then the team stagnates. If you do have it and they buy in and this is, they're really all in on that Kaizen continual. improvement, know, Kaizen comes first mindset that kind of comes along with it. Then they look forward to this meeting. It's not just, know, something to check the box at the very end of our sprint, but it's actually, you know, when are we going to have that retrospective? I've got some stuff I want to talk about and that's our time now. You know, we can shut out the rest of the world. We can shut out, you know, everyone who's not here in our team. And now we can focus on us. You know, the question I often ask the teams when I do this is, do retrospectives is, what would it take for us to be the team everyone else wishes they were on? And, you know, that's really what you can accomplish through a retrospective is you can be that team, everyone else in the group and the organization looks at and goes, man, I wish I was on that team. That team's the, that team looks like a great team to be on. You know, I know there's, we're not given a lot of details here because this isn't We're not opening sales to this at the time that you hear this, when this podcast comes out. This is just a preview. I wanted to announce it here in the podcast first and let you guys know about it. Stay tuned. We're gonna have some stuff coming out soon. You can come to our website, mountaingoatsoftware.com and you'll find more information about this. But stay tuned here to the podcast as well. We're going to talk about some other things around podcasts in the next few weeks. we'll let you know when it's going to be open. I'll tell you as well, this is going to be a limited time thing. It's not something that we're launching and then kind of keeping open forever. This is something that we're going to launch. And there's a window for you to actually purchase this. receive both these at the same time. We'll talk about pricing and all that other stuff later down the road. But I just wanted you guys to know that these two things were coming. And hopefully, that gets you excited. And you can start now saying, hey, boss, there's something I'm going to be asking you for here for the training budget or something somewhere along the way. So stay tuned. We'll have more information here about it in the coming weeks. Cort Sharp (33:51) Yeah So we're starting the hype train now. Hype train is starting to pull out of the station. And the next station it comes into, it's only going to be there for a limited time. So make sure you get on board and get on with this. Because these sound like really awesome classes. And they sound like a really great way to either elevate where you're at already or where I'm at already for retrospectives and whatever techniques I'm using. I know we didn't talk much or really at all. Brian Milner (34:01) Yeah, exactly. Cort Sharp (34:26) other than the title of the Better Retrospectives course. But having been through the Better User Stories course, that really elevated my ability to write and facilitate user story work or story writing workshops. But it allowed me to be more effective on the user stories front. if it's anything following that trend line, which it sounds like it kind of is, that Better Retrospectives course sounds like a fantastic way to elevate. Brian Milner (34:46) Yeah. Cort Sharp (34:53) my ability to not only facilitate, but also just get more value out of retrospectives. And then the retro repair guide. Awesome starting point. Sounds like it's a great spot if I'm struggling with anything. Really, really common. Well, not really common. The biggest questions, biggest problems that are seen throughout retrospectives. Great starting point in order to. help myself grow and get up there. And the fact that I don't have to choose between the two, that's fantastic to me. makes me really excited. Brian Milner (35:25) Yeah. Bonus, right? Yeah. Well, and I do want to throw out there as well. know, the pattern here, I'm copying Mike, right? This is what Mike Kona has done previously. And I'm with you, Court. When I took the Better User Stories course, you know, I really wanted to go deep on user stories. I wanted to understand them at a level that I just didn't previously. And I wanted to know the ins and outs. I was ready to go deep on it. And I agree with you. did the same thing for me. It helped me to really fully understand kind of what this method is and how to get the most out of it. So that was my idea when I wanted to copy that into the retrospectives. I wanted the same thing. I wanted people who were at that point where they're ready to go deep. Here it is, right? It's ready for you. And retrospectives, the repair guide as well, I was a consumer of Mike's Scrum Repair Guide before I joined Mountain Goats, you know, when I was a Scrum Master on a team. And I remember when I saw that course and I saw the list of things that, you know, he was going to talk about in that course. There were two or three of them on that list that I just said, yeah, star that one, star this one, like that. I need that answer. I just remember that feeling of, I really need the answer to this. So my thought at that time was, whatever this is, It's worth it because I don't know how to do this on my team right now. We're having this problem and I need it fixed. So I need guidance on how to do this. And I know there's people out there that are gonna feel that way about some of these topics they're gonna see that we have in the repair guide. So all that's just to say, it's from the point of view of someone who benefited from that pattern, you know, from Mike and other courses. And I'm hopefully going to be able to do that for people here with retrospectives as well. Cort Sharp (37:15) Well, I'm excited. So a couple action points for anyone else who's interested in this. Stay tuned, right? Stay tuned for future episodes on the podcast. Keep an eye out on stuff. Can they visit mountainghostsoftware.com right now and sign up for a list or anything or get any pre-emails or anything like that or not quite yet? Brian Milner (37:33) I don't think there's anything that you can do at the moment. mean, if you're on our email list, I think that's probably the best thing you can do. You sign up for our email list. You can do that pretty easily at mountandgoatsoftware.com. And that'll keep you informed when we send out our newsletters. We're gonna have information on it there as well. But it's kind of like, you you get those emails sometimes that just say nothing right now, but, so nothing right now, but, you know, kind of just... File this away, know this is, you in the next few weeks, you're gonna hear more about this and then it'll be that limited window that you can actually, you know, take advantage of it. Cort Sharp (38:07) Awesome. Yeah, so keep listening in, keep an eye out, and we'll keep giving you some practical approaches, practical tips that you can use to go into your next retrospective. Maybe your team isn't the quiet team, but maybe they're the ones that just don't really like retros. know, Brian, thanks for helping me out with my quiet teams, or any time that I interact with quiet teams, and even the ones that are a little more just passive and don't. Brian Milner (38:28) Nah. Cort Sharp (38:34) don't really see the value in retros. Thanks for sharing those tips and for helping me out with all the teams that I work with. So I appreciate that. Thank you. Brian Milner (38:42) Yeah, absolutely. If you can't tell, I'm really excited about it. I can't wait for people to start diving into this stuff. more than anything, I can't wait for it to start to make a difference in teams. Cort Sharp (38:53) I'm excited, Brian. I can't wait. I'm stoked. Brian Milner (38:54) you

  --------  

  39:33

More Technology podcasts

Trending Technology podcasts

About Agile Mentors Podcast