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.

Down with the annual appraisal!

Applying agile to people management

As we near the end of the year, people managers across the world will be aware of the looming, ominous shadow of a well-known nemesis – the annual appraisal process. In a vain attempt to avoid identification, this sinister entity also goes by the name ‘end of year review’. In either case, tackling this foe is a thankless task, requiring managers to succinctly sum-up the performance of their line reports while simultaneously developing, motivating and realigning their people. Worst of all, this has to be delivered via a single formal meeting and/or tightly regulated document. Joy.

At Red Gate (my employer), we don’t do annual appraisals. As far as I’m concerned this is a good thing for two main reasons:

1. Annual appraisals don’t work. Certainly as far as them being an effective method of developing people, recognising good performance and identifying opportunities for improvement. They are destined to fail for many of the same reasons that Waterfall software development projects are destined to fail:

  • They involve up-front requirements specification (a.k.a. annual objectives) which fail to respond to the changes that happen throughout the year and don’t encourage people to take advantage of any unforeseen opportunities that may arise.
  • All parties/functions involved in the process work separately on the same project and pass documentation to each other as a means of communication. This leads to misinterpretation and misalignment.
  • They are Big Bang; involving a single, high-value release (appraisal document) that is often unsatisfactory to both parties and contains unexpected content.

2. Annual appraisals are a massive overhead; they take an age to put together. Everyone involved struggles to remember anything beyond the last few months. Additionally, setting meaningful objectives for the whole year is nigh on impossible and time-consuming.

So, at Red Gate we don’t do Annual appraisals, because they’re clearly broken. Instead, we take a more agile approach.

Agile people management

At least once a month, each employee has a “one-to-one” session with their line manager; just the two of them, catching-up, for 30 minutes to an hour. Each monthly meeting is treated like a mini-review, with the employee leading the discussion on what has gone well and what hasn’t gone well in the last few weeks (amongst other things). At the end of the session the two participants agree short term goals, changes and actions for the next month. They’ll review these at the next monthly meeting.

For the line manager, these meetings tend to require a coaching approach rather than a directive one. In any case, regular one-to-ones are an opportunity to recognise great work and give constructive feedback much closer to the actual event than a yearly appraisal allows. Problems don’t get time to grow and fester. New opportunities can be quickly taken advantage of.

Monthly one-to-one sessions work for many of the reasons agile software development works:

  • They focus on repeated, short time periods that can easily fit in your head and be reasonably planned. These iterations can be chained together to deliver a larger  changes.
  • Everyone involved works together on the task, sharing insights and quickly surfacing disagreements.
  • Work is delivered regularly, progress is clear and information is fed back into the process to improve work over the next time period.

Whilst many software development organisations encourage regular one-on-one sessions between managers and their direct reports, they still keep the annual appraisal process as a method of officially measuring performance and developing people. I’d argue they are missing a trick and should start applying the agile techniques they have honed on software projects to their people management processes too.

In a future post, I’ll write in a bit more detail about exactly how I run one-to-ones with my team.

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.

Visualizing team work: Physical Taskboards vs Virtual Taskboards

I’m a project manager, so unsurprisingly I can find myself in animated conversations with other project managers regarding how best to manage the work that our team members are doing. We all have our favourite techniques and methods, but the process generally starts with making the work each member of the team is planning to do, is doing, or has done, visible to the whole team. From there, the team can start to tackle important questions together, such as “are we doing the right work?”, “where we are struggling?” and “are we on-track?”

For the purposes of this post, I’m going to call these work visualizations “taskboards” but they are known by many names. For instance, at Red Gate they are called whiteboards, even though our teams use a combination of boards, walls and windows to host information. My team’s whiteboard is actually an opaque glass wall, but it works just fine!

Our 'physical' taskboard

Our ‘physical’ taskboard

In addition to visualizing the work the team is doing and their progress towards their current goals, taskboards also:

  • Map out the process of turning feature ideas into valuable functionality delivered to our users
  • Encourage team members to focus on team goals
  • Highlight dysfunction, bottlenecks and issues
  • Provide context for the current tasks underway
  • Give perspective on the relative priority of work
  • Encourage the completion of work and reduction of work in progress
  • Illustrate project health to stakeholders

There can be something strangely motivational about the completion of a task causing a tangible change. The ritual of moving a task from the ‘in progress’ column into the ‘done’ column emphasises that you have achieved something.

However, while project managers tend to agree on why it’s important to visualise work, the question of how to do this does not always reach such a clear consensus. In fact, there seems to be a dichotomy between people who favour physical taskboards, filled with tangible post-it notes and index cards, and those that prefer project management software tools, brimming with time-saving functionality and features.

When I tell people that my team exclusively uses a physical taskboard to visualise their work rather than a virtual tool, I’m quite sure some of them consider me to be some kind of Luddite. They proudly, and occasionally smugly, announce that everything pertaining to their project lives inside a computer! This, they assure me, is more collaborative, saves them time and is hassle-free (apart from when it’s down for maintenance).

However, it’s not a fear of technological change that causes me to continue sticking stationary to walls. It’s because I believe physical taskboards best meet my two most important requirements of a team work visualisation:

  1. It radiates information from a central, obvious place
  2. Everyone in the team uses it

The information should be clearly presented and in your face. It should be big and constant, so you aren’t able to ignore it. You shouldn’t be able to lock it away or hide it. All team members should use it, and use it in the same way. It should be trusted as the single, definite representation of the work going into the project. For me, a physical taskboard does this best.

There are many good software tools that can provide a virtual taskboard. I’ve used VersionOne and LeanKit successfully in the past. Personally, I’d only ever use one exclusively if my team was not co-located. In fact, when I worked with a geographically distributed team, I maintained a physical taskboard situated where the few co-located members of the team had their daily meetings.  That was because I wanted an information radiator. Admittedly, I could have done this with a very large monitor that permanently showed the virtual taskboard, but it was cheaper, quicker and easier to tailor a physical wall with index cards.

As a central heating radiator emits heat to passers-by, a taskboard should broadcast project status to everyone who passes it. Often virtual taskboards live in browsers on individual team member’s machines. These browsers can be closed or hidden. They are more like information cabinets. Everyone knows that the project information is in there, but they need to choose to open it up to discover what it says. If you suspect something sinister lives in that cabinet, then you are probably quite unlikely to open it regularly.

Maybe we shouldn’t really be trying to find a one-size-fits-all resolution to the physical vs virtual taskboard debate. Both approaches can work really well depending on the behaviour and location of your team. The more important discussion is whether your team work visualization is an information radiator or an information cabinet.