The second day of the Futurice Scrum Club had retrospectives as the theme (as chosen in the last Scrum Club meeting). How did it go and what did we learn?
Text by Jari Harjula and Jukka Edvardsson.
The Scrum Club held its second session at the beginning of June. It consisted of many exercises designing retrospectives of different lengths and goals, and a multitude of methods and exercises were brought forward by the participants. How can one facilitate a good retrospective? What kind of issues might affect the outcome? What are the key ingredients of a successful retro?
We started the day with a safety check exercise. The main idea of the exercise is to verify that participants feel safe about sharing their feelings with the group. The information was gathered with a closed anonymous poll where everybody put a number between 1-5 to illustrate their individual feeling of safety. Poll results are gathered by the Scrum Master and only the total is shown to the group. (Remember to use same kind of paper and pens for everyone!) This way, the group will get valuable information about whether there are people who are possibly not willing to share their feelings and thoughts openly. If the results of the poll are not encouraging, it might be a good idea to investigate why. A successful retrospective requires at least some feeling of comfort from all participants.
One of the group exercises was to design a plan for a sprint retrospective session with a tight time limit (about two hours) and a specific goal in mind. Our group decided to focus on “improving measurements and metrics”. Petri imposed an additional challenge: we were not allowed to use any methods from previous exercises, meaning we had to more or less invent a new methodology for a successful retro session. Here's what we came up with:
1. Setting the stage. The topic for this short sprint retro will be: What should we measure during sprints and how? Why and for whom? Assuming the participants know each other, we won’t spend much time here.
2. Data gathering. Participants individually come up with at least one story that answers the questions what, why and for whom we want to measure. The metrics can be existing ones as well as new ones - meaning that we'll start from an empty table. One story, for example, could be We want to measure the time it takes to deploy a production release in order to monitor and improve it. Stories are written on Post-it notes.
3. Generating insight. The stories are shifted around to the next person so that nobody has their own story. Everybody then places the stories one by one on a cost-value chart drawn on the wall. The positioning of each story on the chart is discussed and agreed upon together. If there are duplicates, they are combined. Which metrics are easy to take into action and provide the most value?
4. Pick three stories to act upon as a group. The position on the chart most likely affects whether a story is chosen.
5. With the help of a whiteboard discussion, each story is broken down into concrete tasks. What data is collected, from where and how? How is the metric followed and reported? How often?
6. The stories and their corresponding tasks are then written on large sheets of paper and hung on the team wall for follow-up actions. Rinse and repeat as needed.
The whole day was organized like a long retrospective. We started with data gathering regarding Scrum usage in our projects, then proceeded to propose improvements, prioritized them and finally agreed upon some concrete actions and experiments. Of course, these were committed to by the Scrum Club participants.
Stay tuned to hear more about them!