How Did Your 2020 Agile Retrospectives Go?

Added to Process

Look back at last year and imagine you did not run any Retrospective. What would have been different?

If the answer is little or nothing, read on. I might prompt some useful questions to make your new year retrospectives even more effective.

Agile Retrospectives are a well known “ceremony” that stems from the 12th Agile Principle:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


Psychological Safety (PS)

The term Retrospective (shortened to Retro) is very often associated with three questions: What went well, what didn’t go well, what would you do differently (*) on any action item. Often the questions are phrased differently or a metaphor is introduced, but the bottom line is the same.

This approach is easy to pick up but it requires the presence of psychological safety (PS). Lacking that will jeopardize even this very basic 3-question approach.

What was the level of PS in your retrospectives? Lack of it shows up in people blaming each other, or conversation heating up fast when sacred cows are even mentioned.

How did you assess PS in your retros? When there was a lack of it, what did you do? Did you try to change, influence or respond to the system to foster PS?


Decide what to do

Assuming you have Psychological Safety, the next question is what action items came out of your retros?

Was the retro just a long whining session with no action? Or did you get way too many action items on top of the ones from the previous iteration?

What kind of action

Are your action items well defined and supported by the group? If not, they won’t be completed. Acronyms like SMART (Specific Measurable Achievable Relevant Timebound) and FINE (Fast feedback, Inexpensive, No permission needed, Easy) help give clarity to those action items. For complex problems, having an hypothesis and ways to detect if your experiment (aka action item) is positively or negatively influencing the system.

Not all action items should be the same. Depending on the kinds of problems you’re looking at you should use different approaches.

Does everything need to be discussed?

There is a misconception that all topics that come up have to be discussed during retro. Let me clarify that if you try that you will run out of time and have just shallow discussions.

You must cluster and prioritize your topics. And when I say you, I mean the group.

If you’re running the retro yourself, encourage full participation and do not cluster for the others. Wait for them to start. If they won’t do it, did you ask why? Did you dig into that?

Actions the team can control, influence, or in the soup?

What are the actions within the sphere of team control? In their sphere of influence? Or outside of all that (in the soup)?

Did you start focusing on what the team controls? If all seems to be outside their control, perhaps you can change granularity and see that the team can influence or control parts of those issues. Ultimately the team can always define how to react to events they don’t control or influence. That’s an action item.

This approach can yield good initial results, but in the long run the feeling is your action items are just picking low hanging fruit.


The next level

The teams I work with outgrow the 3-questions approach pretty fast and get a feeling that retrospectives are picking low hanging fruit.

The 3-questions approach lacks adequate reflection time and does not foster divergent thinking. That is ok for clear outcomes and some complicated problems, where spending a few minutes is sufficient to find convergence and decide what to do.

What I often see is topics camouflaged as simple when they are really less traceable. The hurry to zoom through all the topics does not help.

Generating insights from your data

After you gather your data, use a prompt like “how could X be amazing?”. X can be the prioritized cluster from the previous phase, a static sentence, or a theme that the retrospective is focused on.

When you collect events in your retro, you should gather data about the past. Hold off on “What would you do differently”. First the group must have a mutual understanding of what happened. That’s not consensus or agreement but simply seeing all points of views about the past before moving on to what we want from the future.

That’s why I do not mix interpretative or decisional questions (like “What would you do differently?”) with questions to remember events such as “What do you remember of the last iteration?” or “What was a high point of the last retro?”.

I also stay well clear of start, stop, continue. The stop is again a call to action before we look at the data. When those or similar prompts are used, I see groups take decisions that are not sustainable agreements. When they are, they are business as usual decisions. They also tend to generate a massive number of action items that the team doesn’t have energy for.



After reading this blog post think again about your 2020 Agile Retrospectives. What changed? Do you see them differently now?

What have you read from this post that made you shake your head in disagreement? What made you nod in approval?

Let us know and join the Agile Alliance Principle 12 Initiative to make Agile Retrospectives even more purposeful and effective.

About the Author

Enrico is an agile coach and (visual) facilitator with a background in product management and software development starting in 2001. He worked and lived in Europe (6 years), Australia (7 years), and the US (6 years).
Enrico is a visual thinker, if he’s not looking in the camera he’s probably sketching the conversation–lately on his iPad.
He thinks agile is not a recipe to follow but something to tailor to your complex context. He likes to prepare facilitated sessions that are purposeful and meaningful to the group.
He stays well clear of any certification, he attended Cognitive Edge Cynefin Foundations and ICA ORID facilitation training and he’s a member of IAF (International Association of Facilitators).

This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.