Category culture

I am fortunate to have lived in the Agile world for pretty much the entirety of my career having been introduced to Xtreme Programming right out of college. So sometimes I forget that some practices of Agile teams are not common practice. Recently I was asked about Agile Retrospectives. The person wanted to know what they are and why they are useful. And last but not least, how the hell do you do them? After talking about their original intended use and all the ways that I have used them in non-intended ways I decided to write up a post for our readers!

Agile retrospectives are meetings that are typically held at the end of an iteration in which people involved in the project meet to talk about what happened during the iteration. (Notice I didn’t say what went wrong during the iteration.) Retrospectives cover the whole time period and are about all things, good, bad, and indifferent that happened. They should be thought of as more of a lessons-learned type meeting. At its core retrospectives are a time to reflect on what is working and what isn’t.


Agile retrospectives have tons of benefits but for me the most valuable ones are the following:

  • Retrospectives help teams continuously become better at what they do.
  • They give everyone an opportunity to celebrate success as well as discuss failure.
  • They allow the team to be involved in coming up with solutions to help improve things.
  • They allow the team to have closure on the previous set of successes and failures and start fresh on the next iteration.
  • They build team trust and create a highly cohesive team.

How do you do them?

Ideally speaking, you always have a retrospective at the end of an iteration or sprint. So if you are doing weekly iterations as is the case often times with Kanban then retrospectives should happen weekly. They don’t have to be super elaborate but there are some ground rules you should set. You have to foster an open culture where everyone feels empowered to speak up. Everyone should always know that their voice is wanted and respected as part of the discussion and everyone must believe that everyone did the best job that they could. To use Norm Kerth’s (the father of Agile Retrospectives) own words

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.

And I meant it.. Seriously. Everyone has to feel included and valued for retrospectives to work and everyone really must believe everyone else did the best they possibly could have.

Ok, now that that is out of the way.

There are 3 primary questions we are always trying to answer during a retrospective.

  • What went/worked well for us?
  • What didn’t work well for us?
  • What things can we do to make things better going forward?

There are tons of different ways you can do retrospectives but the absolute easiest one that I have used and works well in my opinion is the :-) :-| :-( Version. I call it the smiley version.

You can draw on a whiteboard the 3 standard smilies. Happy, Meh, Sad. Then have people just openly start saying things they’d like to add to each column. Do make sure they tell you which column they want it in.

Some examples are:

  • Joe says (Project Manager): “Suzie’s new subscription work went live and has really impacted conversions", :-)

  • Mary says (Dev): "The new PR process seems to be working a bit better but I am experiencing a lot more merge conflicts", :-|

  • Suzie says (Dev): "The new subscriptions work went live”, but she indicates it should go in the sad column. :-(

And so on!

Once everyone feels they have put their ideas on the board, or a previously set timebox has expired, then the facilitators open up a discussion around each item. I like to start with the Sad column and get the not-so-great-feeling stuff out of the way. If I were facilitating, I’d ask Suzie if she would mind talking more about her item. She might tell us that while she is glad the code is live and conversions are good, she is concerned that there wasn’t enough time during the testing cycle and is worried there may be problems. She is stressing about the impact it might have on the company. The team can discuss more details about what she is experiencing or is concerned about. The team might suggest setting up a follow up meeting for the team to discuss and make an action plan to address the concerns.

After the team has discussed all items in the sad column they move next to the Meh column and then the Happy column. At the end the facilitator should go down each list and ask is there an action we should take with regard to this item. The team should decide if there is and who on the team is responsible for making sure the action is carried out.

The following week, at the beginning of the retrospective the facilitator should bring up the previous weeks action items and get a status on the progress of the action or its resolution before moving into current Happy, Meh, Sad’s.

That’s it. Just starting to do this very basic meeting could mean some significant improvements across your teams.

With a remote spin

More and more often teams are either partially or fully remote. Some companies have teams where people never meet face to face. You might think it would be hard to have this kind of retrospective meeting using something like hangouts or a phone call but actually, it is not that hard at all. I started doing remote retrospectives a few years back and it wasn’t that different. There are a few modifications I suggest to the tracking and collecting but really it’s the same stuff.

I typically use google sheets for the tracking component. I create a document called “Team/Project Respectives" then I create a tab/sheet as a template.

It should look something like this:

Empty header Reported By Action Items Action Item Owners (optional)
What went well?
Suzie’s new subscription work went live and has really impacted conversions! Joe
What didn’t go well?
The new subscriptions work went live Suzie
The new PR process seems to be working a better but I am experiencing a lot more merge conflicts Mary

Once you have a template you can create a new tab/sheet by duplicating it and adding a date as the name of the tab/sheet.

The coolest thing about this format for me is that everyone on the team can be adding things to the sheet throughout the week. The biggest issue I have experienced with retrospectives is forgetting successes and issues between the time when they happen and the retrospective. A teammate of mine pointed out that it can be a lot of fun watching everyone editing the sheet at the same time all in different colors etc. One thing to watch out for is not over-writing what someone else is typing or has typed so make sure there are plenty of empty rows for people to use.

I recommend having video conferencing on during these. Retrospectives are as much about connecting as they are about improving and it is much easier to connect to a face than to a voice so if at all possible VIDEO ON! However, if you must, with the Google Sheets document you don’t actually have to be screensharing or video conferencing. You can just have the meeting over the phone with everyone looking at and editing the same document at the same time.

Beyond Development

Retrospectives in their original form were designed for development teams and are used primarily at a team/project level to talk about a previous iteration, generally a week to one month long in most teams. However, over the years I have applied and been a part of retrospectives in lots of different contexts. I have seen companies use them on a monthly basis as a way to determine how things are going overall at a company level. I have seen them used in multiple departments such as Marketing, HR, and Customer Support. This to me is one of the coolest things about retrospectives. The idea is very basic and extremely flexible and powerful.

I have also seen a multitude of different types of retrospective exercises and processes that are used for particular objectives.

  • There are exercises to use when your team is tense and not communicating well.
  • There are exercises that are all about helping people express their feelings.
  • There are exercises for team building and all sorts of stuff.

So my suggestion to you is that if you’ve never done them before, give it a try with your current team. Do it for at least two months and be strict about doing them. Don’t miss any! I bet you at the end of the two months when you ask in that last retrospective, "Is this something we want to keep doing," the answer will be yes.

Ok, ok. I made retrospectives sound rainbows and sunshine and we all know there is always a downside so I hear you saying.. "yeah yeah.. what’s the catch”. Well, to be frank, retrospectives can get super boring or time consuming, and when that happens they aren’t as useful. For that reason I recommend getting multiple retrospective facilitators in the works. Make sure they enjoy being a facilitator and that they don’t mind doing a little research in order to spice things up. There are lots of games and activities you can do that will help keep the retrospectives engaging and entertaining. Hell, come up with your own game and share it with the rest of us!

I am including some resources I think will be helpful to anyone interested in doing more with retros than just the basics. I actually prefer the Agile Retrospective “Making Teams Great” book over Norm’s Project Retrospectives Handbook, but they are both great resources. For a bit of flavor and fun try the Fun Retrospectives site.

Enjoy and Happy Retrospecting!