Retrospectives are easy. They are easy because they are just a fancy word for a meeting in which the goal is to reflect on the past in an attempt to improve the future.
Retrospectives are hard. They are hard because they are only effective if they catalyze change, and change is hard.
Which one of these statements resonates the most with you? If your team is mature and well-formed, if its members have trust in and empathy for one another, and if continuous improvement -- from both process and a technical perspective -- is part of its ethos, you probably read the first sentence, smiled about life, and said "yeah, that's us!"
As for the other 99% of you, read on :)
The top 10 things you need to know to run effective retrospectives
1. The Retrospective Prime Directive
Defined by Norm Kerth, the retrospective prime directive states:
“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.
Norm Kerth (retrospectives.com)
Enough said.
2. Your Output Should Be An Action Plan
Retrospectives, in and of themselves, have little to no value. Instead, retrospectives lead to value by catalyzing continuous improvement and change. So one of the most important things to keep in mind while running your retrospective is "What can we do right now to ensure we will actually get better over time?"
The answer lies in action plans. Actions plans are a list of concrete steps you will take after the retrospective is over to follow through on the promises made during the retrospective. It's not enough to complain about your team, your management, or your bad technical practices. You have to do something about it, or the retrospective will have been a waste of time.
Your action plan should be written in an actionable format. Some teams choose to follow the SMART acronym (specific, measurable, assignable, realistic, time-related). Others follow the Who, What, When paradigm (who will be responsible, what will be done, when will it be done by). Both work well.
However you choose to build your action plan, make sure you build one. It's the single most important artifact your retrospective should generate.
3. Use a Facilitation Technique
Imagine if your software development team didn't follow any processes or paradigms at all. No scrum. No kanban. Not even any waterfall. Just cowboy coding. Can you imagine how much of a mess that would be? (You do follow some software development methodology, right? Right?)
Apply the same line of thought to your retrospectives. If you don't facilitate your retrospectives with a technique like Mad Sad Glad, 4Ls, or Lean Coffee, your team will have less of chance of generating good ideas and they will be less engaged with the process.
4. Vary Your Facilitation Technique
Great, so you've started to run facilitated retrospectives. After a few times using the same technique, your team gets bored and starts to mentally check out before the retrospective even begins. Now what? The answer is to start introducing other techniques.
There are many techniques out there. In fact, whole books have been written describing them. So don't limit yourself to a single technique, instead take the time to master many techniques and pick the right one based on your team's specific situation and the impediments it is facing.
5. If There's Resistance, Run Your Retrospectives In "Stealth Mode"
![_f2m3mEkaaU[1]](https://cdn2.hubspot.net/hubfs/1892587/Imported_Blog_Media/f2m3mEkaaU1.jpg)
In some organizations, the concept of taking regular and frequent breaks to discover how to improve is entirely foreign. There may even be some push back as to the value of retrospectives in general. If that sounds like your organization, start by running your retrospectives in stealth mode.
I got this idea from Ben Linders, who first started running his retrospectives this way. To run a stealth retrospective, drop the word "retrospective" entirely. Instead, focus on creating an environment that stimulates growth, openness, and improvement. You might not even need to schedule a formal meeting to kickstart your stealth retrospectives. Take teammates out to lunch individually. Do coffee with your manager. Try to find out what's holding the team back in an informal way, and then take action on it. The most important thing is...
6. ...Make Sure You Follow Through
So your retrospective is over and you have an action plan. What now? The most important part: follow through!
Retrospectives are not simply a box to check off so that you can say "we're doing scrum!" Nor are retrospectives an end in and of themselves. Rather, retrospectives are a means to an end: continuous improvement.
So, it's critically important to actually do the things on your action plan. You'd be surprised (or perhaps not) at how many teams run their retrospectives by the book...and then completely fail to follow through afterwards. For those teams, retrospectives actually become an impediment to improvement and a waste of time. Why run a meeting whose goal is to catalyze continuous improvement if nothing ever really changes? Don't let that be your team.
7. Facilitation Over Participation
If you are a Scrum Master or an Agile Coach, your role during the retrospective will be very different from your colleagues'. Your job is to design the process and to guide the discussion, but in general, not to participate. Broadly speaking, that means no idea generation and no influencing.
Notice that the rule here is "facilitation over participation". Like the agile manifesto, which states "while there is value in the items on the right, we value the items on the left more", it's important to realize that sometimes there is value in participating. The key is understanding that we value facilitation more than we value participation.
8. Read And Internalize The Advice of Experts
There's a lot of great literature out there about running retrospectives. Here's just a sample of books you should be reading to become an expert:
- Getting Value out of Agile Retrospectives - A Toolbox of Retrospective Exercises, by Luis Goncalves and Ben Linders
- Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen
- Project Retrospectives: A Handbook for Team Reviews, by Norman Kerth
Don't reinvent the wheel -- start with these resources and then master them.
9. Don't Forget The Positive
Because retrospectives focus on ways to improve, they tend to accentuate the negative and can leave a team feeling like it can't do anything right. But your team does a lot of things right! It's important to remember to emphasize the positive, in addition to looking for things to improve upon.
One way of doing that is running an Appreciations Retrospective.
10. You Can Run a Retrospective At Any Time
Because of the popularity of the scrum methodology, which rightly instruct teams to run retrospectives at the end of every sprint, there is a common misconception that retrospectives are derived from, and synonymous with, sprints. In fact, there are many types of retrospectives beyond the sprint retrospective. Project retrospectives. Personal retrospectives. Cross-team retrospectives. Release retrospectives.
Remember, the goal of a retrospective is to catalyze continuous improvement. So don't limit yourself to running them at the end of sprints. Run them whenever you feel the need to improve.
NEXT STEPS
What will you do to start improving your retrospectives? This list should get you started. Let us know what else you'll be doing in the comments! And if you're a distributed team, make sure to check out Retrium -- we're making distributed retrospectives easy and effective.