I wrote this article intending to for the proposal to RSGT 2025, so if you don't mind, please consider giving a like to my proposal.
As it's been a long since the last post, I would like to describe some about the Retrospective in Scrum, which I discussed deeply with my Agile Coach.
I shared this content with my junior engineer friend and he said it's worth paying me some drinks, so I am expecting that you would enjoy a lot if you are interested in Agile or Scrum
The Quality of Retrospectives Reflects the Quality of the Team and Ultimately the Product
Are you conducting retrospectives in your team?
When I ask this question to the developers in Scrum team, many respond, "We do it properly every sprint," or "We allocate time every other week."
However, when I ask what actually they do, I often find that they are merely writing down KPT (Keep, Problem, Try) and just sharing it among the team.
Retrospectives are activities that handle "Inspection" among the three pillars of Scrum: "Transparency," "Inspection," and "Adaptation." They also serve as activities to prepare for Adaptation.
The quality of this "Inspection" directly impacts the quality of the team and ultimately the product.
Therefore, simply writing down KPT and presenting it may be somewhat insufficient.
Scrum also has Sprint Reviews as a representative inspection event.
The Sprint Review is an inspection of the product, responsible for how to improve the product.
On the other hand, the Retrospective is an inspection of team activities, responsible for how to improve the quality of team activities.
I have summarized the representative inspection perspectives in a diagram based on what came to mind.
Looking at it this way, you can see that each event has a very large number of topics, and it's clear that just discussing them briefly won't lead to improvement.
To efficiently discuss these topics and ac## Designing a Retrospective
Designing the Retrospective
What does it mean to design a Retrospective?
Including retrospectives, most meetings have a purpose.
Purposes vary, such as brainstorming, information sharing, or deciding on measures to address immediate issues.
Whether the participants of the retrospective can smoothly reach that purpose depends greatly on the quality of the agenda and facilitation.
Elements like how to conduct the proceedings, what methods to use for discussions, whether to encourage divergence or convergence and how to draw conclusions are important.
From that perspective, considering the agenda and discussion methods to guide participants efficiently and appropriately towards the purpose is the idea of designing a retrospective.
To surely run an improvement cycle that enhances team activities, it's necessary to properly design each event and guide the team into discussions.
Although we won't touch on Sprint Reviews this time, the idea of designing events and meetings is useful in various situations, so please consider it if you're interested.
Phases and Tools
As we begin designing retrospectives, let's look at retrospectives from the perspectives of Phases and Activities.
Phases are, as the word suggests, stages of discussion.
In the design stage, we consider what steps to take in the discussion to efficiently reach a conclusion.
For example, if there are four phases—Sharing, Divergence, Analysis, and Decision-making—we examine questions like Is it sufficient to have one round each of divergence and analysis? Is decision-making necessary? How much time should be allocated to each?
While retrospectives have their own purposes, each phase also has a purpose, and the tools used to achieve the purpose of each phase are the activities described next.
Activities refer to what methods of discussion are used in each phase.
For example, KPT, which was mentioned at the beginning, is one of the activities used for conducting discussions.
Other activities that many of you may be familiar with include "Sailboat Retrospective," "5 Whys," "Brainstorming," and "Good/Bad/Ugly."
Each activity has its strengths and weaknesses, and it's necessary to consider combinations based on the team's situation, the phase of discussion, and the required time.
By combining appropriate activities for each phase, you can proceed with discussions more efficiently.
In this way, analyzing the timebox of the retrospective and the team's situation, and considering combinations of discussion stages (phases) and discussion methods (activities) forms the basis for designing a retrospective.
Moreover, this way of thinking can be used in regular meetings as well, so please try using it not only for retrospectives but also in workshops, presentations, and various other situations as needed.
Note that the quality of the design can vary greatly depending on the number and maturity of the activities you have at your disposal.
If you're not familiar with many activities or don't know how to conduct them, please consider reading 'Agile Retrospectives: Making Good Teams Great' listed in the References section.
It introduces a large number of tools.
The Five Phases of a Retrospective
Now, you might be unsure where to start if you're suddenly told to design a retrospective.
Don't worry. In Scrum retrospectives, there is a commonly used framework called the "Five Phases."
This is the idea of dividing the retrospective time into five phases and combining activities in each to lead to conclusions.
Below is a simple summary of these five phases. The time in parentheses is a guideline for time allocation when designing a one-hour retrospective.
- Set the Stage - Get Ready for Discussion (within 5 minutes)
- Collect the Data - Gathering data (about 10 minutes)
- Generate Insights - Analyzing data (about 30 minutes)
- Make Decisions - Deciding what to do (about 10 minutes)
- Close the Retro - Closing the retrospective (within 5 minutes)
In this framework, you prepare for discussions, gather discussion topics, discuss the collected topics, decide what to do, and get ready to move forward.
Now, let's explain each phase.
Set the Stage - Get Ready for Discussion
In this phase, we have to get ready so that all participants can discuss comfortably.
It is important that all participants can participate in the discussion. However, in unfortunate retrospectives, sometimes a few strong-willed individuals dominate the conversation, or those who miss the initial opportunity to speak remain silent until the end.
This phase is intended to have all participants feel, "We are about to participate in a discussion," and "It's okay to speak up here," and it serves as a place to establish and confirm rules for that purpose.
Having everyone participate in the discussion and express their opinions in the place where the team's direction is decided not only gathers multiple perspectives but also leads to a sense of ownership when implementing the improvement plans decided in the retrospective.
This phase tends to be overlooked, but unless time is severely constrained due to delays, please make sure to carry it out.
What to do in this phase greatly depends on the team's maturity.
I will introduce two activities for different maturities.
Check-In
For example, if the team has high psychological safety and each member can actively express their opinions, it's fine to just have them say a few words.
Originally, check-in is an activity to help participants focus on the retrospective, so the rule is to have them share what they expect from the retrospective or their current situation, but there's no need to stick strictly to that.
Questions like "Share your thoughts on this week's sprint in one word!", "Describe your current mood in 20 characters!", or "Tell us what you had for lunch today and your thoughts on it in one sentence!" are sufficient.
This isn't because we want to know the answers to these questions or to engage in team bonding; it's more like a warm-up to create an atmosphere of "I'm about to speak up" and "I'm going to express my opinion."
It may seem meaningless, but whether or not you do this activity can significantly affect the liveliness of the discussion.
Even if it feels silly, please make sure to do it.
In my company, we often start by doing an activity where each person places their name on the "Wheel of Emotions" and shares briefly why they chose that spot.
Team Agreements
On the other hand, in teams where some strong-willed individuals tend to dominate the conversation, start by establishing and confirming discussion rules.
Specific rules might include: "Be mindful so that everyone speaks an equal amount," "Do not interrupt and listen until someone finishes speaking," "If you feel it's hard to join the conversation, give a signal," "If you talk for more than one minute, check if other members have opinions or questions," and "Do not take away the speaking opportunity from someone the facilitator has designated."
These rules can be decided by the facilitator or Scrum Master, but it might be good to take some time during the retrospective to discuss them.
If they are agreements decided as a team, both members who tend to talk too much and those who are not good at speaking can participate in discussions with mutual understanding.
Also, if there are members in higher positions, it can be effective to ask them in advance to moderate the frequency and intensity of their comments.
Collect the Data - Gathering Data
Once all participants are ready to speak, the next step is to gather seeds for discussion.
When you think of data, you might imagine quantitative elements like completed story points, man-days, or the number of PRs. However, the data referred to here also includes qualitative elements such as emotions, opinions, and events.
Posting KPTs (Keep, Problem, Try) is also one of the data collection activities. KPT is a tool that handles everything from data collection to decision-making in one go, but at this point, it's better to treat "Try" as something like "things we think we should do."
Specific data examples include the following:
Quantitative Data and Tools for Obtaining Them
- Transition of completed story points: Jira, etc.
- Lead time of development activities (※1): Findy Teams, etc.
- Values of 4 Keys (※2): Jira, Findy Teams, etc.
- Actual working hours (※3): Team calendars on Kanban boards, groupware, etc.
※1 From initiation to design creation, from design completion to development start, from development start to PR creation, from PR creation to merge, from merge to deployment, etc.
※2 Deployment frequency, change lead time, change failure rate, time to restore service
※3 Total working hours within the sprint, excluding vacations, meetings, Scrum events, etc.
Qualitative Data and Representative Activities
- Feedback on team activities: Keep/Problem/Try, etc.
- Feedback on team status: Good/Bad/Ugly, Sailboat Retrospective, etc.
- Events within the sprint: Timeline, etc.
- Emotional feedback from members: Mad/Sad/Glad, etc.
Of course, it's not realistic to collect all of this data, and too much information becomes noise. Please have the facilitator decide what data to collect and how, after confirming in advance what the Scrum Master and team members want to discuss.
Also, one point to keep in mind is that the most important part of a retrospective is the discussion and analysis that follows. Therefore, using tools that automatically collect data or gathering KPTs in daily activities are very effective ways to reduce the time spent on data collection.
Actually, it was repeatedly pointed out during mentoring meetings with a Scrum Trainer, and we created a board to regularly collect timelines and emotional/activity feedback.
Also, in the team I participated in, we prepared a space called Found and Resolved, which was set up to put sticky whenever someone noticed something they wanted to discuss with the whole team.
Generate Insight - Analyzing Data
Next is the data analysis phase. As mentioned at the end of data collection, this phase is the core of the retrospective. We bring together the collective wisdom of all team members to analyze the collected issues and explore solutions.
Selecting Topics to Discuss
Before starting the data analysis phase, the first thing to do is select the issues to discuss. Each member has their own sense of issues, and various topics come up during data collection.
However, since the time available for discussion and for implementing improvements is limited, it's necessary to narrow down the topics to decide which problems to solve or which good points to further enhance.
My recommended methods for narrowing down topics iare Dot Voting and Heat Maps.
Dot Voting
Dot voting is a commonly used method, so many of you may already know it, but I'll explain it for just in case.
In Dot Voting, you decide on the number of votes per person (e.g., 3 votes) and vote on the topics collected during data collection that you want to discuss. Limiting the number of votes allows each member to prioritize topics.
The topics that receive the most votes become those with high team interest, and the impact when improved becomes greater. Dot voting can be done in a short time and has the advantage of simplicity and easiness of understanding.
However, one caution is that when conducting dot voting, you need to ensure that it's not apparent who voted for what, such as by color or name.
If voters are identifiable, there's a possibility that votes may be skewed due to power balances within the team. To select topics that all team members can discuss on an equal footing, use anonymous dots of the same color.
Heat Maps
Personally, I recommend Heat Maps over Dot Voting. It's an extension of dot voting, where you vote with as many dots as you like, up to a set limit, on the topics collected during data collection that you want to discuss.
The number of dots represents your level of interest in that topic. For example, if the maximum is 3 votes, it can be interpreted as follows:
- 1 vote: Interested
- 2 votes: Want to discuss
- 3 votes: Really want to discuss
After voting, tally the number of dots as in dot voting, and start discussing the topics with the most votes in order.
The good thing about heat maps is that they reflect the strength of each member's will.
In dot voting, topics that aren't of much interest may still receive votes, but in heat maps, the level of interest affects the number of votes.
By using heat maps, topics that may not have gained much consensus but are very important to certain members also get attention, allowing problems noticed only by some members to be selected for discussion.
Deepening the Discussion
Once you've narrowed down the topics to discuss, move on to the discussion. Share opinions and ideas on the selected topics, and share what you'd like to try or do.
You can conduct the discussion freely until a conclusion is reached, but by using tools like Fishbone Diagrams, 5 Whys, or Lean Coffee, you can proceed more efficiently.
I myself often use Lean Coffee in 1-on-1s and regular meetings, so I'll explain Lean Coffee here.
Lean Coffee
Lean Coffee is a method used to discuss many topics by setting timeboxes. By following the rules below, you can perform analysis and idea generation in a short time.
- Divide 10 minutes into three segments of 5 minutes, 3 minutes, and 2 minutes.
- At the end of the first 5 minutes, pause the discussion.
- If you feel satisfied with the topic, show a 👍; if you still want to discuss, do nothing.
- If the majority shows a 👍, move to the next topic; otherwise, continue the discussion.
- Do the same for the remaining 3 minutes, and after the final 2 minutes, move to the next topic unconditionally.
By proceeding with the discussion in this way, you can talk about up to 6 topics in 30 minutes, or at least 3 topics. Also, if you come up with 2 TRY ideas for each topic, you'll generate between 6 and 12 TRY seeds from the topics.
As a side note, when conducting Lean Coffee, it's recommended to assign a scribe. By visually tracking the flow of the discussion, it's easier to generate constructive TRYs.
Make Decisions - Deciding What to Do
After deepening discussions and generating various TRYs (things we want to try), we finally decide what to implement to improve the team.
Even though TRYs have been raised during the discussion, it doesn't mean that the subsequent improvements have been decided.
We cannot implement all the TRYs that were raised, and the TRYs that came up during the discussion are not necessarily executable as they are.
In this phase, we primarily conduct the following discussions and decisions:
- Decide which TRYs are most important for the team
- Refine TRYs to make them executable
- Assign TRYs to team members
- Manage the TRYs
By going through this phase, the TRYs become executable as follows:
Let's explain each of these.
Decide Which TRYs are Most Important for the Team
Selecting appropriate topics and engaging in active discussions can result in many TRYs. However, it's not realistic to execute all of them.
Trying to implement many TRYs simultaneously can lead the team to face many changes in the next sprint, causing fatigue. In the worst case, the motivation to execute TRYs may gradually decrease, turning the retrospective into just a place to propose improvements without action.
To avoid such situation, I recommend you to utilize tools like dot voting or heat maps to decide which TRYs to implement in the next sprint at the beginning.
Refine TRYs to Make Them Executable
As mentioned earlier, the TRYs generated during discussions may not be directly executable. To make the selected TRYs executable, refine them by clarifying the wording, creating subtasks, and adjusting the scope.
When refining TRYs, it is recommended to compare them with the criteria of SMART goals.
A SMART goal is a commonly used criterion for goal setting, derived from the initials of the following five words:
- Specific: Clear and specific
- Measurable: Progress and results can be measured
- Attainable: Realistically achievable
- Relevant: Appropriate for solving the problem
- Time-bound: Has a clear deadline or time frame
For example, suppose the following problem and TRY have been raised:
Problem: Pull requests are piling up, causing many conflicts
TRY from the discussion: Schedule time for pair reviews
This TRY is not necessarily executable as is. Let's refine it from the perspective of SMART.
- Specific: The action itself is clear, so no problem here.
- Measurable: Frequency and duration are not specified, making it hard to measure. For example, adding the words "1 hour daily" would be better.
- Attainable: Scheduling between reviewers and reviewees is necessary. For instance, creating a subtask to block 1 hour on own calendar after the Daily Scrum (DS) can increase feasibility.
- Relevant: Securing review time helps prevent PR backlog, so it is appropriate for solving the problem.
- Time-bound: There's no set deadline. For example, "Continue for two weeks and evaluate the effect in the next retrospective" makes it clear.
By refining the TRY in this way, we get the following specific TRY and tasks:
Problem: Pull requests are piling up, causing many conflicts
Improvement (TRY): For the next two weeks, schedule 1 hour after DS for pair reviews, then discuss whether to continue afterward
Tasks
- Register the schedule in the calendar
- Add a pair review request to the end of the DS agenda
- During each DS, ask if anyone needs a pair review
- Discuss whether to continue after two weeks
Assign Responsibility
To execute the refined TRYs, the next step is to assign responsibility. Clearly define who is responsible for completing the TRY and who will carry out the created subtasks.
A common issue in retrospectives is that improvement ideas are proposed but end up not being executed.
Deciding who is responsible at this stage is crucial to cultivate a habit of the whole team taking responsibility for improvements and preventing the retrospective from becoming a mere formality.
In a team I previously participated in, we established temporary roles called "〇〇 Police" (e.g., Review Police, Pair Programming Police) to check whether the team's decided improvement plans were being executed and to prompt action.
Having fellow team members gently remind each other made it easier to implement improvement plans without resistance, which I found to be a very effective approach.
Manage the TRYs
This step is not mandatory, but managing TRYs had a significant positive effect on improving team activities.
Even after refining the selected TRYs and assigning responsibility, sometimes the improvement plans decided a week or a month ago get sidelined due to daily tasks.
To avoid such situations and ensure that improvements are executed, I recommend managing TRYs on a Kanban board and checking progress during the Daily Scrum (DS).
Regularly reviewing the progress of TRYs and tasks from the previous sprint to see if team activities are improving was very effective.
Close the Retro - Closing the Retrospective
Once you've decided on the improvements to implement in the upcoming sprints, the final step is to close the retrospective.
In this phase, you record what the team has learned, solidify the improvement plans, and express gratitude to the participants and facilitator.
The main activities are as follows:
- Reflecting on the content of the retrospective
- Moving TRYs and tasks to a visible place on the Kanban board (including transcribing them to the TRY Kanban if you're using one)
- (For offline meetings) Taking photos of whiteboards or sticky notes
- (For offline meetings) Tidying up the venue
- Expressing gratitude to the participants and facilitator
I'd like to introduce two activities that I personally enjoy.
Retrospective of the Retrospective
While a retrospective is an activity to improve team practices, the retrospective itself is also subject to improvement. By reflecting on the retrospective at the end, you can conduct future retrospectives even more efficiently and effectively.
In a Retrospective of the Retrospective, each member writes down what went well and areas for improvement at the end.
By candidly sharing feedback such as "I couldn't express what I wanted to say," "There were moments when the discussion stalled," or "The connection between phases was weak," you can apply these insights to the design of the next retrospective.
Circle of Gratitude
This activity is particularly effective in quarterly retrospectives. It's also very effective in overall retrospectives held at the end of a project or release.
The method is very simple: participants take turns expressing gratitude to the team and each member.
Procedure:
- The first person expresses gratitude to the team and to someone (or everyone) in the team.
- The person who just spoke nominates the next person, who then expresses gratitude to each member in the same way. (You can nominate someone who you expressed gratitude in step 1.)
- Once the last person has finished expressing gratitude, declare the completion of the retrospective.
Retrospectives are held to conduct continuous improvement, and by concluding with expressions of gratitude to your colleagues, you can start the next sprint on a positive note. This also leaves a positive impression of the retrospective itself and the overall improvement activities.
Conclusion
This post has become quite lengthy, but that concludes the discussion on the concept of designing retrospectives.
Retrospectives are one of the representative Scrum events, and I believe they are often conducted in a way where people "just try doing it without really understanding it."
Since the goal of Scrum is to increase product value through continuous hypothesis testing and improvement, the focus tends to shift towards improving the product or service itself, such as backlogs and sprint reviews.
However, at the same time, the core of Scrum is the team, and improving the quality of the team ultimately leads to the quality of the product.
If this article has piqued your interest in retrospectives, I encourage you to take this opportunity to design the retrospective event anew.
Additionally, if you'd like to discuss or ask questions about this article, or if you'd like me to design and facilitate a retrospective for your team, please feel free to contact me at the email address below.
Email: munchkins.hands@gmail.com
Lastly, as mentioned at the beginning, I wrote this article intending to for the proposal, so I really appreciate if you can put a like to my proposal.
Thank you for reading to the end.
References
The Five Phases of a Successful Retrospective
Are you an Elite DevOps performer? Find out with the Four Keys Project
Agile Retrospectives, Second Edition: A Practical Guide for Catalyzing Team Learning and Improvement (This is link to Amazon, but not for promotion or affiliates.)
Top comments (0)