It’s Friday, the last day of the sprint. The team has worked hard to get their burndown chart looking good, they’ve received good feedback from all their demos and the weekend is nearly here, but there is a tension in the air. “Oh god,” they’re thinking, “it’s almost time for another retro”.
It’s a common narrative that developers hate retros and it’s your job to corral them so you can check that box and help the team grow, but retrospectives don’t have to be a painful process if they are facilitated in a structured, respectful and light-hearted manner. Here are four things you could be doing wrong when you’re running sprint retrospectives, and what you can do as a scrum master to fix it.
The attendee list is too big
This could be due to a couple of reasons:
- The team itself is too big. For optimum performance, scrum teams should max out at about nine or ten people, including the scrum master and product owner.
- There are people attending your retros that aren’t part of your core scrum team. This is arguably a more serious and urgent problem.
Why this is bad
When there are a lot of people in a meeting, it doesn’t give much opportunity for everyone present to say their piece. Because the purpose of a retrospective is to gain feedback on the state of the team, it’s important for every team member to have the opportunity to speak up. Otherwise, the overall direction of the team will be skewed in favour of only a portion of its members and the more quiet and shy team members will be left behind.
Additionally, there is a reason the invite list to a team retro is held as sacred in the Agile world. Team members can’t speak as openly as they would otherwise if the retro is opened up to people outside the team (especially managers). If team members are afraid to speak up, retrospectives become a performance for the spectating attendees and the feedback collected is less likely to be useful or directly actionable. If your team has managers outside of that team attending their retrospectives, they are being micromanaged.
What to try instead
Due to the sensitive nature of this issue, it may be appropriate to follow up on this issue privately – use your own judgement here. If the team is too large, it is worth getting with the leader of your engineering org to see if they can be broken out into smaller teams.
Likewise, if there are external parties attending your team retros, they need to come off your invites ASAP. You are still encouraged to share a (possibly filtered) summary of the team’s discussion points after the retro with those external parties after the meeting, but the meeting itself must be a closed, safe environment in order to be effective.
Some teams may feel stifled if the product owner is present for this ceremony because they are more business- and sales-oriented than they are technical, so it may be valuable to consult with your team lead and product owner about whether the product owner’s attendance really is mandatory for the team’s specific use case.
The devs are bored
Often, there can be several contributing factors in play:
- There are only a couple of team members taking the floor for the majority of the ceremony.
- The team doesn’t understand the purpose of retrospectives.
- Team members have had a bad experience with a previous employer or scrum master.
Why this is bad
This can be a rather self-serving issue with your retros. The factors listed above and others can lead to disengagement, which leads to boredom, which can ultimately lead to resentment towards leadership for mandating that things are done “Agile” or towards you for being the face of the recurring meeting they dread.
Bored team members are not engaged team members. Retros don’t have to be an absolute riot every time but it is important to keep your team members engaged in order to provide a more sustainable, productive environment.
What to try instead
If you’re noticing one or two team members tend to hijack the conversation, call on other team members and ask them one or two open-ended questions based on the current discussion item. You may notice that once the ice is broken, team members are more willing to participate for the rest of the ceremony. Here are some prompts you can draw from:
- How did this affect you personally this sprint?
- Why do you think the team ranked this item so high/so low this time?
- If it’s something the team did well: who did you notice in particular that contributed to <thing that went well> and how did they do it?
- If it’s something the team could improve on: what do you think the team could do to handle <thing that could be improved> next time?
If you’re feeling mischevious, add a “retros are boring” card to the retro board. This will at best spark some useful discussion you can use to pinpoint the issue, and at worst lighten the mood of the retro and encourage people to open up for the rest of the meeting.
The retrospective is too long
Any training course or online resource will tell you that for every two weeks the sprint lasts, the sprint retro should be scheduled for anything between an hour and 90 minutes. For example, a two week sprint should have a 1-1.5 hour retro, a month long sprint should have a retrospective between 2 and 3 hours, and so on. This can get a bit ridiculous the longer your sprints are.
The problem with having a mandatory length for this ceremony is that it encourages you to extend the duration of it by trivial or artificial means.
Why this is bad
Gameifying your retros can be fun and interesting under certain circumstances, but for the most part bringing legos or feelings jars into your retrospectives infantilises your team and tells them you don’t respect them. One of the most critical aspects of a scrum master’s role is to build trust with the team so that they are comfortable bringing up issues or blockers, and that trust won’t come if your retros consist of childish games and kum ba yah circles.
What to try instead
Treat your developers as professional adults and allow discussion on each item to end naturally. A good cue for when to move on to the next card is the creation of one or several action items; it promises the issue will be resolved, and once it’s taken care of no further discussion is necessary. If the action taken was really impactful, you may even see it appear as something that went well in your next retro.
There is nothing wrong with a simple whiteboard listing areas of “went well” and “to improve” plus a handful of pens and sticky notes. The reason this is the standard approach to retrospectives is because it’s effective, actionable, and easy to remember.
There is not enough variety in your retros
This does not mean you have to up the ante every sprint, nor does it mean you have to take a different approach every time. If your retros are characterised by the same discussion points appearing over and over again, then your retros are lacking variety.
Why this is bad
It’s frustrating for everyone to have the same discussions and draw the same conclusions over and over again. Not only is it a waste of time, it’s incredibly demoralising and will leave your team feeling underappreciated and misvalued. This can contribute to burnout and harm your organisation’s ability to retain good talent.
A lack of variety in the discussion items that come up in your team’s retrospectives is indicative of a larger problem: either leadership is not supportive of the suggested changes, or the team is stagnating.
A sprint retrospective should be a tool used to drive positive change; it is not a platform for people to point fingers or vent their frustrations to the team (unless it is followed up by some action). Without action, retrospectives are pointless and the team has nothing to look forward to.
What to try instead
If it’s an issue of unsupportive or unaware leadership, take some action items to follow up directly with your manager or a supportive ally in a leadership position on why you’re not seeing movement. Be sure to emphasise the urgency of the issue and the effect it’s having on morale in your organisation. If appropriate, pursue it in the same way you would address a blocker – don’t let go of it, and give your team regular updates in the daily scrum/standup until you see some movement.
If the issue is stagnation within the team, you’re going to have to do some digging and it’s best addressed right there in the retro. Is the team so overloaded that they don’t have the bandwidth to address ongoing issues within the team? Speak with your product owner about reprioritising to make room to address these issues. Is it a recurring code issue that requires greater architectural discussions? Get some initial ideas, then take an action item to schedule it and use that feedback to help you build your agenda. Are your team members in too many meetings to get any real work done? Find out which of those meetings can be postponed or cancelled. As a scrum master, it is your responsibility to act as a barrier between your team and the fickle demands of the rest of your organisation.
A sprint retrospective should be a tool used to drive positive change. It’s important to keep in mind the purpose of the retrospective as you facilitate it. The point of a retro is to look back on how things went over the last couple weeks, figure out which successes are repeatable and which problem areas should be addressed so that the next sprint is smoother, less stressful and more productive.
Meetings don’t always get hate so much as pointless meetings do. If your retros are resulting in quality of life improvements for your team on a consistent basis, they will always be an engaging, thought-provoking, fun exercise.
Comments are closed.