20th Mar, 2020
Anything that happens again and again without a small change gets boring in 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 need to have focused outcomes. Also, different techniques can be used to achieve different results.
Let us see what some of the ways are:
When teams passionately discuss the ideas, a lot emerge. 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, which they think as 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 its 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. Start usually will be a straight face smiley.
- Stop: Processes, way of working, coding practices, and other things that are not helping the team, or the product should be stopped. The team identify these and choose to stop them. A stop will be a sad smiley.
- Continue: Some things are helping the team and need to continue as it helps. A continue will be a smiling or a cheerful smiley.
This activity can be done innovatively using different ways. One of them is to use smileys.
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 the 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.
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.
It is also known as fishbone, herringbone, or cause-and-effect diagram. It is mainly used for identifying causes of a specific event. In our case, we can use it for the Sprint. Below is the sample fishbone diagram.
Fishbone will be used in retrospective 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.