New ideas and tips to keep your scrum retrospectives fresh
A lot of developers in agile teams see retrospectives (”retros”) as a waste of time. In fairness, many retrospectives are a waste of time. That doesn’t mean they have to be. A good retrospective will reinvigorate a team, generate new ideas and excitement. Let’s look at some ideas for scrum retros and how to improve them.
Action points, or lack thereof, are the number one reason why developers perceive retros as a waste of time. Retrospectives can quickly become whine fests with everybody venting about the issues they’ve faced over the previous development cycle. And this is fine - as long as meaningful actions are extracted to solve these issues in the next cycle. So, how can we get to the stage where our retros are generating useful action points?
There are different flavours of retrospective, but they all follow a similar pattern. Each person notes down the items they wish to talk about that week, mixing in things that went well and not so well. What’s really important for this is to give people some time to fill these in by themselves - we usually set a timer for 3-5 minutes. It’s vital to do this: some people are quieter and more reflective and some people are loudmouths. If you allow people to start talking freely, only the loudmouths will be heard. Being a quieter, more reflective person is not a character flaw and it should not mean that they get to say less. You need to create space for their thoughts. After the timer is up go person by person through each item they wish to discuss. The person will read out their notes and a little explanation of why it’s been brought up this cycle. After each person has read out all of their notes, everyone is encouraged to share their thoughts. It might just be “I experienced that too”, but could also be “here’s how handled that”. Once everyone has gone, we then look for action points. Typically these are naturally generated by trying to prevent things that didn’t go well from happening again, but don’t neglect things that did in fact go well! It may be a team member has implemented a new documentation system they want everyone to adopt.
When producing action points to solve problems, don’t focus on the symptoms of problems. For example, there was a time when some tickets were staying in our project management system, Linear, for several cycles and not making progress. The easy way out would have had the action be “clear all the tickets” but that didn’t address why some of these tickets were staying in progress for weeks and weeks. On reflection, it was because those tickets were more like large-scale projects and a lot of work had been done on them but they weren’t yet approaching completion. So the real solution was to delete that ticket, make a project, and then break it down into smaller individual tickets which could be reasonably completed in a week or two.
Sometimes, action points can ruffle feathers. Be careful with how you decide what is an important action point. Very often democracy is used for this, which can work but it leads to the intractable problem of a happy majority, with a very unhappy minority. But those people are still part of the team. Consider trying to generate more consensus. For example, if someone in the team doesn’t like a new idea that the majority want to implement, try figuring out why they don’t like it. Maybe you can modify the implementation a little. Or maybe you can agree to implement it as a trail for one week and then give them a chance to review it and reject it more promptly later on. Stick to these promises or trust in the process is immediately broken.
Now you have your action points, write them down somewhere permanent. If it’s not written down, it won’t get done. We keep ours in the development cycle description in Linear to make sure everyone can see them with minimal effort. These are then linked to tickets if the task is specific enough, for example, “move passwords from nordpass to lastpass”. This makes it easier to review the previous cycle’s tickets to ensure progress is being made. Each action point should be assigned to an individual person and a due date added - most of the time it is by the next retro.
Do try and focus on things that the team can actually change. It’s okay to vent a little about things beyond your control. We will almost certainly vent about something to do with AWS and how it wasted our time that cycle every single retro. But keep this limited, instead focus on things that can actually be changed. In this case, it might be raising awareness and advocating for the need to dedicate some time in the week to improving the cloud deployment scripts.
Remember that action points are work. This means that if you fill everyone’s cycle with the normal amount of tickets, and then expect the action points to be done on top of that - they won’t get done! It’s important to realise that in order to actually do the action points it takes at least some time.
At Naurt we had an experience recently which really prompted this article. When we first started retros, they were really productive and we were generating a lot of action points. Each week, everyone had something to bring and we piece by piece implemented changes and tried to hone the working practices of the team. After a while though, the retros just became quite stale. We went from having 4-6 action points to having none.
What happened there? My suspicion was that the format became stale. We had been using a “what went well - what went wrong - what we learned” format for the retros. I brought up in the retro that I wasn’t finding the retros useful anymore and a few proposals were brought forward. One suggestion was to stop doing them. Certainly an interesting one. I wanted to try a new format. We agreed to give it a go next week.
The new format was very successful. Suddenly again we had loads of action points. The new format is an energy retro - we ask everyone what their currently energy level is. They can reply pretty much however they want. Sometimes people use a percentage (e.g. 30% - I’m low energy!) or sometimes people just use a low-mid-high. We then go through what things energised the person, what things drained them, and what things could recharge them next week. The same ideas apply - we then take the “what drained me” and “what could recharge me” columns and turn them into action points.
Astute observers might notice that “what went well” maps to “what energised me”, “what went wrong” maps to “what drained me” and “what we learned” kind of maps to “what could recharge me”. Even though these formats are very similar they come with a small change in perspective. In the original retro format we were asking team members to look externally at the project and the company as a whole. In the energy retro we’re asking them to look internally at themselves and their own experiences. A lot of retro formats essentially orbit around this format of “well-poorly-better”. Small changes can still be enough too.
What happened after a few retros with the new format? It started to get a little stale. We aren’t generating as many action points any more - maybe only 1-2. The solution like last time for me is to bring up a new format for the retro - this time we’re going to try the lean coffee retro for a few weeks. I imagine this pattern could be pretty regular. Introduce a new retro format with a new focus, which generates new ideas. After a while it gets stale. As lean coffee inevitably becomes stale, I’m thinking of going back to the WWL retro. After a few months of not using it, it might generate new ideas again. If not, I’ll move onto other styles of retro.
At Naurt, we do our retros in Notion. This lets the whole team access the retro wherever they are and look back at the previous one each cycle. You could use anything - I know Miro is also really popular. If the whole team is in a room you could just use a white board or post it notes. I would suggest if you do that, take a photo or write down the contents of the board at the end. It can be useful to compare week on week.
Sign up at Naurt for product updates, and stay in the loop!
