How can we have good retrospectives (about our Scrum Master)?
The podcast is BACK!
Today’s question comes from Stig, who is wondering how to help his team give honest and constructive feedback to their Scrum Master during retrospectives. We’ll talk about an approach you can use to help your team to break through the power imbalance that might be keeping them from sharing useful information with your Scrum Master.
Mentioned in this episode:
- Join my free 5-day Daily Scrum Challenge on June 12th. Start by checking out how awesome your current Daily Scrum is at http://DailyScrumQuiz.com
Like the podcast? I’d love it if you’d take 60 seconds to rate it in iTunes.
Do you have a question for the show? Submit it at http://GetAgileAnswers.com
Adam: Welcome to Agile Answers. I’m Adam Weisbart, your Certified Scrum Trainer and Agile Coach. Each week, I get your questions about Scrum and agility and I answer them here, on Agile Answers.
It’s official. I’m back. One of the questions I’ve been getting over the last many months is when the heck is the podcast coming back? You posted a message saying it was coming back in a week or two or a month, and we haven’t from you since. It’s been months. I will admit that my estimate was wrong. It turns out, estimates are sometimes wrong. My estimate was wrong because, of course, as a new parent, it’s taken me way longer to get everything back in order than I thought it would. So I was ambitious, I apologize. But now, I’m back and I’m here to answer questions.
I’m going to start by answering a question from Stig. This question might sound familiar to you, if you’re a Scrum Master or you’re struggling with maybe some things your Scrum Master is doing. So let’s hear from Stig and see if I can answer his question.
Stig: Hi, Adam. This is Stig from Denmark and I want to thank you for keeping up a great podcast. So here’s my question. I recently started out as a Scrum Master and one thing that worries me is honesty from team members at sprint retrospectives. The improvements discovered at a retrospective meeting might be centered around any of the team roles, and for a Scrum Master, it seems difficult to encourage honest feedback especially on your own role. It might be that the Scrum Master overlaps too much with the product owner role or gets involved with the development activities. I guess what I’m trying to say is as a Scrum Master, how do I encourage my team to bring up Scrum Master impediments so that I can be a better Scrum Master? Thanks a lot for choosing my question and have a great day.
Adam: That is a great question, Stig, one that I think a lot of people struggle with, honestly. So I have some suggestions for this. I actually have a favorite retrospective in this situation.
Now, the first thing I would mention, before doing this retrospective is that you should not do it as your first retrospective with your brand-new team. Your team should have a good understanding of the framework of a retrospective, perhaps the five-step framework from Esther Derby and Diana Larsen’s book, Agile Retrospectives: Making Good Teams Great. You should have modeled what a good retrospective looks like and taken your team through a couple of months’, probably, worth of retrospectives before jumping into this one, because this one can go wrong if your team is not sort of prepared for it.
The second thing I would make sure of before jumping into this retrospective that I’m about to outline is that you’ve build a decent amount of trust on your team. So if there’s not a lot of trust yet, I would focus, as a Scrum Master, on helping build trust across the team, which we’ll talk about in other episodes, but I would make sure that there is trust. And running good retrospectives, especially from that book, can go a long way towards doing that. If you’re not quite ready to do this, the retrospective I’m about to outline, don’t worry about it. You will be, in a month or two, I suspect.
So the first question is why do people find it hard to speak to the Scrum Master about these things? After all, they’re just a team member, just like everybody else in the team. I think the reason for that is that the Scrum Master role doesn’t really look like just another person on the team. What it looks like, if you’ve never worked on a self-organizing team with somebody who’s helping facilitate but not manage, it looks like the Scrum Master actually could be a kind of a type of manager, right. It’s the closest thing that we can link it to in our minds if we haven’t had the experience of working on self-organizing teams.
So I think people go in with this mental model of the Scrum Master is not just a normal person on the team, they’re someone above us. There’s some hierarchy there. So this next retrospective, I think, is very useful in helping break that down to get everybody on the same level, which, it turns out, they are, but I think that we have to do something to help people break that down in their minds so their mental model matches what’s really going on.
So the retrospective I would run is called the Hot Seat Retrospective. The Hot Seat Retrospective works with everybody sitting around the Scrum Master. So if you have a room in which you could form a circle, I’d put chairs in a circle as a Scrum Master, invite everybody in for the retrospective, everyone has a seat. And then you, as a Scrum Master, have a seat in the middle of the circle. Your job during this retrospective is not to facilitate, not to say brilliant Scrum Master things, it’s to be totally silent. You’re to be totally silent because your team is going to give you feedback about how it is to work with you as their Scrum Master.
Now, before you do this, of course, you would set the stage for this retrospective. You would have some working agreements reminding people that retrospectives, of course, are about helping figure out how we can improve as a team, not about blaming people or taking people to task. This retrospective will not work well if your team just wants to beat you up, figuratively. But it does work well if they would like to give you honest feedback about the way your work is impacting theirs.
So you sit in a circle, you sit in the middle of it as a Scrum Master, and you simply listen very deeply, you concentrate very much on what your team is sharing with you. You acknowledge them, perhaps by nodding your head, letting people know that you are taking in the feedback that they are giving you.
Now, this might seem like it’s not doing a lot, because you are there silently listening, but it’s doing two things. The first thing it’s doing is helping break down that mental model that the Scrum Master is somehow above the team. The Scrum Master is an equal of people on the team, and therefore, they can receive feedback like anybody else on the team. And by not responding as a Scrum Master, by not defending yourself, this isn’t an argument, it’s just I’m listening to the feedback my team has for me so that I can figure out how I’m moving forward to improve.
Now, this might spur other conversations down the road with your team. It’s perfectly fine to talk with individuals or groups or the whole team about the feedback you’ve shared after you’ve figured out, or they’ve shared, after you’ve figured out how you would like to approach resolving those things or helping the team, if that’s necessary to have those conversations. You can certainly do that. But this retrospective is not the place for it.
This retrospective is simply the place to receive this feedback, listen to it, and let the team know that you’re there for them, you’re listening, and you’re not there to defend yourself or advocate for your position. Because after all, the Scrum Master’s job is to be detached from particular outcomes, to be a good facilitator, right? So they’re going to listen, and they’re going to take it in, and then they’re going to go back and help their team in the sprints.
So that’s my favorite retrospective for helping break down this issue.
The other thing I would recommend, and I’ll happily put a link to it on the show notes, is the Scrum Master’s Checklist by Michael James has some items in it that I think would be helpful in this case. If nothing else, giving it to your team and saying, “Hey, please, each of you, fill out a copy of the Scrum Master’s Checklist. It helps identify what areas I could be helping you more in, in our sprints.” And because they don’t need to put their name on that and such, it can be anonymous. That might be helpful for you. I actually don’t think that anonymous feedback, in the end, is super helpful and we’ll have an episode and a little bit of time here talking specifically about that. But I do think that it’s not a bad place to start.
So if you did not have a ton of trust on your team yet, and you thereby were not ready to do the retrospective that I just outlined, you could do the Scrum Master’s Checklist and have it turned in to you anonymously. The feedback from those surveys, you can use to adjust your work, to plan what you are doing moving forward to help your team. And I believe that as you correct these things, and as you help your team with these impediments, as you resolve them, your team will see that you’re actually taking action towards the things they requested in that survey. And because of that, because of that, you’ll help build trust. And I think you’ll get into a spot where you are ready to actually help them via this Hot Seat Retrospective.
I will tell you, when you do the Hot Seat Retrospective, the first time I did it, it was super uncomfortable. It’s not called the Hot Seat Retrospective for no reason. But you can totally survive it. It wasn’t actually a bad experience, and I don’t believe that it was as uncomfortable as I made it up to be in my mind, certainly, nothing bad came from it. It was very useful. But if it feels uncomfortable to you, it’s all right, That’s why it’s called the Hot Seat Retrospective.
Stig, thanks so much for your question. Just like everybody who submits a question to the podcast, you will get a deck of my Agile Antipattern Cards in the mail.
If you’ve got a question that you would like answered on the show, just like Stig had his answered here on the show, please go to GetAgileAnswers.com. Right there on the home page, you can click the Submit a Question button and record a question that I might answer on a future episode. If I choose to answer it at a future episode, you’ll get a deck of my Agile Antipattern cards as a thank you for contributing to the show. And if you don’t feel like recording the message, because you don’t want people to know who you are, you want to stay anonymous, you can totally do that. No problem. Just submit your question on the form there and click the button that says, “I want to be anonymous.” You can just type it into the window. You don’t even have to record your voice.
Thanks for tuning in, and I’m so sorry for the long delay. I’m really excited about my episode coming up next week. It’s already in the works. I look forward to chatting with you, both in person, when I run into you at conferences, and here on the podcast. Thanks for tuning in. Stay agile. Never change.
How do we make sure we have cross-functional teams and why does it matter?
What agile practices can you recommend to our game development studio?
How do we remove silos when doing government contract work using Scrum?
How should we form new Scrum teams?
When’s the podcast coming back?
How do we self-organize if our boss is on our team?
How do we deal with constant interruptions to our Sprint?
Can a User Story be too long? Ours seem insane!
Can our Scrum Master and Product Owner be the same person?
What 1 simple thing can I do to improve my coaching & scrum mastering?
How do I get hired as a ScrumMaster if I’ve never been one before?
Our team wants to be more agile. What agile process is best?
How do we improve our giant, multi-team Sprint Review session (or Sprint Reviews in general)?
What are some creative & effective ways to make Retrospectives more engaging?
Will this hurt my Daily Scrum? And how do we deal with “non-dev” work?
How do I escaped the dreaded ‘Scrummerfall’ trap?
How do you help PMs and Managers not fall back into their waterfall ways?
Our teams keep changing. How do I set guidelines that keep teams together?
How do you make sure your team has time to make the improvements they identify in their Retros?
When should the business stakeholders get help from the dev team to get items ready for work?
How do I energize a demotivated Scrum team?
Mic Check! 1…2…3…