The Real Baseline Agile Retrospective Format

I always considered this six question format to be the Baseline Agile Retrospective Format.  I say baseline instead of standard because a baseline is something to build on, not an ‘always the way’ standard (I know I’m splitting hairs here).

I believe the six question baseline agile retrospective format is a solid way to teach people how to do an agile retrospective. They can see, relatively clearly, the different parts that should be included. It can be a useful starting point to address additional questions and challenges.

To be clear, I do NOT believe that anyone should always use the same format (including this one) for a retrospective.

Many people consider Plus-Minus-Delta to be the “standard” agile retrospective. This is a companion article with Bad Standard: Plus-Minus-Delta Agile Retrospectives in which I outline the issues with using that format for a retrospective. Both are part of the ongoing series of articles on retrospectives.

The Real Baseline Agile Retrospective Format

The start of these questions can look similar to the (not recommended) Plus-Minus-Delta Retrospective. There are critical differences, though, including allowing the team to decide what ideas, if any, to commit to taking action on. That change means more than just asking a few more questions–it speaks to the intent of the process.

I mention in Agile Retrospectives Improve Team Relationships that the core value of agile retrospectives should be understood. I always saw the six question format as a baseline — a way to teach and lay the foundation for that understanding.

Baseline Agile Retrospective
Build on the baseline agile retrospective

1. What went well? It is important to talk about things that went well first. Spending some time on this is important. If you don’t have time to do it every 2 weeks, when will you? Voicing real appreciations on an ongoing basis DOES help people improve. One of my concerns with high-speed retrospectives is that there is often not time for this. You miss a huge opportunity by skipping it.

2. What did not go so well? These are objective-based assessments, not personal issues. You might want to review The Responsibility Process™ before starting this one. Another learning opportunity.

3. What are POSSIBLE actions we can take or experiments we can run to target items that went well or that did not go so well? This question focuses on generating action ideas and experiment ideas. It is NOT a commitment to doing any of them. Does this sound different than “what should we change?”

  • Targeting what went well: There may be things that went well and obviously will continue. Other items may have went well unexpectedly. Recently I worked with a team that was surprised that collaboration with a second team went well. They have not had a lot of cross-team work in the past, but will continue to have some moving forward. Since they were surprised it worked well AND since they are going to have more of this type of work, I asked to hear more about it. This could be an item for them to target. What are possible actions or experiments that may help them repeat this success?
  • Targeting what did not go so well: What are the possible actions? What experiments might make sense? The team can’t target everything that did not go well. They may not even focus on what you see as the most important! Are they focusing on what most concerns them? Ask powerful questions about that, as a facilitator! There are times when the team does not have any ideas. There can be a variety of reasons for this, but it could mean that the retrospective format you are using is not working.

One challenge we can run into is a lack of enough information to make a decision. This can sometimes cause teams to shy away from moving forward. If actions have high risks, you can design experiments to validate hypotheses or split larger actions into smaller ones, much like story splitting. Determine the small slice of that action from which something can be learned. This process should be about brainstorming; techniques such as the 5 whys, 6 thinking hats, root cause analysis, or Impact Mapping can be required to really dig in.

4. Of these possible actions or experiments, are there any we want to act on for the next sprint? If they require take more than a sprint (or iteration), split them into smaller actions or experiments. This is another place where we can start to gauge the team’s interest in improving OR their belief in the possibility of change. Don’t confuse the two. Often, no one wants to act for a reason OTHER than being lazy. This is also a point where a manager may feel a need to “compel” the team to act on something; don’t do it. Let the team make the decision.

5. Fist of Five Vote: Everyone on the team votes using the Fist of Five Voting Method (or another approach that works). Do they want to COMMIT to moving forward with an action from Step 4? Resist the tendency to store and review ALL possible ideas to improve (as noted in Bad Standard: Plus-Minus-Delta Agile Retrospectives). The team should record only the items on which they commit to working. After all, what if a team does not want to commit to improving anything? [that is another article…]

6. What can we improve for the next retrospective? Make a list of ideas. You do not have to discuss or debate the ideas at this point. Realize that some comments might be critical of you as the facilitator (or may feel that way). If that happens, it is okay. Consider it as new information you can use to improve.

I’d be remiss if I didn’t mention that there is much more to a retrospective than only the format.  There are factors such as facilitator experience and energy, opening and closing the retrospective, pre-work, and more that can’t be underestimated.

Assess Your Situation

What are you doing now? What is working? What isn’t? Some of the most common breakdowns in agile retrospectives are caused by not holding true to many of the core elements outlined here.

You can ask yourself if the retrospective you are using is covering the intent of each step, should it? You may run a retrospective that does not cover the idea behind each step, just make sure you (impartial facilitator) AND the team are aware of this going into the process. Check out Agile Retrospective Resources for more information on retrospectives.

Have a challenging retrospective situation you can’t seem to find a solution to? Comment here and ask.

Share

3 thoughts on “The Real Baseline Agile Retrospective Format”

  1. I totally agree that Step #3 of looking at the possible actions rather than what needs to be changed will work much better. This allows for some creativity and maybes to enter the discussion. It seems to be designed to open the discussion rather than shutting people down with “what do we need to change” which can often feel like blame. Very helpful article.

    Reply

Leave a Comment