Team Retro Gremlins

Like nasty little gremlins these anti-patterns will chew up your retros and spit them out if you don’t have a plan to deal with them!

Like most full-time agile team coaches I have done my fair share of team retrospectives. In the early days I focused on “doing a good job” — as a facilitator. So I dutifully studied and practiced the different types of retros. I did “Liked Learned Lacked”. I did the Sailboat Retro. I did mood graphs to set the scene. I even did a Star Wars retro once.

Over time though I noticed that no matter what techniques I used; the same anti-patterns would emerge. My focus now is not so much on new and innovative retro techniques but on helping teams navigate the anti-patterns that develop.

This article lists some of the retro gremlins I’ve seen, and gives some thoughts on how we can stay on the journey of continuous improvement without these nasties biting us along the way.

The gremlins (anti-patterns)

Anti-pattern 1. Team doesn’t buy in.

This anti-pattern can manifest in a few different ways: some team members don’t show up at all for the retro or come very late. There is a sense of low energy and dis-engagement.

Anti pattern 2. The immediate dominates the important.

As human beings we have emotions. If we experience something negative during an iteration - for example a production incident, or a negative interaction with another team then this will affect our emotions more than a long running systemic problem. You can be sure that these front of mind problems will be raised in retro, and they will have energy behind them. In this anti-pattern retros almost always focus on the immediate, at the expense of the important.

Anti pattern 3 . “Take it to retro”.

Sometimes during a stand up a team process or team dynamics issue will come up. For most teams as soon as discussion gets started on this, the cry will go out, often from the team facilitator: “lets take this to retro”. Many times however we don’t take the issue to retro at all, or if it does happen, the item has lost context.

Also, for team relationship issues, if someone feels awkward bringing up a topic at a stand up, they are unlikely to raise it in the more formal atmosphere of a retro. “Take it to retro” in this anti-pattern becomes code for “this is hard, lets not deal with it”.

Anti pattern 4. Over-focusing on constraints.

All team face constraints. Often the chief constraint is a reliance on another team to be able to progress a piece of work. In this anti-pattern the focus becomes on ‘what’s not right’ — without a corresponding focus on how to work within the constraint while seeking in parallel to mitigate the constraint.

Anti pattern 5. Retro as team bonding.

This is a subtle one. As there is human element to a retro — we’ve finished what may have been a challenging iteration and now we gather around the (metaphorical) campfire to share stories and bond. Over time though team bonding focused retrospectives will result in a lack of energy and team buy in will decrease.

Anti pattern 6. Once over lightly.

Retros are generally time-boxed, and by the time the data is gathered and discussed it is not uncommon to be faced with a whiteboard (or virtual board) with 20 or more sticky notes. Perhaps some can be grouped, lets say we get to 5 items. In a a one hour retro there may be 25 minutes left for this part (30 minutes to gather, discuss and analyse the data and allowing 5 minutes to wrap). That leaves 5 minutes per topic. The items are rushed through, some action points hastily generated. This is improvement lite, with no real traction gained

Anti pattern 7. Much discussion, no decision.

In this anti pattern opinions are voiced, there is much debate and perhaps even some emotion. And at the end of it all, time’s up and its on to the next meeting.

Anti pattern 8. Action points not given priority.

Many of us will be familiar with this one. Lots of action points, little action

Anti pattern 9. Action points are almost always process tweaks.

A team process improvement is a valid outcome of a retrospective. But if the outcome of retros is consistently team process tweaks (adjusting the time or duration of team meetings, a new field in Jira, resolution to stick to the time-box in stand ups and so on) then you may be in the improvement lite zone.

The gremlin busters (patterns)

As I have said in my introduction I don’t believe the answer lies in better facilitation, although of course our craft is important and we should always be seeking improvement for ourselves as well as our teams. Here are some patterns that may help battle these retro gremlins:

Pattern 1. Eyes open.

Awareness is often half the battle. Be aware of the traps and make plans to avoid them. I’ve listed some potential pitfalls in this blog, you will be aware of others.

Pattern 2. Harness the power of “now”.

Focused team time is precious. Does a team process improvement need to wait for retro? What if the team spend a few focused minutes at stand up to come up with a solution to something that is slowing them down? A new workflow step can be agreed and implemented in minutes, if it doesn’t work out we inspect and adapt.

If there is a team dynamics issue, is there a specific conversation you can have with the team members involved now? “Now” is when the issue is freshest in people’s minds. This won’t be possible for all impediments, but from experience sorting it “now” is sometimes more possible than we think

Pattern 3. Pre-select discussion items before the retro meeting.

Lets take a look at the anatomy of a typical retro. We set the scene, bringing to mind the last iteration, we then gather data. We attempt to understand the data, discussing the various points raised. Opinions on the data are voiced. The data gathered, usually in the form of sticky notes or their electronic equivalent is then analysed and grouped and perhaps prioritised using dot voting or similar. This takes time, in my experience up to two thirds to three quarters of the retro. Two thirds of our precious time — gone.

Let me ask you a challenging question — what if we did planning the way we do retros? The team simply created the stories on the fly in a single meeting? No Product Owner, no product discovery, no story mapping, no refinement, we just “come up with them” on the spot doing some silent brainstorming and grouping. We would surely see this as an anti-pattern. Why are we doing retros this way?

Consider an alternative. We start the meeting with an agenda of one or two items that we have agreed as a team are worth discussing and attempting to progress to the next step. The full team focus for the full duration of the meeting. What would you lose by giving this a go?

Pattern 4. Have clear roles.

If your team does not have clarity on roles you will struggle to have effective retrospectives. Roles are a wider issue — for more on roles in an agile team have a look at my blog on team roles.

Pattern 5. Review retro effectiveness.

From time to time, pause and reflect on the effectiveness of the retros you are doing.

Ask the question “What would we lose as a team if we stopped doing retros?”. If the answer, after rationally collating and reviewing the team improvement data, is ‘not a lot’, then there’s work to do 😊