Extending the DDM modules in Liferay with custom field types isn’t that easy. This blog post is the result of our attempts...
10 tips for more effective retro actionsKoen Wellens
Think back to the last retrospective meeting you attended.
- Were people repeating the same things over and over again?
- Did you get the feeling you weren’t discussing the most important topics?
- Did you come out of your retro with more grudges and frustrations than when you went in?
If so, you’re not alone. A lot of teams struggle with retrospectives and even more with the actions that come out of them. Often, this is caused by ineffective retro actions that aren’t taken up by the team. Many of those action don’t tackle the root cause, but merely one of the consequences. How many of your retrospectives end up with actions like “We will hold a meeting with person X to investigate how we handle problem Y”? Actions like that are pretty common, and we’ve had our fair share of them as well. Through trial, error and experience, we have since then mastered the art of effective retrospective meetings. Sharing is caring, so we’ve thoughtfully compiled 10 tips for you to create more effective retro actions yourself.
1. Take matters into your own hands
The worst kind of retro actions are the one in which you decide on something for someone else. Imagine you’ve been out of the office for several days and instead of starting work on the topics you left behind, you’re tasked with something completely different. All because your team members decided to assign a retro action to you without you knowing. And it could be even worse: imagine you’re sitting at work and some other team that you’re not even part of starts giving you actions. Come on!
You probably want to avoid a situation like that. Most people hate to be told what to do, without having any say in it. Especially since most of the times, the team in question is perfectly capable of handling these kind of actions! So, when you notice a discussion during a retrospective is spiralling towards an action for someone who’s not there or not even part of your team, stop right there! Take matters into your own hands. If for any reason you cannot do that, investigate why. It might be a good idea to act on that issue first.
2. Make your actions S.M.A.R.T.
When you define your retro actions, how do they look? Let’s do improvement X? How are you sure that you’re actually going to do that? When is improvement X enough? The solution to this is to make your actions S.M.A.R.T.:
That way, you can evaluate whether your action has been done. Also, by assigning it to a member of the team, someone is responsible for making sure the action gets done!
3. The quick action review
Let’s assume your retrospective goes something like this:
- You generate issues on post-its and put them on the wall,
- group the post-its together into groups and prioritize them,
- discuss the highest priorities in order to create actions,
- finally finish the retrospective and clean the wall.
Ever have the feeling that your actions aren’t in line with the priorities you gave the issues? A problem might have the highest priority, but because it was so hard to solve you might have settled on one simple action. Another problem might have multiple actions to solve it, albeit not so important to the team as the first problem you’ve discussed. You quickly lose sight of this when discussing.
After you generate actions, you can hold a quick action review. Are your actions really a step towards a solution for the problem you are facing? And are your priorities straight? In the end, that’s all that matters. If you’re working on your biggest problems, you’ll most likely make the biggest improvements.
4. Only act on what you control
Uncontrollable things are frustrating, but they are a part of life and work in general. They can be reflected on in a retrospective, so that the team knows about them. Yet sometimes we walk into the action trap. That’s when we create an action for something that the team has no control over. For instance, if buses are always late after work, does it make sense for the team to have an action let’s improve the bus schedule after work? Of course not, so why try to do something similar while creating retro actions? Remember tip 2: make your actions S.M.A.R.T. and only act on the those you have control over.
5. Talk about what you can’t control
Only acting on what you can control doesn’t mean that issues outside your span of control aren’t going to be resolved, ever. The retrospective is a tool for teams to improve. If some external factor blocks, frustrates or irritates a team, it’s time for the team to stand up. Instead of changing what you can’t change, make sure your voices are heard. Make it clear and transparent that the entire team is blocked, frustrated or irritated by something you can’t control.
6. Link actions to the problems they solve
Unless you’re constantly aware and up-to-date about the retro actions done in the previous retrospective, it makes sense to go over them at the beginning of the current team meeting. At ACA, we do this too most of the time to ensure that we actually take action. But what do you do after you’ve completed an action? Do you just say “check” and go on? Do you even remember what problem the action was going to solve? Because if you can’t, then does it matter that the action is done or not? Maybe you discussed a problem that has been fixed by another cause. Consider it a lucky side-effect.
Most likely, a team will no longer remember what problems their actions were trying to solve by the next retrospective. This knowledge is implicit: everyone assumes that by reviewing the action, they’ll remember the entire issue gathering and follow-up discussion. But you know what assuming does to you and me. Make this explicit. Link actions to the problems they solve. It will be easier to measure whether it was a success or not and whether the team should continue or not. Plus it requires less brain activity about a previous retrospective, giving the team all their brain capacity to use in the one you’re currently doing.
7. Address disagreements during the retrospective
Your team is discussing a topic in your retrospective, but you don’t like the direction the discussion is going in. The generated actions are tasks you do not support. When do you say this: during the retrospective or afterwards?
Our experience tells that people often come back to actions after the retrospective, stating that they didn’t agree to that action. These are the discussions you want in the retrospective, not after. After a retro, the entire team should already have agreed on the actions. You can disagree with a solution, but still give it a try. Maybe it will amaze you. But just discussing actions over and over again will not take you further, it’ll only frustrate you more.
8. Visualize your actions
Tip number 3 already stated that it’s common to review the previous retro actions during your meeting. You might do that to ensure that someone actually completes the actions. But why is that? Are you tackling the cause of this problem by reviewing it? Think about it this way: if you have a retrospective on Friday afternoon, will you remember all the actions by Monday? If you’re working on a complex issue and you go back to that after your retrospective, is it easy to switch context for the retro actions?
If the answer is yes, that’s great! But from our experience, we’ve learned the answer is most likely no. You can proactively put the focus on retro actions by making them more visual. Put retro actions on your whiteboard in fancy colours so that they are always in your sight when you look at your board. When a team comes back on Monday, they can see the retro actions immediately, which helps to remember exactly what needs to be done. The team members that work on very complex issues can finish those and work on retro actions after they’ve completed their other tasks.
9. Share your action outcomes
When going over your retro actions, don’t just mention that something is done. Explain the outcome of the action so that the team can evaluate it properly. You don’t need to wait with sharing the outcomes until the next retrospective. If you’ve done something to improve your team, let them know, preferably by the next stand-up meeting at the latest. This way, team members that might miss the next retrospective (due to sickness, holidays or things like that) stay informed!
10. Evaluate action outcomes
Going over previous retro actions freshens up the memory and stops you from repeating yourself retro after retro. If an action isn’t finished yet and the team wants to continue it, great. It might not be necessary to put up the issues again until there is an outcome of the actions. A side-effect is that you can follow up on the actions, and have a quick recap on what the outcomes were. If more or different actions are necessary, take this as input for the retrospective.
BONUS TIP: Hold focused/themed retrospectives
Sometimes you might get the feeling that you’re not producing S.M.A.R.T. actions anymore. Often, this is because there are a lot of issues on the board for which the team can’t generate suitable actions. You might encounter items on the board which are too widespread. If that is the case, it’s very difficult to create effective actions that the entire team supports.
When struggling to come up with actions, hold focused themed retrospectives. For example, focus on code quality. This gives you issues and actions only related to that topic. That way, you can keep focus and stay on topic.
During retrospectives, teams can have trouble creating good, well supported actions, but these 11 tips should help. If you recognize your team in some of those, don’t try them all at once. Try the tips one at a time, so they don’t overwhelm you or your team.