Webinar: Sprint Retrospectives Q&A

One of the great things about Scrum is its focus on continuous improvement. The Sprint Retrospective, or Retro, is just one of the ways Scrum bakes in opportunities for progress. Sprint Retrospectives happen last of all the Sprint ceremonies and is technically scheduled after the Sprint Review and before Sprint Planning of the next Sprint. The prescribed timing allows the team to review what happened and also gives them time to make changes and prepare for the next Sprint.

A few weeks ago, Agile coaches Reese Schmit and Braz Brandt got together and fielded questions about Retrospectives. You can find the video below as well as a transcript of the Q&A portion.

Sprint Retrospective Video

Sprint Retrospective Q&A

Q: When do you hold Retrospectives? Before Sprint Planning?

Reese: Definitely before Sprint Planning. There’s a reason why most of the books say to do Retros as the last activity. This is an opportunity to look back at the Sprint and see what held you back, what kept you guys from being awesome. So if you do that after Sprint Planning, you don’t have the opportunity to place these things in your backlog and you miss out on the opportunity to create actionable items and follow through with them.

The other thing is what if your biggest issue is predictability? Predictability is the main focus of your Sprint Planning sessions. If you hold your Retro after Sprint Planning, you have to wait another two weeks before you can really dig in and work on those things in a Sprint Planning session. You want Retros to be your cap on your Sprint.

Q: As the Product Owner, should I come to Sprint Retrospectives? I want the team to be able to speak freely about what they need from me. I think they could do that better if I’m not there.

Braz: There’s a couple layers to this question. As a ScrumMaster, it makes me start to wonder: Who comes to a Sprint Retrospective?

This takes me back to basic CSM classes: How many roles are there on a team? Three: A ScrumMaster, a team member, and a Product Owner. The Product Owner is a part of the team, and the whole team should be at the Sprint Retrospective. If we are going to get better as a team, if there are issues going on with how available my Product Owner is or his lack of authority, then I need to be able to talk to my Product Owner about that. If the Product Owner isn’t there, then we go from an introspective Retrospective to an extrospective Retrospective– meaning we’re looking for people outside of the room to solve our problems.

Then there’s another layer to this: As a Product Owner, I have this feeling that my team will function better if I’m not there. That’s where the ScrumMaster should ask, “Why don’t we feel comfortable when the Product Owner is here?” Then the Retrospective can focus on solving that issue, because without the PO there, you won’t have effective Sprint Retros.

Q: It seems like Retros become less effective over time. How do you keep them effective?

Braz: Non-effective Retrospectives can, in themselves, be a Retrospective topic! Part of your role as an effective ScrumMaster is to be that mirror for the team, to say “This is what I see happening, so what’s going on?” A Retrospective is a place to have those hard conversations.

So, make your Retrospectives more effective by retrospecting on your Retrospectives!

Reese: So meta.

Braz: Very meta.

Q: Are outside stakeholders and/or managers involved/invited? If not, who provides the download?

Reese: First, let’s talk about the download. Who is the Retrospective for? It’s for the team. There is no download. If the team wants to take notes or pictures of the board, that’s fine. But that’s for them to decide. This should NOT be a download for the managers. If they want to understand what’s going on, it should be a conversation.

As far as stakeholders or managers getting involved, that’s a slippery slope. I mean, I have no problems with my boss getting involved with my Retros because I feel comfortable saying things to him. But, not everyone is. Remember, you want to create a safe environment for everyone to speak freely.

If people don’t feel comfortable, they might have trouble talking about where they went wrong. They might skirt around the hard topics if the manager is in the room. So it should really only be the team in the room (Team, ScrumMaster, and Product Owner).

Q: I’m on a big team. 90 minutes tends not to be enough time for a Retro. What should I do as a ScrumMaster? The team is 12 people.

Braz: Big team–that’s my first red flag right there. Twelve people is too big. The size of the team should really be seven, plus or minus two. If you’re looking to have everyone involved and to have really vibrant and inclusive discussions, 90 minutes for a team of twelve probably isn’t enough.

So here’s my first question: Is your team really twelve people? Is everybody on the team really invested or are they just interested? Are some really just managers or stakeholders or outside folks that don’t necessarily need to be a part of the Retrospective? If we are actually a part of the team, my next question is are you actually one team? Maybe there’s some opportunity to split into two teams with two separate Retros.

Now, is 90 minutes enough for a Retro? If you’re having trouble with that, you need to start looking at the whether or not you’re actually following the five part format. Are you getting to everything you need to get to? Is the ScrumMaster flexing their facilitation skills, setting good time boxes, and driving those parts to conclusion? If we are doing all of these things, then maybe it’s a question of extending the time you spend in your retro. Take that question to the team, and see how the team wants to fix it.

Q: What strategies should we use if the team is not getting their action items to completion? What if the same issues keep coming up in your Retrospectives?

Reese: Be sure to check in at the beginning of your Retros and see where the team is at with previous action items. Make sure that those action items get put into the backlog so that you can keep your eyes on the prize. If you’re not following up on them, then come up with a solution to that as a team.

Q: What do you do if the team doesn’t participate?

Braz: Again, as the ScrumMaster, you don’t have to solve that problem. But, you do have to ask that question. The ScrumMaster needs to say, “Hey team, what’s going on? You guys aren’t asking questions or coming up with solutions,” or “You guys are saying everything is fine, but it doesn’t seem that way. What’s really happening here?” Ask those hard questions. Or ask individuals about why they aren’t speaking up.

Reese: At the same time, make sure not to alienate people that are more shy or introverted. Those people might not feel super comfortable in a room full of people. Remember, creating a safe space is key to an effective Retro.

Braz: Of course. You can find time outside the Retro when you can speak to that person one-on-one. And finally, the ScrumMaster can offer help. Ask the team (or the individual) about what you can do to help increase participation.

Q: Should the action items from the Sprint Retro become part of the backlog for the next Sprint?

Reese: Yes, absolutely. Now, make sure that you’re limiting yourself to only a few items. Not everything will fit in the backlog.

Q: What tools would you recommend for remote team members to become more effective and collaborative during Sprint Retros?

Braz: This is one of my favorite questions. My first tool isn’t a tool, it’s a mindset. How many Retrospectives have we been in where the entire Retro is spent with everyone on their laptops, not engaging. We have to be mentally co-located. If we aren’t mentally co-located then nothing is going to get done. It’s important for ScrumMasters to ask the team, “Are you guys actually here? Are we all fully present?” Once everyone is mentally checked in, everything else will get easier.

Now as for actual tools, I’ve used several. One way is to have everyone, whether they are physically in the room are not, message their thoughts directly to the ScrumMaster using whatever internal messaging system your company has. They can then sort through them and make sure everyone’s thoughts are being addressed. Also, take advantage of things like virtual whiteboards to give everyone on the team a visual. Innovation Games has some great tools to use in Retrospectives as well, with templates or the ability to create your own.

Q: How do you handle a team that believes they are high-performing and there is nothing to improve?

Reese: Sometimes, as a ScrumMaster, you have to ask the team to pretend for a second that they aren’t the best team. Now, what’s the most amazing thing, the silver bullet, that the team could do to really dig in and reach the next level?

Another thing you could do is a team health check. Atlassian has some tools out there to help you gauge the health of your team. Or you can use the team health check from the Agile Coach over at Spotify, Henrik Kniberg, which uses cards to create a visual of issues the team might be having.

Q: Do you think it’s a safety violation if the ScrumMaster makes it mandatory for each team member to answer every question on status updates?

Braz:  Safety is so easy to break. The best way to ensure you’re not violating anyone’s safety is to ask. As a ScrumMaster, you should ask if the team is comfortable with you reminding them when they forget to answer a question. Asking for that permission, asking for engagement in finding a solution, is huge. If you don’t have that engagement, you’ll run the risk of making team members feel uncomfortable. Discomfort can inhibit the team’s ability to really dig into their Retros and get real value from them.

Q: Do you recommend using Retro time to reevaluate working agreements and establishing/building team charters?

Reese: Again, take it to the team. See if they feel comfortable taking another look at those working agreements and team charters as a topic during the Sprint Retro. They might feel like that’s more of an action item to be worked on during the Sprint itself, in which case you want to make sure that you’re leaving space in your Sprint.

Usually when kicking off a team, you’re going to spend a lot of time in your first few Sprints figuring out things like team charters, definition of done, and so on. However, there might come a time when these need to be reevaluated. If the team thinks it’s a high priority, then using Retro time to do that is just fine.

Q: What do you do when the team assures you that there’s nothing in the Mad/Sad/Stop/Negative category?

Braz: This might be a good time to look at other types of Sprint Retrospectives. Try exploring other formats for gathering this data and generating insights.

You can also do a root cause analysis, like the 5 Why’s, on the statement “There’s nothing we could do better” to uncover some of the assumptions behind that sentence. (We talk more about the 5 Why’s in our article, Lessons Learned From an Ice Cream Social.) This gives the ScrumMaster the opportunity to challenge some of the assumptions and help the team uncover areas that could use improvement.

Q: Do you recommend Sprint Retrospectives before or after Sprint Review?

Reese: Again, I’m definitely in the camp of Retro after Sprint Review. You want Retros to be your cap on your Sprint so that you are able to implement what you learn from your Sprint Retrospectives immediately into your next Sprint.

Q: Reese mentioned a book earlier. What was it?

Reese: We’ve mentioned a few books on Sprint Retrospectives that you can reference, including Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen and The Retrospective Handbook, by Patrick Kua.

Q: Is there a format or agenda for a targeted Retrospective? For example, when you know there is a problem that needs to be addressed that may not come up in the start/stop/continue format.

Braz: There are a lot out there. You can look through the books that we’ve mentioned or explore resources like Tasty Cupcakes.

More importantly, is the ScrumMaster setting aside the time to research all of these methods and find one that fits the best. Make sure the activity you choose gets to the heart of the problem you’re trying to uncover. If you have a lot of comfort in your team environment and you have strong facilitator skills, the best tactic to get to these tough problems might be to just call out the elephant in the room. Ask your team directly about particular problems.

Q: Other than timeline, what are some other activities that are good for project Retros? What are the typical guidelines or standards for running a productive post mortem?

Braz: One of my favorite activities is the Amazon Review game. It helps you dig into what looks good and what doesn’t from a customer standpoint. The timeline works well for comparing the internal workings of a team and the external events (like holidays, weddings, or babies). Timelines let you see how the team is affected by external factors and learn how to prepare for the external factors.

Q: What are the typical guidelines or standards for running a productive post mortem?

Braz: First, I’m not a fan of the term post mortem. It implies that we’re looking at a project that is dead and no longer relevant. If we’re doing Scrum and Agile right, then we’re focusing on building vibrant teams not one-and-done projects. So don’t call it a post mortem, because the team is still there and still invested.

Q: Would love to hear ideas, possibilities, and pitfalls around scaling Agile–it would likely would fill another webinar.

Reese: It would probably fill an entire webinar! In fact, we’ll probably do an entire webinar on scaling Agile in the next few months! Our companies are growing and scaling is becoming more and more important. There are so many frameworks and techniques out there to help you with that.

If you’re doing Scrum, you can start holding Scrum of Scrums meetings. Make sure you start small and build from there. SAFe® is a very prescriptive Agile framework. It’s got everything figured out for you, you’ve only got to plug in and play. The framework for you depends on your team and your organization.

Q: What are your biggest takeaways from Agile 2017?

Reese: My biggest takeaway is that all those people who write all those book are real people. They’ll sit down and have a beer and a conversation with you. They’re coming up with new ideas and looking for real feedback. They’re just human beings just like us, they’ve just been doing Agile longer. They’ve just had more time to learn about what works and what doesn’t.

There was also a lot of focus on safety and team culture as a tool to create high-functioning teams.

I personally took what I learned about sketch-noting and visual meetings. Images are retained much better than words.

Braz: I’ve been amazed by these large conferences and the broad spectrum of people there are around this idea of agility. Whether they’ve been at it for awhile or they’re just dipping their toes into Agile, it’s amazing to see that we have such an inclusive community. You really can have a meaningful conversation with some of the biggest thought leaders in our sector. Being able to connect on a human-to-human level is so empowering. So thanks to everyone that’s a part of this wonderful community.