Recently I had the difficult task of running a retrospective with a team I had little knowledge about. I’d never met the team members before and had no insight into what this team works on or what their skillset is.

A difficult challenge, but one that I was up for, made somewhat easier by the team already working with agile and being familiar with retros, albeit having them fairly irregularly. If you don’t know by now, retrospectives are my favourite ceremony and I have so much fun facilitating them, yet there were many lessons I’ve taken away from that particular session.

Lesson #1 - Always prepare the environment first

Luckily, I had time to prepare the room prior to the retrospective. I like my sessions to be casual, the less furniture the better. The aim of this is to try to make participants feel more at ease, have less distractions, and to prevent the “attending another meeting” mentality. The meeting room was a decent size with lots of natural light - this was something I specifically requested. I pushed all of the tables out of the way and arranged a few chairs in a semi-circle facing the whiteboard (hint: next time, please provide me with beanbags instead.

Lesson #2 - Set the tone

When the team arrives, it’s important to give them a feel for what the retrospective is and what you’d like them to get out of the session. This is fundamental with those unfamiliar with the ceremony or who have had badly facilitated retros in the past. I provided sweets and nuts (hopefully not seen as a bribe) and advised the participants to basically be as comfortable as they can be. If they want to sit on a chair, the floor, jump up or down, anything goes, as long as they can see the board and are willing to contribute to an open discussion and don’t distract their teammates.

Lesson #3 - Play it safe with the game choice

I’ve posted before about retro games - I joined a team who only knew one game, and were so bored of it, so I try to play a different game each time. In this instance this was a bit of a mistake; I started off explaining the basic grid (well; not so well; do differently; puzzles) which the team seemed to understand, then I asked them to choose an object or event (the team knew someone who was getting married so I suggested the “wedding theme”). Maybe it’s just my explanation (some were non-native English speakers) but the retro went pretty off-piste from there on in. The object they chose was a web development library that they had just started using. This focussed the attention on the library rather than the sprint as a whole. Next time I’m with a new team, I’ll choose the grid for simplicity’s sake.

Lesson #4 - Colour coordination

If you’re gonna use post-its or pens, make sure to colour coordinate them to each discussion area (e.g. if ‘well’ is green, choose blue for ‘do differently’). Having had a bad experience of this in the past, I decided not to mandate which colour of post-it they should use. That was a disaster, as after sticking them to the whiteboard, a couple of post-its fell off - lack of colour coordination made it difficult to tell which section it was assigned to. Next time I use post-it notes, I’ll assign a blank one to each category to form a template for the team to follow - visual effects work best.

Lesson #5 - Test the A/C

I tend to forget A/C exists (it makes me sneeze!) until someone makes a point of turning it on high. It may sound silly, but trust me, I’ve learned the hard way. Test the air conditioning prior to the session. Someone will want it on, and you’ll want to make sure it blows nowhere near the board you’re either writing on or sticking post-its to. Post-its + powerful air conditioning = bad retrospective (Lesson #4 helps if you do find yourself in this unfortunate position).

Lesson #6 - Be aware of time

With the team I work with day-in, day-out, we’ve got retros down to a fine art. I rarely have one that exceeds 20mins. New team? Allow at least 1 hour. I made the assumption that we had plenty of time, and before I knew it we were out of time and didn’t address every post-it on the board. Next time, I’ll set a timer on a physical clock for each discussion point - having the team see the time decrease should make the discussions more fluid.

Lesson #7 - Use SMART for Actions

This particular team were not great at coming up with, nor assigning actions to people. A lot of time in the ceremony was wasted trying to coax them to set at least one action and a date to achieve that by. Next time, I’ll go over the SMART mnemonic acronym to ensure they know what my expectations are.

Lesson #8 - Review sprint/kanban boards beforehand

Unfortunately I didn’t have the luxury of seeing what the team was working on prior to the ceremony. In hindsight, this was a huge mistake. A lot of items that weren’t mentioned in the retro were those that were causing problems with the team. Had I seen the sprint board prior to the retro, I could have led the discussion better to talk about the external factors to the team that affects their velocity.

Most Important Lesson

The most important lesson of all is to adapt the ceremony to your environment. Incredibly difficult in this scenario, but when in doubt, play it safe. No two teams are the same, adaptability is at the core of agile, and it most certainly applies to the ceremonies too!