Continually improving our work habits with retrospectives

Gareth Saunders

Wednesday 11 March 2015

One of the principles behind the Agile development method we use 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”.

We run two-week sprints: from Monday to Thursday on week one, and again Monday to Thursday on week two. A portion of Friday is kept clear each week for support and maintenance, but the larger part of the second Friday is devoted to planning in the afternoon, following a sprint retrospective in the morning.

The retrospective is always facilitated by someone; so far, it’s always been me.

Step 1. Ground rules

Before the retrospective, as a team we collectively look over our Trello board (where we track our projects) to look at what work we completed during the sprint, and evaluate whether we successfully met our sprint goals or not.

This allows us to go into the retrospective with a clearer picture of what happened. So much happens during a sprint that it can be hard to remember what we did two weeks ago.

Then we set the ground rules for this session and all agree to the following:

1. We will stick to 1 hour.
2. We will be honest.
3. We will accept everyone’s opinion without judgment.
4. We will try to not interrupt.
5. We will talk from our own perspective, and not speak for anyone else.
6. We will not make jokes about other people in the room.
7. We will not check mobile phones, email, etc during the retrospective.

As part of setting the stage for the retrospective, I read out what is known as Norm Kerth’s ‘prime directive’, and ask everyone to verbally agree to it.

The prime directive, which was written by software consultant Norm Kerth, sounds quite Star Trek-y, but it’s not quite as geeky as that. Its purpose is really to help ensure that teams have the right culture of openness and honesty.

This is what I read out:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Step 2: Brainstorming

For the next 20 minutes — though it’s usually shorter — armed with a stack of Post-It^® notes and a Sharpie^® each (other sticky notes and pens are available), we individually reflect on the last sprint and brainstorm ideas that fall under the following headings, which I put up on a whiteboard:

• Enjoyable
• Frustrating
• Puzzling
• More
• Same
• Less

Step 3: Mute mapping

Having filled the whiteboard with a colourful patchwork of ideas, the first thing I do is read out each idea. We now hear what everyone has written. Sometimes this prompts new ideas; these get added to the board.

I then set a timer for 10 minutes during which we silently group all the cards into categories. There are three rules:

1. Put related ideas close together.
2. Put unrelated ideas far apart.
3. No talking.

It’s a surprisingly effective technique.

Once done, I take a whiteboard pen and draw circles around each group of sticky notes and we give collectively decide on a label, e.g. content strategy, social, tech, tools, training, time management, etc.

Step 4: Vote

Having categorised the ideas, each member votes on which categories should be improved during the next sprint.

I hand out five magnets to each member of the team. Participants can use them as they like, depending on how strongly they feel about the issues raised. They may put all five magnets on one category, or one magnet each on five categories, or somewhere in between.

Step 5. Retrospective objective

There should now be a clear winner.

Or two.

Or sometimes three.

We clear the board of all the other categories and discuss which category or categories we should focus on during the next sprint, and brainstorm ideas to finally agree on specific actions to improve how we work.

These objectives then become actionable tasks during the next sprint. Sometimes we might add something to our process, or else we might remove something. Either way the idea is to make things go better.

Slow PCs

Sometimes it’s obvious and the actions that come out of it are pretty simple to fix. During the first retrospective, for example, almost the entire team identified that their PCs had too little memory for the work they were expected to do with it. Simple fix: order more memory. The total cost was about £200 but as our PCs now start up a little faster and don’t grind to a halt while trying to multi-task or open enormous graphics files we must already have recouped that cost through increased productivity.

Daily stand-ups are too long

Another example. It was identified during one retrospective that our daily stand-up meetings were taking too long. There are only seven of us so they shouldn’t be taking any longer than 15 minutes maximum, if you stick to the guide of two minutes per person plus two minutes.

The retrospective objective for the next sprint was simply this: use a timer for stand-up meetings. A simple solution and it proved very effective.

We ran timers every day for the following two sprints and now we don’t need one: daily stand-up meetings are now as short as they should be, and any extra chat is left to the end and optional.

Ad hoc requests

Sometimes the answer isn’t quite so straight forward. A noticeable frustration was noted during our last retrospective about ad hoc requests that land on our desks from time to time. There had been a surprising number during that past sprint.

On the surface it looked like they all fell outwith our general team objectives. But as we discussed them more fully it became clear that only one did. What initially seemed like an enormous mountain of a problem turned out simply to a simple conversation to have with someone.

The real value in retrospectives

This is where the real value of holding regular retrospectives becomes apparent for me. These often small niggles, if left unaddressed, can prove to be destructive in the long term. Not only do they affect productivity but they can also destroy team morale.

How long had people been grumbling about their PCs being slow? Six months? A year? Longer? One this was identified it took 10 days to resolve.

If our stand-up meetings had continued to run for 30 or 40 minutes then that too would have had a detrimental affect on the team. Not just that it eats into development time it may have led to some team members not sharing valuable information for fear that the meeting went on too long. And as we all know from Master Yoda, fear leads to anger, anger leads to hate, and hate leads to suffering.

Collectively unpacked what was behind those ad hoc requests, I felt, gave us a real clarity about the different types of requests we get, how to evaluate whether we take them on straight away or not, and how to deal with them.

In identifying that all it required was a conversation, it gave us an opportunity to build bridges and educate rather than defensively close doors.

At the end of this week we’ll sit down for another retrospective. I don’t know yet what we’ll discover, but I do know that it will be valuable and another step towards us becoming a better team.