In today’s episode of the Agile Coaches’ Corner podcast, Dan Neumann is joined by David Horowitz, the co-founder and CEO of Retrium. Retrium is an incredible tool that enables teams to lead engaging retrospectives that fuel continuous improvement. It empowers agile teams to have more effective conversations, discover new insights and generate action plans, and maintain a guided facilitation process and a space to organize your retrospective documentation in one place.
And speaking of retrospectives, today’s episode is going to be a retrospective deep-dive. Dan and David will be addressing some of the common misunderstandings and misconceptions around retrospectives, why you should hold retrospectives in the first place, some of the common anti-patterns with retrospectives (and how to combat them), and most importantly, how to have more effective, engaging retrospectives.
Transcript [This transcript is auto-generated and not completely accurate in its depiction of the English language or rules of grammar]
Intro [00:03]: Welcome to the Agile Coaches’ Corner by AgileThought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.
Dan Neumann [00:16]: Welcome to the Agile Coaches’ Corner. I’m Dan Newman and I’m excited today to be joined by David Horowitz, the cofounder and CEO of Retrium and, uh, has a lot of real world experience including the world bank and the international finance corporation and, uh, now doing the startup thing. So thanks for taking time and joining, David.
David Horowitz [00:36]: Thanks so much for having me, Dan.
Dan Neumann [00:38]: And, uh, appropriately enough Retrium is a tool for Retrospectives. And so we’re going to be talking about the topic of Retrospectives and exploring that a little bit. So it kind of a retro deep dive.
David Horowitz [00:50]: Fantastic, super pumped. I could talk about this stuff at three in the morning without worrying about it, so happy to do this with you today. All right.
Dan Neumann [00:57]: Maybe people are listening at three in the morning and they’re like, man, what’s this Retrospective thing anyway? It’ll be awesome. I love retros. In fact, what the, uh, the first agile conference I went to was in Orlando and they had a little, um, lunch with the authors and Diana Larson, I had her she was at a table with a little flag up there. That’s a Diana Larson. I couldn’t have picked her out of a lineup. I had no idea who she was. And that actually was kind of the first time I bumped into anybody who was really, um, kind of passionately exploring Retrospectives cause as folks know, she and Esther Derby wrote the book on agile Retrospectives.
David Horowitz [01:33]: Yeah, glad you brought that up at the beginning. So if you haven’t read it, it’s sort of the Bible for lack of a better word of retros. So start there for sure.
Dan Neumann [01:39]: It is. And I honestly, you know, I keep waiting for somebody to go like beyond that or somewhere else, a lot of complimentary things, but I haven’t seen anything that’s really wowed me from a, a different framework. The framework they, they introduced I think is super valuable. And of course they, um, they borrowed that from, from previous works as well. His name is just completely escaping me right now.
David Horowitz [02:02]: Yeah. So to, to be cautious of self-promotion here, but we have something called the Retrospectives Academy that we publish. It’s Academy.retrium.com where we’re trying to do a bit of that. It certainly builds off of Diana and Esther’s work. That to me is still the core of everything we know about Retrospectives, but we’re trying to go a bit deeper than that. So yeah.
Dan Neumann [02:21]: And Norm Kurth was the name I couldn’t come up with a minute ago. A lot of Norm’s work was the basis for what Esther and Diana did and uh, and cool. So you guys have have complemented that as well.
David Horowitz [02:32]: Yeah. And I’m also glad you brought up Norm by the way, because he, so what’s interesting about Retrospectives is that there’s a common misunderstanding that Retrospectives came from the agile community when in fact Retrospectives predated the agile community. And Norm had a lot to do with that. So he had a book called project Retrospectives that a lot of Diana and Esther’s work is based on.
Dan Neumann [02:50]: Yeah. So, uh, yeah, for folks who want to deep dive, they can start there. And then, uh, so this, this retros thing, any why should we, why should we waste, you know, gosh, 30 minutes or an hour or two hours or some chunk of time every sprint. And that’s tongue in cheek. Obviously it’s not a waste of time, but.
David Horowitz [03:06]: Well it can be. So maybe we’ll get into that. Um, but yeah, why retrospect, right? What, why are they important? So I like to start with the basics and go up a level from retros to agility or to agile. So what is agile, if I were to describe it in just two words, agile to me is continuous improvement. That’s all it is. Everything else is just the details of how you get to continuous improvement. And the engine of continuous improvement is the Retrospective. It’s a meeting in which teams get to ask themselves, Hey, what’s not doing so well and how are we going to improve going forward? And that opportunity to learn is what catalyzes the continuous improvement process that agile is all about. Uh, so the purpose of a Retrospective to me is often misunderstood in the industry. A lot of people, if you ask them, Hey, why retrospect? They might go immediately to, well, we’re trying to find ways to get better as a team and we’re therefore if the retro leads to better productivity or better team communication, then that’s the success criteria for a Retrospective. Which of course that’s great if you can do that, right? Yeah, absolutely. But can you have successful Retrospectives if you don’t achieve some productivity gain, for example, to your team? And I’d argue yes. So to explain why, uh, to me the purpose of a Retrospective is what I call actionable team learning. And those three words are picked very carefully. So learning is of course some nugget of information that the team has found out or discovered as a result of their conversation and team learning because it can’t be isolated to an individual. The whole team has to learn it and actionable in that they have to be able to try to change as a result of whatever it is that they learned. So if you imagine a team learned something that does not in fact lead to some improvement for the team, I’d argue that’s still a successful Retrospective because you’ve narrowed the potential solution set of what might help the team by one. And that’s helpful in and of itself. So the goal is not just trying to improve productivity. The goal to me of a Retrospective is let’s get the team to learn something and try something new that might in fact lead to learning and help.
Dan Neumann [05:16]: Yeah. We talk about that sometimes in the spirit of a scientific method or experimentation, Hey, we have this hypothesis. Here’s the thing that we think will cause good change, and it doesn’t always and so yeah. So then you’ve got this, um, you’ve still got learning, you know, one more thing that doesn’t work like you were mentioning.
David Horowitz [05:36]: Yeah. And that’s a good shift for the team in terms of mindset. I think it really can help them lower the barrier of success for a retro, which might help people be more engaged and passionate about it going forward too.
Dan Neumann [05:47]: So engaged and passionate I think are two really important characteristics, especially as you’re trying to avoid the waste of time Retrospectives, which is I the biggest dysfunction that I’ve come across. Oh gosh, we took, you know, everyone’s the same or we never make anything different. So we shortened the time box so we’re not wasting more time, which makes them less effective, which shortens the time box and it’s the death spiral of Retrospectives.
David Horowitz [06:13]: It is. And that’s a huge problem. Um, when I talk at conferences, I’ll ask people, you know, raise your hand if every single time you run a Retrospective, you get out of it what you hope to get out of it. And almost no hands ever go up. And the problem with that is it leads to the vicious cycle of Retrospective disillusionment, which basically just means that you start getting the sense of these things are a waste of time. And the rational response to something that’s a waste of time is of course to not do it again. So you’d expect the behavior that we see in the industry, which is people don’t want to show up for these things. So breaking that cycle and that negative downward trend is really important to me. It’s kind of why I’m excited to be here on the podcast with you.
Dan Neumann [06:53]: Yeah, let’s go. So let’s talk about breaking that cycle. And some of this might be from a Scrum Framework, but the Kanban method certainly has inspect and adapt and continuous learning as part of that. And so Retrospectives are applicable there as well. So maybe we’ll, we’ll drift into and out of kind of Scrum Framework and, and like you said, with Norm’s work, you can do these for projects, you can do these for all kinds of things.
David Horowitz [07:17]: Yeah. Retrospectives are not limited to Scrum. They’re not limited to agile. Actually, any team that’s working together on anything using any process could benefit for Retrospectives.
Dan Neumann [07:25]: So happy to go beyond agile with you. Absolutely. So you want to start with the people part?
David Horowitz [07:31]: Yeah. So, yeah, we can start with people. But I think also, just to back up just for one moment, I mean, what the bigger question is, what’s the biggest problem with Retrospectives? I mean, why, why is it that people get disillusioned, right? Uh, and in my mind, at least, the biggest problem with Retrospectives, it’s not that they are not fun. It’s not that we need a new game to play or a new activity, which don’t get me wrong, they’re, they’re great, right? Go ahead and try new games and new activities out. I do it all the time, but the biggest problem is lack of follow through in the sense that if every single time you ran a Retrospective, it led to some actionable team learning that eventually led to productivity gains. Then people would show up and they’d be engaged almost irrespective of the format or the game or the activity or technique that you used. So breaking that downward cycle relies on being able to achieve, follow through, making that almost muscle memory. Every time we run a retro, we’re going to follow through on it. And if your team starts to do that, then eventually they’ll get to a point where engagement in retros goes up. That’s the biggest problem. So the question to me is how do you break that vicious cycle? How do you get to follow through? And that I think starts with people, right? So the question is who do you invite to the Retrospective? It sounds simple. Um, and if you follow Scrum, the Scrum guide itself has a rule about this. They say that the people you should invite to the Retrospective are the people on the team. And the team is a capital T for The and a capital T for Team. It’s a term that’s defined in the Scrum guide. So it’s very clear. It’s the product owner, the Scrum master, and the rest of the people doing the work. So you follow the 80/20 rule, right? Most of the time that sounds right, but there’s certainly cases when people beyond the PO, the Scrum Master and the rest of the people on the team should be invited. For example, maybe you have some dependency on other teams. Maybe you should do a cross team Retrospective. Uh, maybe you have someone who is not a full time team member, but you know, you’re going to be relying on them for the upcoming Sprint. Maybe they should be involved in your Retrospective. So kind of use your brain, right. I don’t like to say always follow the rules. Kind of think through what you need to do to extend who you invite based on the circumstance that you’re facing. Because if you can’t get the right people in the room, how can you retrospect effectively?
Dan Neumann [09:44]: Yeah. And then you end up with the, uh, the, the messenger running back and forth. Um, yeah, and I think, uh, that’s a pretty prudent way. I sometimes joke about my, uh, German heritage and I like my rules though. The rules, you know, the rules keep us rules keep us safe. They, you know, they create some boundaries. Uh, but yes, you know, you want to make sure that whoever you’re bringing in isn’t going to negatively disrupted the Sprint Retrospective. But yeah, they have them participate in solving the solution. If it’s your ops folks, you know, engage with them. If it’s, um, some folks around the product ownership activities, you know, maybe you invite them or other teams for sure.
David Horowitz [10:25]: Yeah. As long as it’s opt in. So you certainly don’t want the manager or for that matter anyone, any one individual person saying we’re going to invite this, a new person into our Retrospective and you don’t have a voice in that decision because then psychological safety goes, it goes down the tubes. Right. So it should be an opt in the whole team through consensus volunteers to invite somebody. And I think then it, it adds to the Retrospective.
Dan Neumann [10:48]: Well, and I think, you know, as we talk about Scrum Guides specifically, you’ve got the Sprint Retrospective. That doesn’t mean you can’t have some other form of retrospecting and continuous improvement. So maybe for the Sprint Retrospective and the Scrum team specifically, you keep that safe and then, um, to the degree possible you, you bring in those other folks. You know, it nothing to say you can only have one, I suppose as well.
David Horowitz [11:12]: I mean one option there is a continuous Retrospective, which don’t get me wrong, you’re not always retrospecting and doing nothing else but a continuous Retrospective, the idea is maybe you hang a poster board somewhere around the team room and you just tell people anytime you identify a problem, just write it on a sticky note and put it up there on the board and at any time during the iteration, if you see anything on that board that resonates with you, just put a little sticky.vote up there to indicate, yep, I agree with that. And if you ever get a critical mass of dots on a impediment on that wall, stop what you’re doing retrospect then. Right? It doesn’t have to be at the end of the sprint, so don’t follow the dogma. Retrospectives are just how do you get better? Do that when you need to.
Dan Neumann [11:54]: Yeah. I’ve seen the agile conferences really embrace the kind of the continuous Retrospective where they have the flip charts up on the wall and then to varying degrees of success. I’ve seen that work kind of outside of conferences, but if for me a lot of times just at the conferences, a great example of people retrospecting in real time and problems getting solved in real time. So yes. You know, don’t, don’t let something hurt for an entire sprint if it’s entirely solvable in the middle.
David Horowitz [12:22]: Yeah, couldn’t agree more. Absolutely.
Dan Neumann [12:24]: So we’ve got, um, we, we talked a little bit about the who right? So the Scrum team and then, you know, maybe looking to pull in those other folks that, um, that might be around the Scrum team and impacting them. And, and since we’re talking people, you’ve got people that like to talk, you got people that don’t like to talk, some people talk too much.
David Horowitz [12:48]: That is true. Absolutely. So you have these different types of personalities on the team. And a lot of times the people who speak most are the ones who speak in the Retrospective at the exclusion of others. And that’s a problem because yes, they might have good ideas, they probably do, but certainly they’re not the only ones with good ideas. So you want to come up with ways to level the playing field for different personality types. Um, one of the ways that I like to do that, you start simple, right? So, uh, sticky notes. Don’t go around the room and just say, Hey, everyone, shout out your best ideas. Because of course then the extroverts, the senior managers or whoever has seniority will speak up first. But just say, Hey, let’s take the next 5 to 10 minutes to write down your issues, what you want to talk about on a sticky note. And that balances the different personality types out quite nicely. It also has the benefit of allowing people to brainstorm at the same time as each other. So if you’re going around the table asking one by one, you’ll have a backlog, you have this, you have to wait your turn and you’d have to listen to others. Uh, and that actually makes it take longer to get to a conclusion. It’s something you want to talk about. So sticky notes are the simplest way to balance the personality types. There are other ways too, um, one is using a .voting, right? So again, instead of saying, Hey, what should we talk about first and letting the most extroverted person in the room speak up. If you democratize the prioritization of the discussion topics using .voting, you let everyone in the team have a voice about what should be discussed first. So making sure you balance all those personality types is really important to helping boost engagement in the retro.
Dan Neumann [14:24]: Yeah. You get those, the anchoring effect where you know, right or wrong, the first thing that gets brought up is more likely to, to pull the rest of the conversation towards that and the silent writing, the .voting. Um, super valuable ways to get around that.
David Horowitz [14:40]: Yeah. You can also do things like vary the way the conversation takes place. So some people feel more comfortable speaking in a one on one type setting. So using a one, two four, all from liberating structures that have a chance to speak in a smaller setting before having to talk in front of the group can help surface ideas that otherwise might not have been exposed. Uh, and some people feel the opposite. They don’t feel comfortable in a one on one conversation but would feel completely comfortable talking in front of a group. So just varying how the conversation takes place is another great way of ensuring everyone has a chance to speak up.
Dan Neumann [15:13]: It brings to mind the, you’re mentioning the, the chance to speak up sometimes it’s also inviting people in explicitly. You know, you may as a facilitator notice that somebody is sitting back. Um, and just making sure that you have solid good facilitation skills going on.
David Horowitz [15:30]: Yeah, this is a problem to put it lightly. I think for people who facilitate Retrospectives, in my experience, at least the majority of people who do that don’t have actual background in meeting facilitation. And so you’re asking people who are perhaps former engineers, people who are former project managers to all of a sudden become expert meeting facilitators. And that’s just not a realistic thing. So taking the time to level up your facilitation skills as a Scrum Master or even as an agile coach is something that I think is really important to the success, not just of retros, but agility as a whole. Um, so you mentioned inviting people, you know, there’s different ways of inviting people into the conversation. One might be to call on someone. I don’t know if you’ve ever experienced this when you’ve been in a group setting, but the facilitator might say, Hey Dan, what do you have to say about this? And that always made me personally feel uncomfortable because maybe I wasn’t ready to speak up right then, but it’s certainly an option as a facilitator. Um, another way to invite people is just to have an open ended question, just say, Hey, does anyone else have anything to say about this? And just pause and then count to 10 really slowly in your head and give space to people to pipe up who might not otherwise feel comfortable.
Dan Neumann [16:53]: I love the count to 10 and I’ll nitpick a little bit sometimes. So the um, the, does anybody else sometimes results in no, but asking kind of who else is one way to, to um, almost guarantee that somebody speaks up, cause you’re already saying like somebody else is going to talk. Like who is it going to be kind of thing.
David Horowitz [17:14]: Yeah, you’re completely right. I misworded that one.
Dan Neumann [17:18]: I’m sure I’ve misworded something up to this point too. You’re welcome to bust me back, but you, but right. But, but it’s those, it, those, those little things that, that as you, um, start to, um, kind of more intentional, like you said, it’s kind of studying the way people interact and, and pulling them in. So, um, which Scrum Masters sometimes do or don’t have that skill. And like you said, even the coaches a lot of times can level up on that. Um, so in a Scrum Framework, I think we know the answer, or I can guess what your answer is? Does the Scrum Master have to facilitate the Sprint Retrospective?
David Horowitz [17:54]: And given what I’ve said so far about don’t follow the rules, I think you’ll, you might understand. Yeah. I, you know, in general what we’re finding in my experience again at least is that the Scrum Master, by default, is the facilitator of these meetings. But I think it’s a mistake to assume that that should be the case in every single Retrospective. In fact, facilitation is really hard. It is not an easy thing to do. And if you’re facing low engagement in your Retrospectives, one way to increase empathy for you as the facilitator is to open up the meeting to others who might want to experience how difficult facilitation really is. Uh, and this will also give you a chance to not facilitate and instead participate in the Retrospective because kind of, this golden rule of facilitation is you have to pick one, facilitate or participate. It’s really hard to do both. And I’ve always struggled with that rule personally in a Retrospective setting because you are not an external member of the team. If you’re the Scrum Master, you are on the team. And so your voice in the conversation should be heard. You have an equal amount of things to say, likely as everyone else on the team. But if you’re, if you’re concentrating on facilitating, it can be hard to find a space to voice what you have to say. Um, and also encourage others to speak up. So rotating the role of the facilitator is a way to allow you as the Scrum Master to just be a participant from time to time. And the overall team I think can benefit from that.
Dan Neumann [19:17]: Another option that comes to mind is reaching outside of that Scrum team for a neutral party. Somebody who, like you said, the Scrum Master’s in there, they’re responsible for having the Scrum Framework work well. And so hopefully they are engaging with the team, with the Product Owner in helping the Scrum Framework be implemented while, so yeah, maybe go outside and have somebody come in to facilitate too.
David Horowitz [19:42]: Yeah, I was talking to a guy, Oh I don’t know, maybe three, four months ago who set up a program of Retrospective facilitators across the company and it was opt in so anyone could say, yes, I’d like to do that. And then any team could pull in those in quotes, resources. People are not resources but pull in those individuals to be external facilitators for their Retrospectives. But what was important and what I took away from this was that it was opt in volunteer on both ends. It was that people volunteered to say, yes, I’d like to facilitate other teams, Retrospectives and teams volunteered to say yes, I’d like an external facilitator if either one is forced that becomes a lot less effective. But it was an interesting idea and the other thing about it that the person I was talking to mentioned that I thought was really insightful was that if you set up a program like that, you have to be aware of what it might do to your career in a positive way in the sense that if you are volunteering to be a facilitator for other teams’, Retrospectives, you are going to gain a lot of insights into the problems and the potential solutions that teams across your entire organization are experiencing. And that knowledge is a heavy burden to have because on the one hand, you don’t want to violate the safety of teams who’ve shared that information in confidence with you in their Retrospectives. On the other hand, if you’ve identified a problem that 75% of teams at your company are experiencing, isn’t it your responsibility to tell someone so that it can actually get fixed or to try to remove that impediment for the company. But the message there is you become very valuable in a dangerous way to the company if you volunteer for that role.
Dan Neumann [21:24]: Yeah. And even maybe it’s a matter of making others, um, or, or making the team that is saying, Hey, we have this problem aware that, you know what, this is, this is a theme. How might you guys help address it so that that facilitator doesn’t have to kind of go be the rat. You know, snitches get stitches, right? I think that’s the, uh, the phrase. If you watch those mobster movies, so you don’t have to go be the snitch per se, but, but really, um, helping maybe connect people who, Hey, you know, you’ve said you’ve had this problem, are you interested if somebody else has this problem and can connect to them, maybe it’s a community of practice or an improvement community that forms around that challenge.
David Horowitz [22:03]: Yeah. And if you’re an executive or a senior manager at a company listening to this podcast, think of it from the other perspective, which is, well maybe this is a program you’d like to start setting up at your company because it will help to surface some of those broader organizational level impediments that you would not be aware of otherwise.
Dan Neumann [22:19]: That’s where I like some of the concepts around some of the scaling frameworks and this’ll be going out shortly after some of the, uh, we did a sort of a mini series on scaling. And so making those cross organization challenges known, um, so that it isn’t each team going off and maybe solving the problem themselves. If you can get some economy of scale where multiple teams are bringing that together.
David Horowitz [22:44]: It’s also a way to break that vicious cycle that I talked about earlier on in the podcast that if the biggest problem with Retrospectives is lack of follow through and at least some percentage of the impediments teams identify in their retros are not solvable at the team level, then having programs like this can also help give that positive feedback loop back to teams that yes, we are working on these issues and Retrospectives are helping to surface those issues. So keep doing it. This is, this is helping the company and your team.
Dan Neumann [23:10]: I think that’s a nice segue into the topic of focus. We talked about a couple options versus just having broad open conversation so you can have the post it notes to make sure that all the voices have a chance to get heard and .voting to kind of wean that there, uh, to widdle that list down to a much shorter list that you can talk about. Um, and then you were talking about focus, like where do we focus in the retro?
David Horowitz [23:37]: Yeah. So many teams focus on way too much and they do these surface level conversations for five minutes on each topic. Write down an action item on each one and call it a day. And of course, as people, we’re all resistant to change almost by definition. That’s part of who we are. So, uh, asking everyone, Hey, let’s change these 10 things. It’s almost certain that nothing will get changed as a result. So instead what I would recommend is having a much deeper conversation on a single impediment and then calling it quits for the Retrospective and coming up with just one hypothesis that you’re going to test in the upcoming iteration to see whether you can affect change with just one thing. And if the answer to that is yes and you build confidence, then okay, you can start talking about two things in your Retrospective, but narrow the scope down to the most minimal amount of impediments possible until you’ve proven that you can do more. And when you’re having these deep conversations, what does that mean, right? How do you have a deep conversation about something? Um, so there’s a bunch of facilitation techniques that I can recommend, but in general, the idea is to do something called root cause analysis. So you’re going to have an impediment, uh, and you’re going to ask people to dig deeper. Why is that a problem? There’s a technique called five whys where you just keep asking why until you get to what the team considers to be the root cause of the issue. There’s another technique called fishbone, um, which I’m not gonna get into the details in the podcast. You can look it up, but it’s a great way of figuring out what are the real causes of the problem that are happening here. And then what I’d recommend after you come up with that, the core of the issue is to have everyone on the team go back to brainstorming mode where you say, all right, take the next five minutes to think to yourself around what are potential solutions to this problem that we just identified. And have everyone list them out. Again, on sticky notes. It’s almost like going back in time to the beginning of your retro, where you’re asking for people to brainstorm impediments. Now you’re asking people to brainstorm potential actions and you can .vote on those again, right. To try to figure out what does the team have energy around, uh, in terms of what they’ll actually work on going forward. And so that’s a general framework for a much deeper conversation inside a Retrospective that can help the team affect change more frequently.
Dan Neumann [25:46]: So what you’re describing is a mix of the diverging coming up with lots of things and then converging it down and then diverging again.
David Horowitz [25:53]: Yeah the double diamond diagram that everyone talks about. Yeah. You want to allow people, whenever you’re coming up with a list, you want to diverge and an eight create space for divergence before converging on a potential solution.
Dan Neumann [26:08]: Yeah. I have found some pretty good value out of the five whys and that fishbone. And I think also maybe people would know it as Ishikawa. That’s correct. Okay. Yup. So test out my, uh, my Japanese names out a little bit. But yeah, named after the person who kind of popularized it or came up with that. What do you do then? So if you’ve got this list of lots of things you might do, where do you go with that? And you were talking about some, some calculating some value out of these.
David Horowitz [26:39]: Yeah. So what is the expected value of an action item? All right, so a lot of people have probably heard of the ice prioritization framework, uh, which ice, I.C.E .
Dan Neumann [26:50]: So that one’s not, it’s not ringing a bell right now. So what’s I.C.E.?
David Horowitz [26:54]: so I.C.E. Stands for “I” stands for impact. The “C” stands for cost and the “E” stands for effort. So the idea here is maybe you use t-shirt sizes. So relative sizing to rank your possible action items based on how much impact they’d have, how much cost they’d have. And that can be money or it can be any other measure of cost you can decide on by your team. And then effort, how much effort will it take for you to actually do this action item? And through that you can rank your potential action items to get a general prioritization of which ones should we try first. So that’s a good place to start, but I’ve actually found that not to be as successful as you might think because it’s missing one key component, which is this, this rule that I like to follow in any meeting, which is to follow the energy. So I learned this also from Esther Derby, so one of the authors of agile Retrospectives, and she talked about how if there’s no energy around something that you’re discussing in a meeting, then you’re probably wasting your time. And similarly, it’s true with action items. If there’s no energy around the action item that you’re potentially going to prioritize. If no one is interested in owning that action items so that it actually has worked on, it won’t get done. Irrespective of how much impact do you think it’s going to have, irrespective of how much costs or lack thereof, it might have and irrespective of how much effort it might take. If there’s no one who wants to work on it, it won’t happen. So use I.C.E. to get a general sorting of the potential action items, but then ask people to .vote on energy. Maybe give everyone three .votes and say, okay, put anywhere from zero to all three of these .votes on any of the action items that you personally have energy around working on in the upcoming Sprint and you’ll get this interesting graphical visualization of where the energy and the team sits on an action item and it might be that the action item you end up working on is the one that has low impact, high cost and high effort, but if that’s what actually would get worked on, great, that’s better than working on one that won’t get work done.
Dan Neumann [28:57]: Yeah, it’s counter intuitive that way, but related to these Retrospectives and yeah, that for that Sprint might not be the most valuable thing to do, but it’ll get done. I love short Sprints because guess what, in one, two, three or four weeks or a month, you’re going to be back doing it again. It’s not a one shot deal. You’re not. This is not the one change for the next year, hopefully.
David Horowitz [29:21]: Yeah, and I’d actually argue it is the most valuable thing to work on because the expected value of an action item has to do with how, what are the odds you will actually do anything. Right. So if the odds are low, zero if anything times zero is zero. So if the odds are zero that you’ll work on it. It doesn’t matter what else is involved with that action item. So that’s a way of of figuring out how to break that downward cycle of lack of follow through by following the energy in the room.
Dan Neumann [29:49]: That’s why I bailed out on the math minor I was pursuing at one point. That whole zero thing.
David Horowitz [29:53]: Really confusing.
Dan Neumann [29:58]: So we’re going to follow the energy where you’re going to get some things done, knocking them off one at a time.
David Horowitz [30:03]: Yeah, exactly. Focus on one thing and that one thing should be where the team wants to focus.
Dan Neumann [30:08]: I love it. So anything else maybe that we should touch on Retrospective related?
David Horowitz [30:15]: Um, we touched a little bit on this concept of upleveling the impediments that your team’s experiencing that it can’t solve. One other thing that I’d like to share cause I’m really interested in this right now is you know, in agile we talk about information radiators. So you might have a burn down chart that you’re radiating to your team. Uh, there could be a whole variety of information radiators that you have, but people don’t talk in my opinion, enough about radiators coming out of the Retrospective. So people talk about, um, uh, what happens in Vegas stays in Vegas as a rule for Retrospectives, which I get the intent of that, right? So the intent is to keep the psychological safety for the team there that you shouldn’t just talk about what was said in the retro. It makes people feel safe. Great. But that rule is not exactly right to me because in fact, if the team has identified an impediment that it can’t solve and has opt in on a volunteer basis said yes, we want to share this transparently with others in the organization, then in fact, the opposite rule should be true, which is you should have someone who is like the town crier, right? Someone who is out there shouting at the top of their lungs. This is blocking us from getting our work done. And if you follow this, what happens in Vegas stays in Vegas, rule to a T, you’ll never do that. So one thing I like to do when I close Retrospectives is ask the team what out of everything we just discussed should we talk about intentionally, frequently with everybody in the organization as often as we possibly can? And if the answer is none of it, that’s fine. There’s nothing wrong with that. But possibly they’ll say, well, this one thing we want to talk about all the time to everybody and then someone should do that. Um, how you do that at scale is a different question for maybe a different day or different podcast, but radiate the, that information out intentionally as a way to close the retro, I think can help break that downward cycle again of lack of follow through. Uh, retros descend into this complaining session all the time. Let’s break that. Let’s not do that anymore.
Dan Neumann [32:07]: Agreed. Agreed. The information radiators can be powerful. So I’ve had teams where they’ve hung their impediments on a list outside of their, their collective work area. And what you’ll see is teams will go by and they’ll be like, Oh man, I actually didn’t know our team was blocking you. And you know, they could have been emailing back and forth for ad nauseum, but, but just having that information radiator up or if they want to do pair programming, put the chart on the wall and track how often you’re pairing and who’s pairing with whom. Or maybe it’s a list of your improvements so that you know, at the end of the weeks, months, quarter, whatever, you look up and go, Oh, we have made some improvements and lots of good value from that.
David Horowitz [32:46]: Yeah. Imagine what would happen if this became the company culture. So every time you walk down the hall, you saw all of these, we call them Retrospective radiators, you’re radiating out anything that you think is, is helpful to radiate from the team. It could be impediments or learnings or questions or, or our solutions, things that have worked for you. It doesn’t matter. And every time you walk down the hall to go to the next meeting, you can just digest all this information that’s radiating out towards you from all these teams. It becomes a very, it’s a very positive culture. One that builds trust and also leads to greater effectiveness because you will start to realize that, Hey, my team’s experiencing this problem, but team B over here has solved it. I should go talk to someone in that team and have lunch with them. That’s a very impactful thing.
Dan Neumann [33:26]: Yeah. That conversation starter, Hey, what’s that? Or how did you do that? Or us too, you know, that goes a long ways.
David Horowitz [33:34]: Fantastic. I love it. I wish everyone did this.
Dan Neumann [33:36]: Yes. You know, agreed. Well, time has flown for me and hopefully for folks that are listening, we wrap up usually with what are you learning? What’s maybe got you as part of your continuous learning journey these days?
David Horowitz [33:50]: Yeah. So at Retrium we’re of course trying to build whatever it helps people run more effective Retrospectives. And so we have this huge list of requests and ideas that we have and we’re trying to figure out how do we prioritize our own backlog. And so we as a company, we’ve started to read this book called Badass: Making Users Awesome by Kathy Sierra. And we’re just about halfway through or so. So I don’t have any final words about the big key takeaway yet cause I haven’t read the whole thing, but I’m enjoying so far the reframing that Kathy does of the point of your product is to help users get better at whatever it is their solution is that they’re looking for. The example she gives for example, is do you buy a camera? You’re not looking to take photos, you’re looking to capture moments, right? And so how do you help people capture moments in a way that will resonate with them or that they can share with family and friends, not how many megapixels are in the camera. Right? And so how can you translate that type of, of the way of thinking into our own product is something we’re looking through and kind of talking about inside Retrium.
Dan Neumann [34:50]: That’s an interesting mindset cause to, to piggyback on the camera thing, you know, how fast can you get the camera out and make it available to capture that moment. You know, cause he had megapixels are a thing, but it’s that whole experience of is it big enough to take, is it so big you can’t take it with you or you know, is is a large camera appropriate for certain types of moments? Yeah. I think it should create a really deep conversation.
David Horowitz [35:13]: Yeah. Trying to solve problems instead of building features. I like that mindset shift.
Dan Neumann [35:17]: That’s crazy talk. So yes, we should be solving problems with our software, like delivering valuable software frequently is our highest priority.
David Horowitz [35:26]: Who heard of that before?
Dan Neumann [35:28]: Is that one of those agile things, I don’t know what’s this agile thing? Yeah, well it’s good. Well, hopefully people who are interested in agile keep listening and yeah, if they’ve got topics they can send them to us and we’ll respond to those customers too. So we’ve got all that information in the intros and the outros. So Hey David, I appreciate you taking some time to share on the topic of Retrospectives today.
David Horowitz [35:50]: Thanks so much, Dan. I really enjoy being here and if you want to get in touch with me, my email is firstname.lastname@example.org or hit me up on Twitter. It’s @DS_Horowitz. Thanks Dan.
Outro [36:12]: This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions, and information expressed in this podcast are solely those of the hosts and the guests and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.
Contact us to share the challenges you’re facing and learn more about the solutions we offer to help you achieve your goals. Our job is to solve your problems with expertly crafted software solutions and real world training.
For a better experience on the web, please upgrade to a modern browser.