News

A retrospective is a meeting where the team stop working and take a step back to review how well they are working and what they can do to improve.

It is generally done every sprint (or every two weeks if there is no sprinting going on).

The theory is easy – the team share their views on what went well in the last fortnight, what did not go well and what they should keep doing or change as a result.

In practice though, it often turns into a therapy session where people share opinions about the way the world is really bad (or even how the team is awesome) and then they wander off without taking on any action items.

So when your team have lost their mojo and the retros are getting stale maybe it is time to do a retro on the retro.  Similarly, when you first start out as a team, it is often good to define what you might want to get from your retro.

A standard template for all Agile ceremonies

Teams often do retrospectives because they know they are meant to, but they often don’t fully realise why they are doing them, so they don’t really get value from them.

So I often go through each meeting with the team at the start of the adventure and make sure we all agree on what we want from them.  I do the same in a retrospective every now and then when the team seem to be going to meetings out of habit rather than demanding the meeting give them some benefit.

Here is a template I sometimes use to do that:

We agree what the meaning of the meeting is (in this case “Retro”).  Then I ask people to state who will get a benefit from the meeting (in this case the team).

Next, I ask people to agree on what the meeting gives them and what that helps them with.

In this case, we said that the retro provides the team with a chance to step back and reflect on how things are going and to share views.  This is important because it means the team will gain more control over their destiny and also they will be able to highlight the constraints that they will not be able to remove.

The constraints will then impact what the team is going to be able to do, so it is good for the team to know everyone one is aware of them and to share the constraints with stakeholders so that we set the right expectations for the team.

Finally, I ask the team to explain how they would know the retro is successful and the answer here is that it is successful if changes occur as a result of the retro and if people know how things get done in the team.

You can use the same template to review showcases, standups, planning meetings and even other tools like story-walls, the story tracking robot or whatever.

Discuss how to improve

I also run a session where we identify issues that we might be aware of that could impact our retro … or things to take into account when we run them.  For example, we might find that people who work from home or from another office can never contribute because of our lame technology or the bad habits of the team.

Again I have a template if you want to use it:

In this case, I get people to put post-it notes on the wall with “things to consider” or “possible issues.”  Then I have them add things on the wall to mitigate them.

However, sometimes I complete the issues myself (as I did in the above diagram for a training course).  Then I let people discuss or write down what the team can do about the issues.

Agree to act on what you just talked about

Once you have some ideas for dealing with the “things to consider” then you need to decide which ideas to take forward and then actually act on them.

Posted by James King
Copyright © James King.