Plutora Blog - Agile Release Management, Release Management, Value Stream Management
The Agile Retrospective: Definition and Example FormatsReading time 16 minutes
The following is a principle upon which the Agile Manifesto was built: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” The agile retrospective is just that, a ceremony conducted at regular intervals that is focused on continuous improvement. The retrospective is the time of the week that the team figures out how to get better. I would argue that it’s the most important ceremony an agile team (or any team, for that matter) has.
In this post, we’re going to look at how to structure a retrospective, some different types of retrospectives, and some norms that will make your retrospective more effective. Let’s start off by going over how often we should run a retrospective.
How Often and How Long
There’s no definitive answer on how frequently to have a retrospective other than “it depends”. The cadence depends on the team, but a good place to start is once a week. Similarly, the amount of time required depends on the team’s current context. A safe bet is to schedule an hour.
Managing dependencies between Agile, DevOps, and Waterfall methodologies can be a struggle. Plutora provides a collaborative environment where teams can move fast.Learn More
If the team is consistently ending retrospectives (or retros) without covering all the listed items, it’s an indication that the cadence might need to increase. On high-performing teams, the retrospective can take less time because the team is happy with its current process. Alternatively, it might turn into a time to discuss process experiments for even greater benefits.
Because each team is different and has peaks and valleys in performance, the cadence and length of a retro are moving targets. However, one hour a week near the end of the week is a great jumping-off point.
So now that we’ve scheduled our retro, let’s go over the format and how to run it!
Here’s a good format for starting a retrospective:
- Icebreaker: five minutes
- Review previous outstanding action items: five minutes
- The retrospective activity: 45 minutes
- Assign action items: five minutes
I do icebreakers in all the retrospectives I participate in. This might be a little difficult for larger group sizes, but for typical teams, an icebreaker is a great way to kick off the retrospective. The intent is twofold.
The first and most important purpose of the icebreaker is that it helps get people talking. For teams that have a lot of introverted or shy people, answering an icebreaker question is a less risky way to open up to the group. After speaking out once during the icebreaker, it’s easy to speak again when discussing issues affecting the team.
The second purpose the icebreaker serves is to facilitate building interpersonal relationships. If you build relationships and create a culture where people care about each other, you build an environment people want to work in. If people care about the environment they work in, they’re more likely to be concerned about its health and function.
Here are some fun icebreaker questions we’ve used on my teams recently:
- What’s your favorite and/or least favorite concert experience?
- What’s your favorite holiday memory?
- If you didn’t have your current job, what would you be doing instead?
Reviewing Previous Action Items
Before working on generating new ways of improving, it’s important to be committed to existing action items. Use this time to see if current process experiments are accomplishing their purpose and if one-off action items have been resolved by their owners.
The Retrospective Activity
There are a whole bunch of cool retrospective ideas people have come up with over the years. Let’s take a look at a few of them:
- Happy, Confused, Sad
- Liked, Longed, Lacked, Learned
All of these retrospective ideas help flesh out ways the team could improve but in varying ways. Let’s start by taking a look at the Happy, Confused, Sad retrospective format.
Happy, Confused, Sad Retrospective
This is a pretty common retro format that doesn’t require a lot of up-front planning. Team members will discuss the current team’s context in terms of what they are happy, sad, or confused about. This is a good retro for inexperienced or shy facilitators because the main job of the facilitator in this is to keep the discussion productive and cut it off when it starts rambling. I like to rotate columns when discussing items here so that you don’t discuss all the happy items first and then end on sad or confused items.
The prompts for this retro include the following:
- What were you happy about this week?
- Are there some things that made you sad this week?
- Are you confused about something the team is doing?
And here’s how to run this retro:
- Start with a whiteboard or a place where you can label three columns with Happy, Confused, and Sad.
- Give everyone some sticky notes and a permanent marker.
- Allot five or so minutes to have each team member write down answers to the prompts.
- Dot vote! Dot voting is a way to vote on the most important topic. You set a dot budget and then let everyone in the room vote on the topics in the three columns they think are most important to discuss. If there are five to six people, three votes are usually sufficient.
- Organize the columns by the number of votes.
- The facilitator should introduce each item in the order of its importance and let the person who wrote it explain the thought.
- Discuss and capture potential action items if there are any.
Liked, Longed, Lacked, Learned Retrospective
This retro is good after a week where the team struggled with a hard problem. The importance of calling out items that the team learned during a week where they struggled with something is a good way to focus on positive outcomes that they can use going forward.
The prompts for this retro include these questions:
- What did you like about this week?
- Was anything lacking this week?
- What are you longing for in the coming weeks?
- Did you learn something this week?
Here’s the process for running it:
- Set up a 2×2 square grid. Label each square in the grid with either Liked, Longed, Learned, or Lacked.
- Give everyone sticky notes and a permanent marker.
- Give five minutes to respond to the prompts.
- Dot vote if there are a lot of items to go through.
- Organize items by importance.
- Discuss each item and capture actions/outcomes.
This is a fun retrospective that can help the team analyze their work with respect to a broader goal. The idea is to use a sailing metaphor to think about what’s propelling the team forward toward a specific goal. The team is a boat, and the goal is represented by an island. Wind represents what’s propelling the team toward the goal. An anchor indicates what’s slowing or dragging the team down. We also use rocks as a way to indicate risks to the project.
This format can go a couple of ways depending on the facilitator’s intent. If the team already knows what their current goal is, then you can orient the other prompts around what’s helping or preventing the team from achieving that goal. It can also be useful to ask the team members what they think the current goal is. This helps show everyone on the team either that there are some conflicting opinions or that everyone is on the same page.
Here’s the prompt for this retro:
Imagine our team is a sailboat, and our end goal is an island we’re sailing toward.
- What is the wind in our sails propelling us toward our goal?
- Are there risks (rocks) we might hit that will stop us from achieving the goal?
- What are the anchors dragging us down and preventing us from getting there faster?
And here’s how to run it:
- Draw the sailboat, island, wind, rocks, and anchor.
- Explain the prompts to the team, and give the team members five to 10 minutes to write down ideas.
- Have the team place the ideas on the appropriate parts of the drawing. More so than the other retrospectives, this might take some facilitation and help to make sure the stickies are in the right spot. People often confuse what’s currently dragging the team down with risks that might cause problems in the future.
- After doing the grouping, discuss each aspect of the analogy, one at a time.
- Discuss outcomes related to enhancing the wind cards, mitigating the rock cards, and reducing the effect of the anchor cards.
This retrospective is a good one to run to look at a broader period of time for the team to understand where things went wrong or right. It’s also a good way to learn about how each team member is feeling about the direction of the project. The timeline retrospective can also be used as a postmortem activity. I think for this to be most effective, you’d want to look at a period of a month or more.
There isn’t as much of a prompt for this retro. It’s a fluid activity. Here’s how to run it:
- Define the period of time you’re going to review.
- Draw a graph with only the positive quadrant (top right) showing on a large whiteboard (preferably eight to 12 feet or more).
- Put the start and end of that time period as an x-axis.
- On the y-axis, we’re going to put a happy face at the top. Zero is going to be a sad face.
- Give everyone stickies and a couple of minutes to collaborate on listing out the good and bad events that occurred during the time frame. Put those in chronological order on the x-axis.
- Give everyone a different colored marker or have them label a line with their name. Each person is going to draw how they were feeling from the start of the time period to the end. You will notice that people generally have similar peaks and valleys.
- Use the peaks and valleys as talking points about what went wrong or right, and discuss how to either avoid or recreate similar situations.
I included this section mainly because I think that everyone should come up with their own retro formats. As long as the focus is on continuous improvement and getting input from everyone, it’s hard to go wrong. Experiment with different things. To get the best feedback from your retros, you have to get people outside of their normal thought process.
Take the team outside or to a different space. Bring some sticky notes and markers and come up with your own prompt. It can be as simple as saying, “Let’s talk about what went well and what didn’t go well this week.”
Assigning Action Items
Alright, so we’ve done the retrospective activity. It’s important before we disperse to make sure that all the action items or process experiments we’ve come up with have someone who is committed to making sure they get resolved. This gives us someone to follow up with next week to see how action items are progressing.
So that’s the structure of the retrospective and some ideas for retrospective activities. Let’s take a look at some ways we can be effective with this meeting.
How to Have a Good Retrospective
Good retrospectives take practice, and every team is different. What is a good result for a retrospective for one team might be considered ineffective for a different team. That being said, there are a few simple guidelines that are generally applicable.
- Set the stage for everyone to speak their mind
- Facilitation, facilitation, facilitation
- Rotate facilitators
- Be disciplined about your action items
- Run experiments
Set the Stage for Everyone to Speak Their Mind
When running your first retrospective, and whenever a new team member joins, it’s important to level-set with the group. The retrospective is a meeting we have specifically to address areas of improvement and sometimes that means saying things that are difficult to say. You’re free to speak your mind while still being respectful to your fellow team members.
We want the team to be able to discuss uncomfortable things. There are two antipatterns for this. One is where you have retrospectives where it’s a bit of a facade and there is some tension about stuff that isn’t being said. The other is where people are overly combative. Both can be resolved by leadership modeling the desired behavior and setting expectations for what the meeting is.
Facilitation, Facilitation, Facilitation
A facilitator’s role in the retrospective is to hold off on their opinions and help everyone else get a chance to articulate theirs. The three big things you want to watch out for as a facilitator are as follows:
- Is everyone getting a chance to speak? Are some people dominating the conversation?
- Are the conversations relevant to the stated goal of helping the team improve?
- When people speak, are they blaming others or being disrespectful?
You’re not likely to encounter the third one as much, but it is the one that should be taken the most seriously and resolved immediately. That is the job both of the facilitator to call it out and of the leadership on the team to ensure that it’s not tolerated. The quickest way to kill the productivity of a retrospective is to cast blame.
You’re much more likely to encounter the first and second scenarios. As the facilitator, try to ask the opinion of others who are being quiet. If the same repeat offenders are taking up most of the airtime, a side discussion outside of the retro is a good place to bring it up. In retrospectives that I’m a part of, we agree at the beginning that we’re OK with being “facilitated.”
When dealing with off-topic discussions, it’s the same strategy. You can ask that we hold off on a particular discussion and get the right people to have it after the retrospective. Facilitation takes practice and empathy. One way to improve empathy is to rotate facilitators.
Rotate Your Facilitators
This is a great way to get everyone involved and build your team. Have the facilitator pick the retrospective and the icebreaker question. Create a supportive environment for people who are new to running these meetings. Encourage facilitators to try new retrospective activities. On the teams I’ve been on with the most impactful retrospectives, we have facilitator rotation. This has the added benefit of keeping the retrospective a fresh and useful experience. We have someone volunteer to facilitate the next retro at the end of every retro we do.
Be Disciplined About Your Action Items
Action items should be clearly defined, have enough context to ensure people remember what they are, and be assigned to an individual. Action items should be captured from each retrospective, and they should be completed regularly. There are a few antipatterns to watch for with action items.
One pattern is where you consistently don’t have or don’t remember action items from the previous retro. If you consistently don’t have any outcomes, there might be something wrong with the format or facilitation. If you did have some, why were they not captured or assigned? Action items and experiments are the outputs that translate the discussion from the retrospective into tangible improvement. If this happens, take on the responsibility as a group to ensure that the action items are captured and assigned.
The opposite pattern is where you have a board or information radiator overflowing with action items, some that are weeks or months old. If this is happening, there are some questions you can ask yourself. Are the action items actually achievable? Does the group review the action items weekly? Are the individuals to which they’re assigned determined to make sure they get done? In this scenario, it’s a good idea to limit action items from a retrospective to a single action item. When you consistently resolve those, gradually increase the items you allow yourselves to have.
Not every outcome of a retrospective should be an action item. Some outcomes might be process experiments. Maybe the group wants to experiment with the stand-up format. Maybe they want to try mob programming on certain types of user stories. In any case, an action item to “try mob programming” isn’t the best way to capture this outcome.
Try to get your team to take these types of actions and turn them into experiments that have defined desirable outcomes. Here’s an example:
- We’re having problems with knowledge silos on hard parts of our codebase.
- We believe that mob programming on stories relating to that part of the codebase will improve everyone’s understanding of that code.
- The engineers are going to mob program on two stories in the next two weeks.
- We’ll measure whether this was effective or not based on a Roman vote of whether we have a better understanding of that code.
Try to get your team to think about how they would determine whether a process improvement was successful. Try new things, but make sure you capture the outcomes so you know whether you should continue to do them or not.
We’ve gone over quite a bit of information, and I hope that some of these ideas resonated with you. Retrospectives are not only good opportunities for high-performing teams to continue to improve, but they also provide an avenue for building team chemistry on new or struggling teams. They empower your teams to own their ways of working, which leads to more motivated team members and better team outcomes.
I’m passionate about teams running retrospectives, and I think you should be too! There are lots of great resources out there on retrospectives. One thing your teams might be consistently concerned about is remote collaboration. Did you know that Plutora can help you with that with its value stream management platform? For other issues surrounding the team, turn to retrospectives.