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, and 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 a 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 okay 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 are 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 view 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, and 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 make 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.
Conclusions
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.
