How to improve teams beyond the Scrum Retrospective event
By Bia Dimovski, BreakFree Solutions Senior Agile Coach
The sprint retrospective is the most underutilized event in Scrum. It's incredible how simple and yet challenging this Scrum event sometimes proves to be, especially for teams new to the Scrum framework.
If you are on a Scrum team, you already know the sprint retrospective is time-boxed for the team to inspect the processes, interactions, and tools used during the sprint and find ways to improve their effectiveness. Iterative discussions around processes and collaborating practices directly and positively impact the quality of the work in upcoming sprints.
I have worked with teams who understand the benefits of a sprint retro and use it as a tool on their continuous improvement journey. I have also worked with teams who view the sprint retro as a chore, or another meeting to sit through, or something teams should perhaps opt out of as in: we'll get to it next time...
Both instances need consistent follow-through to capture and nourish the true intent of a sprint retrospective. Why? Because if done intentionally, out of the five Scrum events, the sprint retrospective is a driving force behind mature teams.
So how do you make sprint retros intentional?
Break them down into the following two areas of focus:
Mindset
Game-on approach
Sprint Retro Mindset
As a Scrum Master, work with your team to build a mindset that focuses on continuous retrospect and habits that support that mindset throughout the sprint. Encourage your team to bring up topics that affect how the team collaborates throughout the sprint, not only during the retro.
Teams often think of the sprint retro as the fluff Scrum event you do; you know... after the important work (aka, development) is done! They hardly even realize that the sprint retro event sets the stage for improvement and minimal interruptions in doing the important work in the following sprint.
Continuous retrospect mindset focuses on the purpose of the sprint retro prior, during, and after the scheduled retro meeting time. Creating action items resulting from the sprint retro event is a good way of building shared accountability among team members for their continuous improvement throughout the sprint. When done well, retrospect is a seamless part of the team's collaboration - it's how the team operates.
If the team is supposed to retrospect throughout the sprint, why do we need a designated sprint retro?
The purpose of a scheduled sprint retro event is for the team to have an uninterrupted discussion about anything they have observed throughout the sprint that needs everyone's attention – something they can’t focus on during the sprint. However, the actual work as a result of the retro discussion happens after the time-boxed event ends. It occurs throughout the sprint as part of product development. The time-boxed event is only one part of the sprint retrospective.
Most sprint retrospectives focus on the perpetual questions: what went well during the sprint, what didn't go well, and what we can improve? That is fine and in alignment with the Scrum guide. But where most teams get stuck is how to use these questions to help them grow. What ends up happening is team members feel that if they answer those questions, the retro is complete. And this is how the sprint retrospective becomes underutilized, with nothing tangible to take into the next sprint.
In this scenario, what the team discussed during the sprint retro stays in the sprint retro. After the sprint retro, no one actively focuses on "what can we improve" during the sprint — that was left at the door when we closed the event, perhaps until the next retro session. This is because many teams hardly associate retrospect with actively doing something. The "what can we improve" turns into a few well-intended statements that fade away as the new sprint starts.
Instead, work with teams to think of the sprint retrospective as an ongoing concept with a dedicated, recurring, time-boxed event for iterative discussions around ways to improve working together as a product team. I like to call this concept retro-forward.
So how can teams turn things around? How can this retro-forward concept come to life? Think: Game-on!
Game-on Approach
In their book “Gamestorming,” Gray, Brown, and Macanufo explain the difference between a play and a game.
A play is a self-fulfilling activity. There are no predetermined elements aside from what you make as you go. A game, on the other hand, is an activity that has predetermined space, boundaries, rules for interaction, artifacts, and a goal. Depending on how you facilitate a sprint retro, each of the elements of a game may be present, but the retro feels more like a play.
Why? Because there are two essential elements of a game that, when it comes to sprint retros, more times than not, get lost in transition — the goal and the artifact. The artifact lacks focus on the goal, as well as accountability for the outcomes.
Yes, teams may solve for what went well during the sprint, what didn't go well, and what they can improve, but everyone forgets why they are solving these questions during the sprint retro. Every sprint retro needs a goal and an artifact. I call this a game-on approach.
A game-on approach opens the door to finding creative solutions to any topic a team needs to discuss and make decisions on. It maintains a level of accountability for what every product team aspires or should aspire toward — continuous improvement. A sprint retro with a game-on approach is all-encompassing (pre-; during-; post retro) and goes something like this:
Before the scheduled sprint retro event:
Scrum Master – remind the team to come to the retro with a reflective mindset and discussion-contributing attitude.
Team – show up to the sprint retro event with a reflective mindset and discussion-contributing attitude.
During the sprint retro event:
Scrum Master – spend the first 5-10 min nailing down a goal for the retro based on the ideas/topics/issues collected throughout the sprint.
Scrum Master – don't just facilitate the retro! Be an active listener and a thought-provoking inquisitor during the retro event.
Scrum team – do not close the sprint retro without an artifact. There must be at least one process/interaction/tool-related outcome the team can be held accountable for experimenting with in the next sprint. Find it and include it in your artifact.
Scrum team – decide how you will incorporate what's in your artifact into the next sprint.
Scrum team – how will you hold each other accountable for what's in your artifact?
After the scheduled sprint retro and throughout the sprint:
Scrum team – start incorporating what's in your sprint retro artifact into the new sprint right away.
Recommendation: If it makes sense, create an item, keep it at the bottom of your sprint backlog, and include it as part of your daily standup.
Scrum team – collect ideas/topics/issues that need longer than 3 minutes to discuss and solve. If you are unsure, involve the Scrum Master.
Recommendation: Have a central area for everyone on the Scrum team to dump these items as they come up (group chat or a board visible to the team only). This way, everyone can look at the topics before the retro event, so no one is surprised by any of the items.
Have you tried several different themes and fun techniques to engage your team during a sprint retro with very little improvement in how your team operates? Maybe it's time to reshape your approach to sprint retrospectives. Perhaps it's time you explore the possibility of the sprint retro as a sprint-long concept that expands beyond the time-boxed event.
Suppose that's where you are; great! We can meet you there. Reach out to us, and we can get started.