Goldilocks Goals: How to keep Retrospectives fresh and engaging

Retrospectives are the lifeblood of a team’s drive for continuous improvement and a force for good on software development projects. Teams should have a Retrospective at the end of every single sprint and they should never, ever cancel a Retrospective.

But how do you keep retrospectives fresh and engaging, when they should be ubiquitous and routine? One way to do this is by varying the activities that comprise the retrospective. Running a Stop/Start/Continue post-up every two weeks is going to get stale really quickly. So, if you don’t vary your retrospective activities at the moment, go invest in a copy of Agile Retrospectives by Derby & Larsen or just google “retrospective activities” and gather some ideas.

Another way to keep Retrospectives fresh is to set explicit goals for each session. Often, these sessions are run with an implicit goal of “Let’s see what we can improve”. I’d argue that running every Retrospective with that goal, implied or otherwise, is a mistake. Instead, facilitators should choose a goal related to what’s important in the team/project/company, right now. Doing this will help guide the team toward a subject that is new, interesting or timely, and is therefore worthy of their investment.

Like the interminable Start/Stop/Continue activity, running every Retrospective with the same goal can be a bit… well, dull. Doing so invites the team to think about things in the same way they always have, with the same perspective and bias. In a Retrospective, we should endeavour to look at events and ideas in a new light, to challenge habitual thinking and to be innovative.

However, just choosing a specific, varying goal for each Retrospective isn’t quite enough. You want to choose a Goldilocks Goal.

You’ve guessed it – a Goldilocks Goal is a goal that is “just right”. Just right in terms of the scope of discussion it opens up during the meeting. A Retrospective’s goal should allow the group to thoroughly explore a decent-sized subject but not opening up an area too big with too many possibilities for a 60 to 90 minute meeting to reasonably cover.

The image below represents the structure of a Retrospective meeting, incorporating the distinct stages of the meeting popularized by Derby & Larsen.

New Framework - No ActionsThe session opens up on the left, starting the discussion and gathering data points (the green circles) within a certain scope. Then comes the central, creative section of the session where data is analysed and people start to think creatively; connecting dots and spotting patterns in order to come up with novel insights. The session should then begin to narrow focus, converging the discussion towards an agreed set of tasks and the closure of the meeting.

The meeting’s goal is what opens up the discussion on the left of the diagram, setting the scope and dimensions of the whole session. If that goal opens up a subject that is too narrow or too wide, then the meeting will be ineffective and misaligned.

Goldilocks GoalLet’s use an example: it’s Retrospective time and your team is still recovering from a sprint where they accidently released the installer for the Spotify desktop client rather than their own software (this, obviously, is an entirely made up scenario). You, as designated Retrospective facilitator, decide to go with the usual goal for the session:

“Find out what we can do better”

This is often the implied goal of a recurring Retrospective. There is a real danger here that the story team’s fail is lost amongst the huge number of subjects that arise from the last sprint – bugs, meeting problems, practices, environment, etc. This very open goal could lead to the team being unable to generate any real insight. They will struggle to tie together a legion of data threads, unevenly explore particular bugbears and lose the focus needed to delve into root causes of the most important issues facing the team. At the end of the session the group will, frequently, be left with some relatively inconsequential actions to progress over the next few weeks.

On the other hand, facilitators can go the other way and choose a goal that is too narrow. Doing this will mean the session only supports debate on a very specific topic, data points will be scarce and the group will lack the shared experience needed to engender a proper brainstorm. In our example, you decide to get straight to the root of the problem (as you see it) and introduce the team to the following Retrospective goal:

“Find out what’s wrong with our automated tests”

This goal could easily result in a session that is predictable and routine, where the group will only be able to talk about automated tests and unable to exert influence on what is explored and tackled. The end result of this session may be concrete actions to improve something that is relatively unimportant when compared to other problems on the project. What if we shipped the Spotify installer because of a manual error? What if that manual error occurred because someone was forced to rush to meet an unreasonable deadline?

A goal that is too closed may mean that some people feel marginalized or demotivated, as they are unable to contribute to the discussion. Furthermore, this is a leading goal. The facilitator has already decided the root cause and preferred solution to the team’s problems. This is not cool, and your Facilitator Hat should be confiscated immediately.

So, instead of choosing a goal that is too open or too closed, facilitators should spend some time defining a Goldilocks Goal that opens the debate up just right. Teams need a goal that is open but has boundaries. That way the debate can be influenced and re-aligned by the team, but the meeting is focussed on a key area and is less likely to head off at an unproductive tangent. The boundaries of the goal could be delineated in a plethora of ways – time, function, process, practice, commercial, technical, etc. The facilitator should use their judgement, or the insight of the team, to find a restricted scope suited to the current situation.

In our example, I would argue that the following goal was just right:

“Decide what we can learn from our last release”

This will focus the session squarely on the main pain point in the sprint but will still allow team members to raise issues that they feel are connected (a team member’s absence or a crazy deadline). It should ensure that there are fewer threads of data to explore and analyse, as the discussion is bounded by the timescale of the release and the components that comprise deployment (tests, automation, people, etc). Actions arising from this session are more likely to be tackling root causes of important issues, and ensure the team improve in a valuable way.

So, to recap… in order to keep your regular Retrospectives fresh, engaging and relevant, vary your activities and set a specific goal for each session. Make sure the goal is a Goldilocks Goal; not too open, not too closed, but just right.

When the going gets tough, don’t cancel the Retro

If times are tough on an agile project, whatever you do, don’t cancel the Retrospective meeting.

Let’s be clear, cancelling that meeting is removing an opportunity for the team to inspect the way they have been working, and adapt how they do things so they can improve.

Stop Start Continue

That’s an opinion I’ve held ever since I started working on agile projects back in 2008. It just seems logical to me. I had a conversation this week that reinforced that position.

I was chatting to a couple of members of a development team over lunch about their project.  They couldn’t really stop themselves from complaining about some difficulties their team had been experiencing over the last few months. They highlighted a few issues that they felt could be improved and discussed how they’d like to change aspects of how they work together. My overall observation was – they seemed pretty fed-up.

When I asked if they felt they could discuss these worries in their next sprint retrospective meeting, one of them told me how those meetings had not really helped solve their problems in the past. In any case, their team felt they spent too much time in meetings in general, so they had decided to change their process and only have retrospectives at the end of every other sprint. As a result, they had a retrospective meeting once a month.

I recommended that they have a retrospective as often as possible, given their description of the project. One of the team members stopped me and said, quite matter-of-factly and without a drop of irony, “Some of us, Chris, have a more pragmatic approach”, he shrugged apologetically, “we just prefer action over meetings”.

He looked at me somewhat condescendingly, eyes filled with pity as he considered my misplaced faith in a meeting. How could a group of people coming together to talk about stuff be preferable to actually ‘doing things’?

Somehow I managed to stop myself from slamming my forehead into the table in disbelief. I also avoided making the suggestion that the pragmatist’s preferred action seemed to be complaining about the problems they had, rather than trying to resolve them. I did, however, embark on a robust cross-examination of what was meant by the term “pragmatic”.

My recommendation to the two colleagues (who are good guys, by the way) was to not give up on retrospectives but to talk to their manager/scrummaster/facilitator to see if they can design a meeting together that would help them tackle their problems. And they should definitely have a retrospective every sprint.

I described the kind of retrospective activities that might help surface and explore the issues they were experiencing. A teamwork satisfaction poll, perhaps? Or a Mad/Sad/Glad activity? This seemed to gain some traction with the other team member, who went away to talk to the facilitator earmarked for their next retro.

Teams can label the time they spend in retrospectives as worthless and futile. Often, this is because they’ve experienced some poorly run or structured meetings that have failed to produce valuable, insightful actions. In these cases, I’d plead with a team not to give-up on retros and suggest reading Agile Retrospectives by Derby & Larsen to give their meetings a better chance of success.

Teams have been know to cancel retrospectives if they feel like they are under too much time pressure and are forever racing to reach difficult deadlines. For me, taking time away from your desks to reflect on what is going on when a project feels like it is in a perpetual race against time, is invaluable. To be honest, if you think that having the team in a meeting room for one hour every two weeks is going to make your project fail, then it’s going to fail anyway.

So, if you are on a difficult project and are considering cancelling or reducing the frequency of your retrospectives, ask yourself what the root cause of that drive is. Then consider whether that root cause is something that would actually benefit from a regular, frequent opportunity to inspect and adapt.

Five steps to an effective sprint retrospective

In a typical agile software development process, sprint retrospectives are meetings run at the end a development iteration. In those sessions the team looks back on what they have done and how they have done it, and decides what they can do to improve. More succinctly, the team inspect and adapt.

Inspect and Adapt

In my experience, sprint retrospectives are invaluable and the most effective, timely and action-focus form of ‘review’ meeting. If run right, these meetings can be the life-blood of a development team – encouraging them to habitually build on successes and address problems.

However, sprint retrospectives can be tricky to run ‘right’ and as a result, they can be ineffective. An ineffective retrospective might be shallow – only looking at surface issues and not root causes – or it may even forget the adapt part of “inspect and adapt”.

Here are five things you can do to increase the likelihood of running an effective sprint retrospective:

  1. Allocate enough time for the meeting. Book an hour at least, you can always leave early if you have finished
  2. Structure the meeting carefully to ensure the session flows well, from a clear opening through to the definition of actions at the end
  3. Use engaging (and fun, even) activities throughout the session
  4. Vary those activities each retrospective to ensure that these regular meetings stay fresh and challenge attendees to look at things from a new perspective
  5. Be tenacious when it comes to creating a small number of concrete, actionable tasks at the end of the meeting. These actions are the real value of the retrospective – the teams adaptations and the mechanism through which they will improve.

I’d recommend doing all those things, but I’d like to focus on how to structure the meeting.

Below is a retrospective structure popularised by Esther Derby and Diana Larsen in their book Agile Retrospectives. It has five sections, each with a specific goal.

  • Set the stage – Goal: Set the tone and direction for the retrospective
  • Gather data – Goal: Create a shared memory; highlight pertinent information and events
  • Generate insights – Goal: Think creatively; look for patterns, themes and connections
  • Decide what to do – Goal: Generate and prioritize valuable, clear actions
  • Close – Goal: Summarize and end the meeting

For each section of the meeting, you should plan an activity (sometimes something as simple as each person saying one word) that meets the requirements for that section and progresses the team along their mission to “inspect and adapt”.

I like to visualise the meeting like this:

Retrospective structure

Once you become familiar with the stages of the retrospective and what needs to be achieved, it’s fairly easy to come up with new activities (on variations on existing ones) to make your retrospectives feel fresh. As an example, in an upcoming post I’ll outline a quick activity I came up with to gather data in a recent sprint retrospective I ran with my team.

Create tangible retrospective actions

In my view, the drive to inspect and adapt is the most important concept to have been popularized by the agile software development movement.

It’s an idea that got me hugely excited and engaged in the subject when I first came across it in 2005. This essence of this is that ‘we will always know more about the project in the future than we do right now’. The responsible response to that is to build in regular, frequent feedback mechanisms to our development process to be able to take stock of, and respond to, our improved understanding of the domain, technology, codebase, processes, practices and team.

In my head this is always represented with the following diagram. Where the blue dotted line indicates the original direction we thought was going to be right for the project (or codebase, or process, etc), the black dots represent reflection points, and the green lines represent the course corrections that were taken to improve things. At the end of the project, we ended up with a product or a way of working that we would never have envisaged at the start.

Inspect and adapt

Inspect and adapt

This is why I am such an advocate of having regular, frequent retrospective meetings throughout the course of a project, as they provide these important points of reflection and course correction. However, Retrospectives are only as valuable as the improvements they instigate. Sometimes, even though a team may have identified the right area of their project/process/codebase to improve, the corrective actions they decide on may fail to have a discernible effect. For example, a team may want to introduce a weekly customer support rota because the entire group is feeling impeded by the number of support requests being received.  This rota is drawn up and is respected for the first week, so things start to seem better. Beyond that first week though, there’s a good chance the rota will start to get forgotten and the problem will return.

Corrective actions that are destined to succeed often have a tangible effect on, or introduce a new artifact to, a team’s day-to-day life.  In my example, the support rota is much more likely to become entrenched if there is a visual token reminding people every day that it exists and is something they agreed to do. In my team we’ve done this by placing a big picture of an ogre on the desk of the person on rota duty.

The Support Princess

The Support Princess

When a support request comes in, there is no debate about who’s responsibility it is to ensure the request is handled.  More importantly, the fact that our ‘Support Princess’ token is so big and unappealing means that when a team member’s turn on the support rota is over, they are very quick to hand the duty onto the next person, and the rota cycle continues.

Plus, there is something strangely satisfying about placing a silly picture of an ogre on your colleagues desk.