Retrospective as a silver bullet
Frankly speaking, you won’t have a good process if you don’t have retro practice. How can you build a close-knit team who knows what they do and why they do it if they have no time to stop at the moment and focus on it?
We all know that the main aims of retro are to analyze past sprints and make a “to do” plan based on good/bad/need improvement. This is just the tip of the opportunities iceberg. Let’s talk about interesting details with which you can refine your retro:
Always say the goal of the sprint
First, after welcoming the team, we need to say the purpose of the sprint. This is really important so that everyone can concentrate and tune in. Using the aim (if the aim was built correctly), I can grab their attention. It returns my team to the start when I set this goal on planning. At this moment, we are enhancing the team's responsibility skills by a clear sense of completeness. Starting from your wins like a team lays a great foundation: “We are cool because we achieved the goal of our sprint. Let’s talk about what we did great!”.
Break the sprint into pieces during the retro
Use it when you are with your team, start gathering data, try to go consistently. This is really helpful because, at retro, we used to focus at the end of a sprint on account of the fresh memories (maybe the most emotional ones). I divide the sprint into three conditional parts: beginning, middle, and final. Talk about the process and approaches based on these parts. If your team is experienced, you can do a graph of the task’s life cycle to research the sprint deeply. This way, the probability of missing something is declining.
Analyze the previous sprint goals at the end of the retro
One of the most common mistakes I did too, is to start retro from analyzing the previous. The facilitator should endeavor to save team concentration on the present. Otherwise, you will constantly walk on the same trodden path. Undoubtedly this analysis is great and needs to be done, but the previous sprint has its own frames. It would be a good addition at the end of data collection. The team should decide which items will be continued and already achieved.
Get ready for a retro
This obvious rule nonetheless is the key to success. During the sprint, I, as a facilitator, try to notice situations, opinions, and processes to discuss. Nobody can remember everything except for the notebook. PM should not interfere in team decisions but can focus their attention on a grey stain. Prepare graphics, images, show the results and statistics.
Do crazy experiments
Keep things variated. Genius ideas were born from a mad world. Even if it sounds dubious, just set an experiment during the sprint. You should rely on your team, trust them. They should know that they make decisions. It’s in their power to change what prevents them from doing a great project with fun. Provide the key to unlock team potential: use boards, metaphors, analogies, games with a ball, etc., but don’t make your team learn long rules. Explanations of the game’s rules shouldn’t take more than 1 or 2 minutes (train it before the retro). The simpler, the better.
Someday I will write about the best experiments.
Change the environment
Try to keep your team meetings from being a chore. Retro will be interesting for your team if you change the environment, place, style, and sequence of questions. If one retro is much like another, you will lose focus. You can place a meeting in the park or yard nearest your office or sit on the floor in an office space. Guys in your team will have a discussion “ — We had talked about it during the retro. — Which? I don’t remember it. — When Lisa brought a ball, and we imagined that sprint is a pie”. The decisions we had taken were pinned to the atmosphere, and every retro was unique.
Post retro results
It is the most necessary thing that I have learned. The team should always have access to the retro's results and conclusions. Print the main goals and pin them on the wall in the office. Retro results should be shown in two types: actions and principles. Actions like “to resolve comments in Figma” have a performer who is responsible for them. Principles is an idea for all team members like “the last feature of a sprint should be sent to QA by the developer 3 days before the end of a sprint”.
Retro like a team-building
These principles will form the constitution of your team. While passing through an onboarding, every new teammate can get acquainted with the unspoken rules. It was built from the inside by the out-and-outer team. Therefore, a set of principles lays a great foundation for avoiding misunderstanding and adapting.
Check the health of your team.
It’s a great practice to include evaluating the team's health in retro. We use online services or card games to measure team satisfaction of the support (f.e. stakeholders) and resources, understanding the team roles or value that the team provides to the business, how much fun made the sprint at the list. Unfortunately, all of these things are hardly the first thoughts on retro. Corresponding indicators may increase awareness of background problems, and you may find a blind spot or a root of a problem.
Analyze retrospectives globally
Each retrospective isn’t isolated and should be analyzed globally. Use global indexes like the team's health or percent of a completed action (not KPI) involved process.
The main goal is to find stones that lie on the road — they need to be removed. For non-removable stones, you should find a solution such as bypassing them or making a hole through.
Go ahead. Retrospective for the greatest future!
