Anything that happens again and again without a small change gets boring for a while. Retrospectives are discussions where teams share their fair share of improvement ideas to make themselves better equipped for upcoming sprints. 

Though it may sound easy in words about improvements and focused outcomes, the team needs to discuss it openly. A facilitator needs to be creative while running a retrospective event. There are different ways retrospectives can be run. 

It needs to be fun and needs to have focused outcomes. Also, different techniques can be used to achieve different results. 

Let us see what some of the ways are:

Dot Voting 

When teams passionately discuss ideas, a lot emerges. There will be tens and hundreds of thoughts coming up. We cannot consider them all to be implemented immediately in the upcoming Sprint. So, we need to choose. 

• Have the team put their ideas on the board; alternatively, they can use stickies as well. 
• Have them put everything on the wall or the board. Instruct the team to grab markers and place a dot on the idea, that they think is a priority. 
• Ask the team to discuss what made them consider the top priority ones. Use inquiry and have conversations to understand their perspectives.
• Identify ownership for the prioritized items and a target end date for implementing them. 

Start Stop Continue

In this technique, teams discuss three things. Things they need to start doing from now on, which they haven't been doing so far. Things to stop doing, which is not helping the team or the product. Something to continue doing which they are already doing and it's helping. 

• Start: Discuss what the team hasn't been doing to date, which will help them. It will be something to start with to get the benefits of doing it. The start usually will be a straight-face smiley.
• Stop: Processes, ways of working, coding practices, and other things that are not helping the team, or the product should be stopped. The team identifies these and chooses to stop them. A stop will be a sad smile. 
• Continue: Some things are helping the team and need to continue as it helps. A continuation will be a smiling or a cheerful smiley. 

This activity can be done innovatively using different ways. One of them is to use smileys. 

Growth Style

Using a plant, we can explain how we can want to do this growth style. By adding fertilizers and manures, we can help the plant grow better than usual. These are something that we want to start doing. 

Water is already assisting the plant in developing, and so we need to continue doing. Weeds are something that stops the plant from growing, and so we need to prevent them from ensuring the growth of the plant. 

Ask the team to use post-its to post their views and ideas on the fertilizer, weeds, and water. 

Team Radar

This technique is borrowed from Agile Retrospectives by Esther Derby. It helps the team gauge how well they are doing on a variety of measures, such as engineering practices, team values, or other processes. Team members track individual and group ratings for specific factors about process or development practices they want to examine. 

• Draw a blank radar graph like the one below. Ask individual team members to mark their scores on the radar for each factor. 
• Lead a discussion based on the scores like Where do they see them following these values and not following them.
• The same chart can be used with variations like engineering practices, team agreements, team values, methods, etc. 
• Team Radar can be used the first time as a baseline and after a couple of sprints to check measurements. 
• This technique is to bring more conversations when the team is unable to discuss anything further. Team radar is a subjective measure and especially useful when there are no standard criteria to measure against.

Ishikawa Diagram

It is also known as a fishbone, herringbone, or cause-and-effect diagram. It is mainly used for identifying the causes of a specific event. In our case, we can use it for Sprint. Below is the sample fishbone diagram.

Fishbone will be used in retrospect to look past symptoms to identify root causes related to an issue. We should look for reasons behind the problems and issues. The team identifies factors that are causing or affecting a problem situation and then looks for the most likely causes. After they have identified the most likely reasons, they look for ways they can make changes or influence those factors. 

• Draw a fishbone and write the problem at the fish head. Include 5-W's, what, where, when, which, and why and label them on fish bones. 
• Brainstorm factors within each category. Prompt by asking, "What are the [fill in a category name here] issues causing or affecting [fill in the problem here]." Repeat this for each category. Write the issues along with the bones, or have people write them on small sticky notes and stick them to the fishbone diagram.
• Continue asking, “Why is this happening?”. Add more branches off the bones as needed. Stop when the causes are outside the team’s control or influence.
• Look for items that appear in more than one category. These may be the most likely causes. Engage the group by looking for areas where they can make a difference. Use the results in the next phase, Decide What to Do.

This is just a speck of knowledge on your journey to becoming an expert in the industry. If you have any doubts or require career guidance, feel free to connect with our Industry experts and trainers for 1-on-1 coaching. "We upskill and boost your career by providing a wide range of courses such as CSPO, CSM, ICP-ACC, etc. visit our website to learn more about all the courses we offer."