*Article is based on: “Agile Retrospectives. Making Good Teams Great by Derby/Larsen”
Agile retrospective is from my perspective the most important scrum event. The team reflects on how everything went and then decides what changes they want to make in the next iteration. The Agile manifesto states: „at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Let’s start from theory in case some of you have never attended one.
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. This is a three hour time-boxed meeting for one month Sprints. For shorter Sprints, the event is usually shorter.
Some of you may ask, what is the role of the Scrum Master during the meeting?
She/ he ensures that the event takes place and that attendants understand its purpose. Apart from that, their role is to teach all to keep the meeting within the time-box. And of course they participate as a peer team member in the meeting from the accountability over the Scrum process.
What is the purpose of the meeting?
Mainly to inspect how the last Sprint went with regards to people, relationships, process, and tools. Then to identify and order the major items that went well and potential improvements. And also create a plan for implementing improvements to the way the Scrum Team does its work.
What is important while leading the retrospective?
First we should explain activities to participants, ask them if everything is clear. We need to think how to manage group dynamics and of course how to manage time. Then it’s really important to manage yourself, so that everyone get a chance to speak. What’s most important we need to learn from experience.
Structure of the retrospective
Set the Stage: 5% -> 6 min*
Gather Data 30-50% – 40 min*
Generate Insights 20-30% -> 25 min*
Decide what to do 15-20% -> 20 min*
Close the Retrospective 10% -> 12 min*
*Time for 2h retrospective, 17 min for switching activities
By setting the stage we normally think about some check-in or energizing excercises. The main goal of them is just to get everyone to say something since they’ll be more likely to speak later. This part of the meeting is also used to create a good, safe environment to get everyone participating in the retrospective.
- One word – ask the team which word comes to their mind while thinking about previous iteration
- Different opening questions, such us: If you could have an endless supply of any food, what would you get?
- ESVP – ask each participant to report anonymously his or her attitude toward the retrospective as an Explorer, Shopper, Vacationer or Prisoner. Then Acknowledge the results and guide a discussion about what the results mean for the group.
Gathering data is the longest part of this scrum event. Here we are focusing on understanding „the mood” of the team. We can used different methods, such us:
- Timeline – this give us an opportunity to try out an activity that looked at events and emotions
- Color coding Dots – this is the great way to reflect the emotions of individuals
- Mad Sad Glad – issues, changes or observations made during a sprint are listed by all participants and then categorized as either Glad, Sad or Mad
- Satisfaction Histogram – this is used to highlight how satisfied team members are with a focus area. Then we are providing a visual picture of current status in a particular area to help the team have deeper discussions and analysis
- Mood diagram –start from human moods and emotions to discover problems at a retrospective. People made some marks for the areas they’re happy, neutral or pessimistic about, and we can make some conlusion about our process.
- Start/Stop/More/Less/Continue – great for creating action plan of things we are going to start doing, stop doing, or keep doing.
- Team radar:
- Mood diagram:
After gathering the essential details, it’s time to figure out what this information means, we do it during the generate insights phase of the retrospective.
There are different ways we can use here:
- Get ideas from discussion
- Fishbone – The Fishbone diagram is also known as the Cause & Effect (C & E) diagram or as the Ishikawa diagram referring to its originator, Professor Kaoru Ishikawa. The C & E diagram is a good tool when you need to identify the root cause of a problem.
- Five Whys – The 5-why analysis has its origins within Toyota and lean manufacturing and is used to find the root cause of a problem through identifying a symptom and then repeating the question “Why?” five times.
- 5 whys
– We were blocked because of a dependent team that didn’t complete their part of the work
Why did this happen?
– Well, they got the request too late and didn’t have time to stop their other work and complete it
Why did they get the request so late?
– We didn’t know about the dependency until we started working on the story
Why didn’t we know about the dependency?
– We had not groomed the story before hand
Why didn’t we groom the story before hand?
– The PO didn’t have the story ready at that time
Why didn’t the PO have the story ready?
– We didn’t have visibility on the plan for the release
Why didn’t we have visibility on the plan?
– We didn’t do any release planning
So the root cause here is that the lack of release planning caused a chain of events that eventually led to a dependency blocker problem at the sprint.
Next part of the meeting is called decide what to do, in simple words it means solving the problems. We should decide within the team which action points are the most important – prioritize all mentioned items, make them visible to the team. It’s really important to establish who will be responsible for specific APs and follow them up in the future.
Finally by closing the retrospective we just want to summarize what was discuss and finish the meeting somehow. We can ask the team members how they find the retrospective, if there is anything they want to improve in the future. Another great way to conclude the meeting is to use appreciations. It’s all about mentioning the things we appreciate about other members of the team.
„You really served the group when.. and when…”
„What I would like to see more of….”
We all probably know that agile retrospectives enable teams to create a continuous improvement culture, but what is most important for me that they really help to empower teams. They give opportunity for teams to own their own decisions and actions :)