Skip to content

The Death of the Retro

Retrospectives are one of the great gifts of the agile process.  However there are times when it may not seem that way.  Here are some common issues I have seen and possible remedies.

Bad Timing

Let’s start with the obvious.  Do I really have to explain why running retros at 5pm or late on a Friday, or first thing on a Monday are not the best ideas?

Also avoid directly following on from any other strenuous or tense meetings.

And while we are discussing the obvious …

Many times I have seen retrospectives come up with actions such as “product owner must attend all stand-ups”.  Or “stories must have acceptance criteria”.  They tend to be behavioural actions.

To my mind actions like these are obvious and given that time is precious in a retro, are best put quickly aside.

If anything, a working agreement, as used by many teams, is a good way to log these items so you can quickly move on.  Have a look here to see what Uncle Mike says.

Get SMART yeah

In my opinion, apart from therapeutic value (see below), if you do not come out of a retro with realistically sized actions that are within the team’s remit to do something about and are clearly measurable (go on then, SMART), your retro is not going to help you improve anything.

Boiling the ocean

If they are not careful, some teams will try to take on the world by going for the really big targets.  This is easily done as the really big issues tend to impact the team a lot of the time.  The problem here is that too often teams are unable to do anything about them.

There is a time and a place to tackle these issues, a team retro is not it.

Hello Doctor Freud

I am all for a bit of therapeutic ranting and moaning, but again given limited time, a retro is not the right environment to do it.  Isn’t this what coffee and team drinks are all about?

Granted, a retro is that rare occurrence where the team comes together without having to discuss ongoing work, but still, take it to the pub.

Repeating formats and people

Unless you have particularly thoughtful facilitators, you may end up using the same format over and over and over …..  Yawn.  Where was I?

Think about it, there are many great formats out there.  We all know the “good, bad, keep, change” types.  Why not mix it up?  Run a retro on a particular production issue, story or release.  Theme a retro to narrow scope, rotate the topic.  Buy a book and look at other good formats.  Use a timeline.

Beware any use of tools as this may lead to a repeated format if the tool is not flexible enough.

Similarly, don’t use the same facilitator each time.  Using the same people and same format each time and expecting different outcomes is the definition of … yes, I know you know.  Rotate the strike or look for non-team members to host your retro.

Look here for more inspiration.

Repeated outcomes

Let’s just pause here for a second.  What happens if you are getting the same actions every time you hold a retro?  Why would that be?  It is galling and leads to feelings of powerlessness to see this happen.

Read on, look at the sections elsewhere in this post on actions that the team are able to control and overloading individuals.

Facilitator bias

This is a good one.  I have volunteered to be the facilitator and have a gripe about quality of automated tests.  Let’s see if I can make the retro all about that subject.

Of course, this may not be a bad thing.  But watch out for other valuable team points being ignored.

All the people, so many people …

If you have an hour and a team of twenty people on a busy product, how much time do you think it will take to go through each individual’s contributions?  Or to get consensus on actions?

Also the probability of getting a few late arrivals is higher and thus you end up repeating yourself or giving extra precious time to latecomers to brainstorm issues.

If splitting the team up into smaller agile teams is not an option, maybe splitting the teams into smaller retrospective teams is.  If not, maybe you need more time?  Or ask people to contribute in advance?

Overloading Individuals

It is always a good idea to look at the distribution of actions when a retro task list is being put together.  (That is if you have actions.)  If they tend to be heavily weighted to a small number of people, you have a problem.

If this happens, you run the risk of overloading individuals in the team with the result that the actions never get done.  It may also be telling you something about where the power in the team lies and how empowered the team feels to resolve those actions.

My advice is to reallocate those actions so there is a more even distribution across the team.

Actions opened, never closed

How many times have you left a retro and promptly forgotten about all the actions raised.  Only to be reminded of them next time you have a retro and in all probability the same items come up again?

This is probably a symptom of offer issues listed in this blog.  Overloading individuals with tasks, actions are unrealistic or outside of the team’s control.

However, if this is not the case, try and make the actions more visible.

Two things I have seen that work well are sticking all action post-it notes on a board and put it next to the scrum board or raising stories for each action so they are tracked in the same way as other stories.  Point them if that is what you do.  Prioritise them.  Knock yourself out.

What I am not a fan of, is adding an action review to the daily stand-ups – as discussed in my “Death of Stand-ups” post here

Retro the retro

Finally, If you are brave enough and don’t mind the meta, take time out and retro the retro.  Expose the issues that may be preventing your retros from making headway.

You never know, you might be surprised what comes out.

One Comment

  1. Carol Dekkers Carol Dekkers

    Great article! Too often, teams fall into a rut with no real value or true improvement coming out of retrospectives … Great to have your ideas on how to change that.

Leave a Reply

Your email address will not be published. Required fields are marked *