Retrospective idea: Sailboat

Blue and white sailboat on ocean during daytime
Photo by Evan Smogor on Unsplash

The sailboat retrospective is a model that I especially like to use at the end of significant chunks of work, like a release or the end of an epic or the end of a project. But it could be used at any time, especially if there is a need to better understand project objectives, risks, hindrances and helpers.

I like to use this model for post release retrospectives because it helps the team to focus on lessons learned around unexpected risks, the things that slowed the team down and celebrate the things had really helped us.

Continue reading Retrospective idea: Sailboat

Retrospective idea: one-word

Image by Sydney Sims on Unsplash.

A simple retrospective exercise I like to use is the ‘one-word retrospective’ found in Getting Value out of Agile Retrospectives by Luis Gonçalves and Ben Linders. This exercise is particularly useful for helping teams deal with their feelings.

Simply ask every team member to summarize in one word how they felt about the last sprint.

Continue reading Retrospective idea: one-word

Retrospective idea: starfish

Just as a workman wouldn’t rely on the same tool for every job (unless they have some kind of massive Swiss Army tool), it can be useful for Scrum teams to have a few different retrospective models to draw on. Different approaches help teams to see things from different perspectives.

The starfish retrospective is an extension of the typical three-question retrospective of what went well? what didn’t go well? what could be improved? By asking similar but different questions it can help a team appreciate the practices that are going well as well as consider new ideas. I know scrum masters for whom this is their default retrospective pattern.

Continue reading Retrospective idea: starfish

Continually improving our work processes with retrospectives

On Monday, as the new scrum master on the Vision Tasks team in Dundee, I conducted my first retrospective with the team. In this post I want to share the model we used and why it can be an effective way of running sprint retrospectives.

No process is perfect. Your team is unique, as are the situations you encounter, and they change all the time. You must continually update your process to match your changing situations. Retrospectives are a great tool for doing so.

— The Art of Agile Development by James Shore and Shane Warden (O’Reilly, 2008)

Agile principles

One of the principles behind Agile is that “at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” (Source: Principles behind the Agile manifesto.)

This is about continuous improvement. It’s about slowly but surely getting better at what we do. It’s about recognising that our processes are not perfect, that we are not perfect, but that together we will slowly work to improve things. The Japanese have a word for this: kaizen (改善), which means “change for better” or “improvement”.

The Tasks team runs a two-week sprint from Monday to the following Friday. First thing on a Monday morning we review the last sprint and then retrospectively examine how it went: what went well, what didn’t, what can we learn from it and how can we make things better this coming sprint?

Continue reading Continually improving our work processes with retrospectives

When retrospective objectives stack up

In my last post on retrospectives I said that at the end of each retrospective the team should settle on an action that they believe will help improve the next sprint: the retrospective objective.

James Shore and Shane Warden’s advice on choosing a retrospective objective in The Art of Agile Development (2008) is two-fold:

  1. During the retrospective, don’t worry about the detail: a general direction is good enough at this stage.
  2. Choose just one objective: it helps the team focus, and improve incrementally without feeling overwhelmed.
Continue reading When retrospective objectives stack up