So, you’re Agile…When was your last Retrospective?

Henrik Øllgaard
7 min readOct 28, 2022
Photo by Parabol on Unsplash

People who say that they’re working in agile ways seem to forget the perhaps most important element: The restrospective. I’m here to convince everyone that they must do a retrspective in one form or another. Literally, it means looking back. Often this is a great way of learning from your wins and also mistakes along the way.

If you heard about agile, you probably heard about Scrum. In Scrum one the events is the retrospective at the very end of every sprint (a time-boxed iteration of typically 2 weeks). According to the 2020 Scrum guide, during the retrospective:

The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved. The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible.

So, the team reflects on what went well and what should be improved. I’m sure we can all see the benefits here. In theory, at least.

However, when asking teams, team leads, project managers etc. whether they do retrospectives the answer is far to often a low-voiced “No….”. The answer to the obvious “why” is typically: “It takes too long and we have too many meetings as it is”.

Ok, keeping wasted time to a minimum is of course praiseworthy. But, the retrospective is an investment, not the opposite. To illustrate, let’s imagine a team of six people. They’ve been around for a while and good at their jobs. However, as we all know, bad habits tend to sneak in here and there. For instance, showing up late for meetings or sending emails to people who don’t need the information.

Those are just little things that soak up energy. So, imagine our team spending one hour every two weeks discovering ways of doing things a little more efficiently.

Let’s say for argument’s sake that the team can come up with 0.5% reduction in wasted ressources and let’s take time as a resource because it is easy to calculate for our example.

The team works 40 hours per week totalling 6x40 = 240 hours per week. Now, 0.5% of 240 is = 1.2 hrs. Per week. So a one hour meeting just saved us 1.2 hours per week. Not just for one week, but every week.

But the team is six people, so it took six working hours to arrive at 1.2 hours saved. So, in theory after six weeks we start reaping the benefits. Provided we can keep up the changes made, that’s at least one work week saved per year.

It doesn’t sound like much you might say. But imagine improvement as an ongoing mindset, codified in a bi-weekly short meeting. It adds up. Continuing our theoretical argument one work week saved per meeting would add up to 26 work weeks (for one person) every year.

Ok, that’s not real life, I know. The example above is just to make an argument and reality is not that simple. For instance, just measuring time is very crude. What if it’s not 0.5% but 0.25% imporvements etc.

What is important to note is that we can define and measure improvements in many ways and it’s the mindset of improvement that over time delivers amazing results.

One improvement could be moving our scrum (stand-up, daily coffee, whatever you call it) to 10.00. That way a team member stuck morning traffic won’t force the whole team to wait 5–10 minutes several times a week. Something like this is easily measured and a very soft way of introducing an improvement mindset.

Other improvements might have larger scopes. Should we experiment with with banning emails after 8 PM? Experiment with new software to see if we can find better alternatives? Some things may be difficult to measure in terms of metrics and numbers. But remember that a measure could be reported well-being, less stress.

The Perfect Retrospective

How then, can we use perfect retrospectives to increase productivity, well-being, less stress and overall team performance? Ok, the perfect retrospective is the one that creates value to your team, organization or even personal development. But of course there are techniques tried and tested to help you.

But first of all, it is vital that the retrospective is planned and scheduled for everyone. My advice would be to schedule 30 minutes for every week interval depending on cadence: 1 hour every two weeks or 30 minutes every week etc.

Attending the retrospective should not be optional. Making sure that retrospectives are scheduled and attended may sound trivial but far too often retrospectives are regarded as an lavish luxury.

The mindset seems to be that retrospectives can be skipped or cancelled if more pressing matters arise.

The thing is, that there is always more urgent stuff to address. And, because improving the way we work is a continuous long term process the importance may not be as obvious. If we’re behind on delivering an order, on the other hand, urgency itself makes the problem look important.

But maybe we should consider that a bit of reflection could help avoid us being behind all the time. And that’s why you need to schedule retrospectives.

Ok, so we scheduled our retrospective for one hour and everyone is present. Who is everyone? In the end, that depends and the team can invite who they want. But every team member should be present as a minimum. If you have an agile coach, Scrum Master or similar, they may attend and facilitate the process. As a general rule, management should not be present. A boss in the corner may distort thing and the last thing we want is another perfomance review. The team may of course decide to involve management from time to time in order to have a dialog or show what’s going in.

There are a lot of different formats that you can use and I’ll sketch out one take that I found to work for a lot of teams.

Before the retrospective, it is important that the facilitator, coach etc. thinks about how to establish a space of trust. If there are big festering conflicts in the team, perhaps it would be a good idea to adress those in advance.

In the beginning of the retrospective, make sure that the facilitator outlines the purpose of the retrospective and what the outputs and outcomes should be.

The outcome should be related to improving team performance in a broad sense: Workflow, tools, wellbeing, productivity etc. This is not the time to discuss things that are related to products, clients, strategy etc. There are other forums for that.

The outputs are the tangible or visible commitments that are agreed upon. Often improving means experimenting and to achieve good experiments they need to be time-boxed, precise and measurable. Time-boxed means that time is how long the experiment will run. Perhaps moving the daily standup to 10.00 for two weeks and see if there are benefits. Precise means and who is going to do it and responsible. Perhaps one or two team members spend one day experimenting with a new software to see if it can provide value.Measurable means that it should be clear what the intended outcome is and how it can be evaluated.

The Simple Retrospective

I call it simple because it follows a set agenda with action points. You need a facilitator. This is often an agile coach but any team member could also assume the role. The facilitator takes notes and minutes that are shared with the team and perhaps other stakeholders (like management)

  1. Introduction
    Facilitator sketches out the plan for the retrospective
  2. General follow up:
    How are we generally doing in terms of our previous commitments?
    Are we still embracing the good things and avoiding the bad things?
  3. Evaluation:
    One or more experiments have been made since last time.
    Did they go well? You agreed to measuring the experiment in some way. Based on this, how did it goo?
    What did we learn from them?
    What should we continue doing and what should be scrapped?
    How will we ensure that we embrace our new learnings and keep doing what works?
  4. Retrospect
    We have just completed a cycle, iteration or sprint. It is time to evaluate the work process. Answering some questions can often create a good conversation:
    What went well?
    What did we do that made things go well?
    What didn’t go as well?
    What could we have done to avoid this?
    What should we do more?
    What should we do less?
  5. New experiments
    At this point are there any new things, big or small, we want to try out?
    Keep it to one or two things at a time. Make sure your experiments are time-boxed, precise and measurable.
  6. Other business
    This may be ideas or other topics that arise

After the retrospective it is important that notes and minutes are shared. If you have a backlog, you can add whatever new experiments you have agreed to. If appropriate, share with other teams, leader, clients or other stakeholders.

And that’s it! I hope I have convinced you to try out retrospectives. Of course you can and should experiment with your own format. Don’t forget that it is you, the Team, that owns the retrospective so it should suit your needs. At the same time, as always, don’t be a zombie. Or, in other words, don’t just do retrospectives because someone tells you to, but do it because you benefit. And if you don’t benefit, change them to suit your needs.



Henrik Øllgaard

Insigthts Discovery Practioner. My work range from a professional interests as an Senoir Lecturer of Computer Science and agile coach to my passionate History