Retrospectives play a crucial role in continuous improvement. But how do you feel about yours? Have they resulted in any improvement? Do you know where to begin? There are many retro templates and techniques available for creating a good retrospective culture in your organization. The purpose of this post is to teach you everything you need to know about retrospectives and how to perform them.
Retrospectives are a chance for your team to analyze the past to better prepare for the future. If you’re not continuously improving, you’re not Agile. As the Manifesto for Agile Software Development states:
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
Retrospectives, or retros, offer a chance to uncover what works well for a team, and what doesn’t. Retrospectives check the pulse of a team. Teams can take time out of their everyday tasks and reflect on the big picture, identifying potential stumbling blocks before they turn into problems. Retros give all team members a chance to speak up and produce a set of possible actions to improve.
Typically, retrospectives seek to answer three questions:
As you can see, retrospectives are an important tool for team members to identify challenges and gather information about what happened during the sprint. Using what they have learned, the teams can then develop new ways to work on projects and avoid relying on default thinking patterns.
In many retrospectives, facilitators will open their meetings by reading the Retrospective Prime Directive. The objective is to ensure that the team has a positive mentality heading into the event retrospective. Reaffirming the value of retrospectives in agile workflows, and showing teams how to approach them properly.
"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
Retrospective Prime Directive Norm Kerth, Project Retrospectives: A Handbook for Team Review
With the retrospective, team members reflect on a sprint, or period of work, which has just ended. After achieving a milestone, creating a design or product, and moving to the next phase, you're ready to proceed. A retrospective serves as an intermediary step for your team to reflect on what went right and what went wrong. Afterward, you'll know what to improve and what to keep.
Even though it's supposed to be a positive and constructive exercise, it can easily slip into a negative and criticizing one. This is why the prime directive instructs teams to focus on positive aspects. As opposed to believing missed opportunities result from inaction, consider your team's limitations, and remember that some goals are simply unattainable. Make a plan that is reasonable and morale-enhancing rather than pushing your team to work harder.
The scrum guide states that all members of the Scrum team should be invited.
"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."
Who exactly is on the scrum team? According to the guide there are three personas:
It seems to us that we can widen this a bit. The retrospective should be attended by all members of the team, with a facilitator leading the discussion. The facilitator can be a scrum master, a product owner, or it can rotate among team members. We encourage you to include designers, marketers, and anyone else who contributed to the current sprint or iteration.
Retrospectives belong to the category of meetings called "participatory group learning." Any time you ask a group of individuals to analyze together, pose a problem together, or come to a decision together, you are in a participatory learning environment.
Why do “participatory group learning” activities require a facilitator? Here's what would happen if there was no facilitator: those who are the most outgoing or senior will likely speak up first. The rest of the group will be biased - whether consciously or not. As the next speaker speaks, he or she will expand on or challenge the first idea. It doesn't matter how you look at it, the conversation is now focused on what was shared initially.
Perhaps the first idea should be discussed. This is an assumption that might not always be true. Facilitation can fill that void.
It is the facilitator's responsibility to create an environment that ensures you have a constructive conversation that focuses on the right topic at the right time, rather than wishing you did.
The participant must be encouraged to participate fully, the group must be enabled to understand each other and come to solutions from different perspectives, and the team needs to assume ownership of the meeting's outcomes.
Retros don't always go smoothly and it can be hard to plan everything and organize a framework if you don't have everything planned. You will learn how to conduct your sprint retrospective with GoRetro by following a few simple steps.
To begin with, you should invite each stakeholder (development team, product owner, scrum master) to the retrospective, and you should assign a facilitator to lead it. Facilitators can be team members or external individuals with whom the team feels comfortable sharing details.
You can start by creating a board on GoRetro, and if you'd like to simplify things, you can select the 'what went well' template format.
Focus the team on the retrospective and create a respectful and safe environment.
You should begin the retrospective by reviewing whether all actions from the previous retrospective have been completed. If not, why hasn't it been done? Time this for five minutes.
Ask your participants to brainstorm individually and write down their thoughts on the "Went well" and "To improve" columns. It should be about something that happened during the last sprint that stakeholders thought was worth sharing. This step can be controlled by a facilitator giving people 10 minutes to write. Once 10 minutes are up, everyone should stop writing.
The facilitator should read cards one by one and ask people whether they believe the card should be merged with another one on the board. The facilitator can merge them if all participants agree.
The facilitator should assign about 5 minutes for the people to vote on the cards they want to discuss.
When everyone has voted on the cards, you can sort the columns by votes and select the top cards for discussion. This is the most crucial aspect of the process.
Ultimately, it is the role of the retrospective facilitator to keep the discussion open but not lose focus by falling into unnecessary (time-consuming) discussions, ensuring that all stakeholders are heard, and maintaining high levels of communication in the discussion. Prior to the discussion, the facilitator should outline what the expected outcome is.
Afterwards, the team can discuss how the problems can be resolved and what constructive things can be done to resolve them. Read more about action items in the next section.
In the aftermath of a retrospective, there is a sense of satisfaction that the team's feedback has been captured, that they have been engaged and that they have come up with some good ideas. Each was captured, written down and voted on, and actions have been decided on. However, how can you ensure actions are taken on the items captured in the retrospective?
Generally, action items can be separated into two categories based on the expected delivery timeframe:
It is recommended to stick with smaller action items that can be completed within a logical time frame like a month, so that the team remains motivated and enthusiastic. Assured small wins are a more robust tactic for continuous improvement than aiming high right away.
Now, let’s revisit the original definition of the retrospective according to scrum.org:
“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.”
The first two components (inspect and create activities) are activities, and the third one (improvements) is a result. Despite having fruitful conversations and creating action items to achieve the desired results, few teams implement systems to guarantee that they actually deliver on these promises.
A retrospective is only as effective as the action items set, and how they are followed up on. However, there is an issue with the concept of "improvement:" it is subjective and vague, and most importantly, it does not enforce accountability. There must be a better way to accomplish these goals. This is where the SMART goals framework comes in. SMART stands for Specific, Measurable, Achievable, Realistic, and Time-sensitive. You can read more about SMART goals here.
It is common for teams to conduct a retrospective in the same way every week. That’s great if it works for you. Nevertheless, continuous improvement can easily become stale and can often stall. In most cases, retros are based on individual opinions. New formats/templates are presented in a variety of books and websites, but most of them are based on opinions and subjective approaches.
You can build a transparent and adaptive team culture by integrating data-driven approaches into your retros. In addition, data-driven retros promote a culture of ownership, accountability, and self-directed learning so that your team will grow in all aspects of their agile practice and process.
When data is gathered, it gives the team a chance to develop a shared understanding of what happened, which allows for a more meaningful discussion about how to improve. So what data do you need to present at your next retrospective? In what ways can you effectively utilize them?
An objective data set is any piece of information that is measurable and verifiable. Objective data comes in many forms. Some examples include:
Remember, not all of this data needs to be brought to every retrospective (though you can certainly do so). Bring the data you believe is the most relevant, given what's going on.
Objective data includes facts and figures, whereas subjective data includes opinions, feelings, and emotions. Rather than presenting the facts, subjective data can reveal what your team thinks is important about them.
You can gather subjective data by asking the following questions:
The remote work trend is here to stay. In the face of these challenges, how can we overcome them and help teams work together to foster unity and encourage team participation, no matter where members are physically located?
A remote sprint retrospective is exactly what it sounds like: a remote variation of a retrospective meeting via video. The goal of these virtual meetings is to reflect on what the team has done so far and determine how they can be improved upon for the next sprint.
A remote retrospective can be run by:
When everyone is engaged and participating, remote retrospectives are easy to run. The main objective is to review the past iteration and determine what can be improved for the next one. Find out more about remote retrospective in our dedicated blog post.
Ready to have a data driven sprint retrospective?
No matter where you are working from, keeping retrospectives engaging, productive, and organized can be a challenge. We make it simple for you to plan, facilitate and track Sprint Retrospectives with our digital platform. Grab your free account today.