The Sprint Retrospective
Why and What?
Written by Melika Džindo, Project Manager at Softray Solutions
Lately, I have seen that some scrum teams are not running the Sprint Retrospective. For different reasons. Some teams are firmly convinced that the Retrospective is an “unnecessary ceremony” because “there are already enough events in the Scrum in which they can inspect and adapt” others “understand” the purpose of this event. Still, they would rather skip it from time to time “to get work done,” some of them believe that it is a waste only for them because they put the responsibility of performance outside of their team and think that “there is too little they can improve from their side,” and so on. I think many good examples of ScrumButs are presented, especially if we strive for Professional Scrum.
Allow me to remind you why we have the Sprint Retrospective in Scrum in the first place.
We know that every element of “the Scrum Guide serves a specific purpose that is essential to the overall value and results realized with Scrum.” Therefore, if we leave some aspect, like this event, it will “limit the benefits of Scrum, potentially even rendering it useless.”
Secondly, the Scrum Guide describes this event as an opportunity for the teams to inspect “how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.” So, if we are not running the Retrospectives or not running them every sprint, we are missing our chance for improvement in everything mentioned — every sprint!
Let me share with you five things I realized while I was running this event. It is something I have in mind and helps me to facilitate the Retrospective positive and productivity, allowing the change to happen within my teams.
#1
Form matters.
Essence over form is my way of thinking in general. But when it comes to the Sprint Retrospective, the chosen form is vital because it directly affects the success of leading this event and everything else agreed upon.
Can you run the Retrospective with the team onsite, or will you need an online collaborative tool? Where will you “store” the action items? How will you track the progress of the action items? Those are just some questions.
Invest the time to consider the most appropriate, regarding the overall context. Then, discuss it together with the team. Experiment with the options. Inspect and adapt based on your needs and preferences.
#2
Powerful questions.
People usually have beliefs and assumptions that might stand in the way of their improvement. So to allow the change to happen, you need to start asking powerful questions that will reveal people’s beliefs and assumptions and challenge them.
“Why do you think that,” “What needs to happen to let go of that belief?”, “What will happen if it turns out that you were wrong?” are some of them.
Some people might become frustrated by these questions, so before you start asking them, explain your intentions to the team. Then, ask for the team’s permission to allow you to help it reflect and learn by asking.
#3
Prioritize changes.
For all changes that suppose to improve the team’s work, I would highly recommend introducing them immediately because any prolongations might complicate the team’s work even more. But, if you are dealing with too many things at a certain point and there is a risk of losing focus, prioritize them just like your Product Backlog Items. Discuss on the team’s level which change might bring in the short notice the most value or what can improve your quality and effectiveness with the least effort, and focus on those first.
You will need to prioritize and introduce improvements incrementally to keep changes manageable. Still, you will also motivate people because they will see how minor improvements accumulate over time into a larger one.
#4
Learn by valuing mistakes.
When you are dealing with complex work, making mistakes is inevitable. However, learning what went wrong, applying that learning, and trying again will lead you to continuous improvement. That’s what Scrum is all about.
By valuing mistakes, you are creating safety for failings. When there is no safety, people try to avoid mistakes at all costs because they are afraid of punishment. And it is natural when people have to worry about whether they will be criticized or not that they will avoid trying new things or develop strategies to prevent uncertainty.
The Sprint Retrospective is the first place we should start cultivating a learning culture. Encourage your team after failure, explain why it is essential not to give up or try another shot, and share with them some of your personal or professional experiences from the past in which you’ve risen like a Phoenix.
#5
Energize it once in a while.
When you find the rhythm with your team regarding this event and everything that goes on, stick to it. Consistency reduces complexity, no doubt.
But, when there is a need to foster specific outcomes, it is also OK to vary the theme, the environment, and/or facilitation technique during the Sprint Retrospective. Be creative and experiment with the possibilities, but at the same time, try not to fall into the trap of making this event “fun” instead of focusing on actual improvements that need to be done.
For the end, please find a couple of additional ideas and practices of others that are also insightful. All this will help you to start running the Sprint Retrospective, improve facilitation skills and/or find a deeper meaning.
https://www.scrum.org/resources/how-facilitate-sprint-retrospective
https://www.liberatingstructures.com/
https://resources.scrumalliance.org/Webinar/keeping-retrospectives-fresh
https://www.funretrospectives.com/
If you enjoyed reading this, click the clap button so others can find this post.
