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 teams. In my opinion, teams should retrospect on a frequent cadance (every week, sprint, fortnight, iteration) 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 the same Stop/Start/Continue post-up every two weeks is going to get stale really quickly. If you don’t vary your retrospective activities at the moment, go invest in a copy of Agile Retrospectives by Derby & Larsen, check out www.liberatingstructures.com or just google “retrospective activities” to gather some ideas.
Another way to help 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. It invites the team to think about things in the same way they always have, with the same perspective and biases. 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.
The 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 broad, then the meeting will be ineffective and misaligned.
Let’s use an example to illustrate the impact of goals that are too broad, too narrow or “just right”…
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 team’s failure, and the all important lesson, 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, as they 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 should 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 or 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.
This article was first posted on Leading Agile Teams.
