Continually improving our work habits with retrospectives

Last retrospective we identified three actions that would improve our processes.
At the end of sprint #14 we identified three actions that would improve our processes going into sprint #15.

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

Ideas have now been grouped, circled and a category label given to each.
Ideas have now been grouped, circled and a category label given to each.

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.

Sprint timer results proving that our daily stand-up meetings are now shorter.
Sprint timer results proving that our daily stand-up meetings are now shorter.

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.

3 thoughts on “Continually improving our work habits with retrospectives

  1. Gareth, great to read about your experiences with retrospectives. I’m happy that you pointed out some of the benefits that they have given you. Indeed, problems like the ones with slow PC’s or stand-ups taking too long can go on for months and cause a lot of damage to a team. Retrospectives help to identify and address such problems quickly, and get them out of the way.

    The exercise that you use with sticky notes seems to work out. I think that the variety of “questions” that you ask is a strong point. Terms like enjoyable, puzzled and more or less catch different things, which increases the chance that issues that need to be dealt with will come up in the retrospective. At some time their might be a need for a different kind of exercise, e.g. if issues pop up which need a deeper exploration or are somehow harder to discuss, or if things don’t pop up with the current format.

    Thank you for sharing your experiences with agile retrospectives!

    @BenLinders
    Co-author of Getting Value out of Agile Retrospectives

    1. Thank you for your positive comments, Ben. The approach to retrospectives that we’ve adopted is lifted more or less from The Art of Agile Development by Shore and Warden (O’Reilly, 2008). As we’d never used retrospectives before we needed to start somewhere, and as this was the only book I had that offered a model we decided to start there and see how it went.

      Your book Getting value out of Agile retrospectives—a toolbox of retrospective exercises looks interesting. I’ll need to check it out.

      1. As I said, it seems to work great for you, it helps you to improve continuously in an effective and efficient way.

        Feel free to contact me if there are any questions while reading the book, or if you want to discuss anything. Always happy to share experiences 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *