Who Needs Retrospectives?

Who Needs Retrospectives?

[Tl;Dr: Which elements of the way the work works in your organisation exist to serve a real need of an actual person? All elements which do not are waste.]

I don’t intend this as a rhetorical question. But rather as an opportunity to consider the Antimatter Principle via a practical example.

Note: In a previous post I wrote about the problems with retrospectives, and some possible solutions to same. What I DIDN’T raise in that post was: the need for retrospectives of any sort.


On the face of it, a team – for example, a Scrum team – needs retrospectives, or something similar, to help them improve their ways of working. This is the “Check” step in the Plan-Do-Check-Act Shewhart Cycle. Retrospectives offer an opportunity for the team to check (study) their ways of working, and consider how well their ways of working are serving them – how well their ways of working are serving them in getting folks’ needs met more generally.

Retrospectives can be quite handy for those teams where folks have found they have a need to improve. We might choose to express this more specifically as “…teams where folks have found they have a need to improve their ways of getting folks’ needs met”.

Aside: Some teams may have been ”told” to improve, and so have a need to improve to keep their employers happy. We might imagine that – in this case – the need is someone else’s. A higher-up, somewhere. Other teams may have found some intrinsic need to improve, such as a desire to learn more, or “become all they can be”. Others again may have embraced the new frame of the Antimatter Principle, and become aware of the need to continually find better ways of getting everyone’s needs met.

No Need

But for the vast majority of teams I have seen, no such need exists. These teams may be in organisations where improvement is not a priority. Or the folks in these teams may not have found any intrinsic need to improve. Or they may not have embraced the Antimatter Principle. If no such need exists, then any attempts at retrospectives will never be anything more than “going through the motions”. In other words, busywork with no purpose. In such situations, how likely is it that anything of value will emerge from the retrospective sessions?

Of course, so-called retrospective sessions may be serving other needs, such as providing a collective break from the daily grind of sprints. Or the chance to get together to chat socially. Camouflaging these needs under the label “retrospective” may be necessary in certain organisational climes. But in these circumstances, these sessions are retrospectives in name only.

So, in your organisation, whose needs are retrospectives serving? Maybe if you can find out who, you can go ask them just what their need is, and thereby come up with some outcomes that your retrospectives can deliver. Otherwise, you’re just retrospecting – or pretending to – in the dark.

– Bob

  1. Agile Retrospectives (or any kind of feedback mechanism) only work if the intensions why you do it are clear and sincere. For teams who are willing and able to improve themselves, to learn, to deploy their strengths to become even better as they are already.

  2. Ask some questions during the retrospective:
    1. Did anything we did not work right? Can we do that better?
    2. What can we learn from this recent experience that will help us in the future?
    3. Is there some way we could change how we approach such tasks that would work better in the future?
    4. Did we fail to consider some of YOUR personal needs as we did this step of our larger project?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: