Retros are a popular practice in software engineering. By doing retrospectives teams hope to increase their effectiveness and motivation, but sometimes they fail. In this story, I describe 7 popular retrospective mistakes and suggest some ideas on how to get rid of them.
This article first was published on Szymon Skórczyński’s Medium
1. Skipping retrospectives
One of the biggest sins in running retrospectives is not running them at all. Well-organized and conducted retrospectives bring a bunch of advantages to every development team. First, you as a Team Leader or a Scrum Master can show that you care. You care about the work standards, team members’ mood and motivation, product owners’ satisfaction and the quality of the final result. If you are a Team Leader and you care about your team, then with this one meeting you can build up the leadership driven by example – your example – and spread the solicitude among your teammates.
A retrospective meeting is also a great place to build the team spirit. There aren’t many better ways to solidify the team than working together to solve your everyday issues, especially when you benefit from someone’s hard work or you help someone in your team.
A well-conducted retro can help you improve your team’s workflow, increase your effectiveness and help you build better software. Retrospectives need to be treated as a mean of sharpening the saw – a very meaningful habit in good software craftsmanship.
A good retro is a perfect place for you, a Team Leader, to get to know your team members better — learn what’s important to them, what motivates them, what they like and what makes them sick. This is also a perfect place to get feedback on your leader’s work.
Karol Sójko, the author of “To-Do: Team!” – a great handbook for team leaders aspiring to build effective software development teams – warns that the natural consequence of teams skipping retrospectives is “the blame game”:
It’s a game that takes place after a feature was implemented late, you’ve missed a sprint deadline, and/or something didn’t turn out as expected.
What happens is that managers, leaders, or owners accuse the developers of not being able to deliver, and developers accuse them of not specifying their requirements clearly, making constant changes, and not being consistent in their demands.
There are two kinds of teams. Those who do retrospective meetings and those who don’t have the time to reflect on their actions. If you’re in the latter kind of team, then the blame game is your natural environment.
Retrospectives can protect your team from the need to play the blame game.
All in all, retros can significantly contribute to the success of your final product – good, reliable software.
Are you convinced? Well, here’s what you should do: if you follow Scrum or Scrum-ish methodology, you should do a retro at the end of each sprint. It’s a very good idea to do it right after the demo. It’s a great chance to review the sprint, discuss the sprint’s result and, well, if you’re doing good, celebrate the sprint! Don’t hesitate to have fun during the retro.
If you don’t follow Scrum, do your best to plan a retro in your team’s calendar. A milestone deadline or the end of the month are good occasions. But remember to do it often enough. I would recommend running retros no less frequently than once a month. With longer time spans you won’t be able to continuously improve and get decent feedback on the whole time span (and this is because our brains work selectively, more about it the 3rd sin).
2. Not enough time
I’ve met a couple of teams who did retros, but only because they wanted to be strict with Scrum. Actually, they didn’t feel any real value in them and treated them as a chore. They did everything to have them done as fast as possible — 5 minutes, we’re finished, retro checked – finally, we can grab a coffee/play a game/return to coding/go home.
Even though you run retrospectives, they won’t be effective if you don’t plan and spend enough time. It doesn’t mean they should last long hours. It means that everybody in the team should have a decent time to speak their mind and understand their teammates’ opinions. It’s your role, as a retro host, to give everybody enough time, but also to cut off discussions when they are veering off track.
I guess there shouldn’t be any general rules of how long the retro should take. It depends on the team and how you do Scrum. In my team of 6 people and two-week-long sprints, we usually fit within an hour.
3. Selective memory
Since the very beginning of my professional career, I’ve been witnessing an interesting behavior: people are usually raising issues related to events happening recently. And if somebody mentions a past event it’s very likely it has a negative tone. People pay more attention to recent and more emotional events (in psychology this phenomenon is called the availability heuristic) and when it comes to the emotions, for our brains bad is stronger than good.
How to trick your brain to have the best sight of the time span we move back to during the retro? The trick that works best for me is pretty obvious: I write down in my notebook all emotional (both positive and negative) situations that happen during the sprint. Then, at the beginning of a retro, when we think about things we liked and disliked in the sprint (more about it in the next sin), I just go through the list and pick up these events which are for me still emotional and important.
If you (and/or your team) find it difficult to build this kind of habit, then the history line may be something interesting for you. Start your retrospective meeting from drawing a horizontal line on the board. Next, ask your team members to freely stick notes with names of events that occurred during the sprint in the chronological order (the oldest events on the left, the most recent on the right) on it. Encourage them to write down only dry facts without any emotional tone.
The history line
The cooperative work with the timeline can help all retro attendees in recalling facts and events some of them have forgotten. It’s also a good start to the next part, when you bring up your emotional memories from the sprint. Be aware that working on the timeline can be time-consuming, so you might limit the time to ca. 10 minutes.
4. “Shiny Happy People Retro”
Do you recognize this kind of retrospective when a Team Leader or a Scrum Master asks at the beginning: “Does anyone have anything to say?”. No? Well, lucky you. Usually, this kind of question doesn’t bring anything good. People are afraid to speak up, especially when it means criticizing. You end up with a room of team members smiling and saying without any certainty that everything goes well. Karol Sójko names this kind of a retrospective as “Shiny Happy People Retro”. He warns, that this kind of meetings lower the engagement of the team in the process of team building and can also give a false sense that there’s nothing to improve.
One of the ideas to avoid this kind of retro is to ask the same specific question to each retrospective attendee one by one: e.g. “what did you like (or dislike) in the last sprint?”. To engage everybody in the meeting the whole time, it might be a good idea to limit the number of issues raised by a person at the time to one. Then we move on to the next attendee to raise their issue, continuing this round robin rule.
To keep the good flow of the meeting, give retro attendees a decent time to think about their opinion, engage everybody to think on their own (rather than only copy their mates’ views) and have a good reference. I prefer to write down all issues on sticky notes.
At the beginning of each retro, I hand out sticky notes to all retro attendees. Then we have some time to think about what we liked and didn’t like in the sprint — it’s usually ca. 8 minutes. I ask everyone to write their opinion on sticky notes (each opinion on a separate note). After the time is passed and everyone is done, we start the round robin issues rising part. Every attendee, one by one, raises one of their sticky notes and comments it. Other attendees with similar notes are asked to raise them. Everyone is encouraged to comment the issue. Once we’re done, I stick the note (or a group of notes) on the wall and we move to the next person. We finish when nobody has any sticky notes left.
5. Haters Gonna Hate
OK, you’ve learned that during the retro it is important that everyone can speak their mind freely, everyone’s voice is heard, every issue is important and should be well understood and taken into consideration. Haven’t you thought, at least once, that with these rules everyone will just complain? Well, there’s nothing strange if you have – this, is in fact, a reasonable concern.
I see a couple of reasons why people tend to focus on negative issues during retrospectives. First, as I mentioned in the 3rd sin, our brains “prefer” bad emotions. The Gotmann’s Magic Ratio states that bad events are on average five times as powerful as good ones (at least in close relationships). Second, if you work with people to whom the continuous improvement is the natural ecosystem, then it’s normal that they focus on things to improve — and a bad event is a much better base for improvement than a good one. Third, some of us are naturally born haters — “Haters Gonna Hate” isn’t just a meme.
The practice I follow during my retrospectives is that I always hand out the same number of green (for “I liked” issues) and red (for “I didn’t like” issues) cards to every retro attendee. It doesn’t mean that everybody needs to raise the same number of good and bad issues or that they cannot pick more cards of a given color if they want to. This is just an encouragement to balance the number of positive and negative comments, if it’s possible.
Another trick that can help (which, to be honest, I haven’t tested personally) is to run the Appreciative Retrospective. During this kind of retro, the attendees describe positive events, successes, good practices and the most valuable aspects of work.
6. No action items
In the first Scrum team I took part as a junior developer every retrospective looked the same. It looked the same to that extent that we weren’t only running the meeting the same way, but we were raising the same issues over and over. The retrospective meeting was a perfect place to give vent to frustrations at the end of the sprint, but nothing was really improving. After a couple of sprints, it turned out that the most frustrating frustration was that all of our frustrating issues weren’t really addressed. This was madness.
It took me a while to realize that it was because we didn’t prepare any action items after the meeting. We were just complaining about the stuff, but there was no time to talk how to improve them or find some volunteers to deal with the issues. I daresay, that in that situation it could have been less frustrating to skip those pointless retrospectives.
A list of well-addressed action items is the essential deliverable of every retrospective. You should spend a decent time to list them, prioritize, describe in a SMART way and select assignees. How does it work in my team? After a round robin issues raising part (described in the 4th sin) we go through all raised issues once again- starting with the most popular ones. Then we think what can be done to embrace the good items, improve the ones that aren’t good enough, and get rid of the bad ones. Each action item is written down in the retro meeting notes document (we use Confluence, but it could be anything actually: Evernote note, Google Docs document or Trello board). We pay attention to that every action item was SMART:
- Specific
- Measurable
- Achievable
- Relevant
- Time-boxed
We also add an assignee to every action item. Here are some real-life examples of the action items in our team:
– Add a separate column for code review on JIRA board - Mikael
– Arrange a meeting about the CI tool – Maciej
– Take a look at the “Ready for Test” column at the end of each daily – Szymon
The role of a Team Leader or a Scrum Master is to propose action items, but everyone should be able to give a proposition. Remember that it’s not a must to have an action item to every single issue. Try to focus on the most important issues and achievable action items. You may skip some issues if there are many of them or if it’s impossible to specify a SMART action items to them at the moment. It’s OK to skip some less urgent issues and see if they reappear on the next retrospectives (if they do, they should gain priority).
7. No action with action items
You did your best, you made a list of good action items, everyone agreed, you’re all happy you’re going to improve and then… well, it was the last time you saw the list. Event the best action items won’t help if you don’t treat them seriously. You need to move your action items to real action and review the progress regularly.
The retro action items I usually meet can be divided into two groups:
- One-time action — “do something once”, e.g.: “automate moving user stories to the Ready for Test column”
- Continuous action — “do something a couple of times, regularly”, e.g.: “do not be late for dailies in the next sprint”
I strongly recommend to put one-time actions into the backlog and treat them as regular tasks in the sprint. The good idea to keep up with the continuous progress is to put the most important action item on top of the backlog.
Continuous actions are more tricky. While you may want to split them into one-time action items (in the example above we could split the “do not be late for dailies in the next sprint” item to a list of separate “do not be late for the daily” items, one for each daily in the sprint), I’d prefer to keep them as they are, and treat them more like new values in the team. To help our brains remember about them, I suggest to write them down in a place visible to all team members, like your “war room”. They can be written on a whiteboard or a blackboard, a flip chart or a sheet of paper stuck to the wall. Just make sure everyone can see them and they don’t disappear at least during the sprint.
It’s vital to evaluate on a regular basis if you act right with your action items. My team has the habit to go through all previous action items at the end of each retro. During this run, we tick off all done items and discuss these which haven’t been done yet. We pay special attention to the items that haven’t been progressing for a longer time. If they aren’t valid or important anymore, then we simply cross them out. When it seems that we cannot do anything to fix them, then we try to rephrase them to change the assignee or the scope. If they are still valid, important and achievable, then we move them to the top of the backlog.
Wrap up
If you think that I have omitted some important sin or that one of these cardinal sins isn’t actually a big deal, then, well… it’s OK! Feel free to share your opinion in the comments.
The same goes for the suggestions for improvements. You may find that some of them can be valuable while other can be totally misguided. It really depends on your situation. If you find a particular idea interesting, give it a try and evaluate together with your team if it helps. If you’re looking for more quick ideas to improve your retro, I recommend taking a look at “Fifty Quick Ideas To Improve Your Retrospectives”.
I’m sure that this blog post doesn’t exhaust the topic. Running a good retrospective isn’t easy-peasy and there are plenty of good resources (both on the Internet as well as the bookshelves) that can guide you through this subject.