The retrospective is a time when the team looks back at a piece of work, reflects on what has gone well, solves problems and becomes happier. Well, that’s the story we tell ourselves. The reality is that retrospectives can often be tedious, ineffective and confusing. Many I’ve been part of seem to have become a box ticking exercise rather than a key problem solving activity. I’ve seen teams rush through them, forget them, or even disregard them. Maybe this is something you recognise, too.
When done well, though, retros are possibly the most powerful tool in the agile toolkit. It can be used to change direction to focus on more valuable activities. It’s the time when we come together to solve real problems, learn and grow. Not only so we can go faster, but to shift energy towards doing the right thing. To where effort matters.
The question “should we?” is now more on top of technologists’ minds than “can we?” or “how fast can we go?”. With ethical failures of fast-moving technology companies such as Facebook, Uber and Amazon, the conversation needs to shift away from speed and towards empathy. Real empathy. This requires us to stop, breathe and think rather than rush through and ticking boxes. Without getting stuck in the swamp of analysis paralysis, we need to use critical thinking at the right time with the right focus. That kind of thinking is, in my view, what is missing from the retrospective.
Here are three things that are broken, and what you can do about it.
1. Information smoothie isn’t as good as it sounds.
Imagine this: The white board is full of post-its after a retro brainstorm. The team is overloaded with information. The facilitator tries to make sense of it in 30 seconds or less. The team votes and they move on. Information gets lost or misunderstood. How do we handle all that complexity to not get overwhelmed and focus on the wrong problems? This is the "Information Smoothie" effect.
To make an Information Smoothie, take symptoms, problems, solutions, causes and effects, chuck them into a big smoothie machine and hit the mix button. What comes out of this is a big mess full of assumptions and risk. This makes it difficult to solve problems effectively. The worst part with the Information Smoothie is that it often leads to the team spending energy on actions which will have no effect on the problem, or even worsen the situation. What we want is “Information Salad”.
Let me use an example.
My fiancé and I recently moved house. The floor got very dirty (problem). I know it was from the movers when they walked in with shoes on (cause). This is where we need to put our efforts if we are going to make the problem go away for good. We can do that in different ways: Either make the movers take their shoes off, cover the floor in plastic, leave it as it is or stop anyone from coming in. The point is that if we clean the floors (solutions) without addressing the cause (movers walking in with shoes), we will have to keep cleaning the floors until the movers are done. The same principle applies to software. A team should spend their time doing valuable things and not conceptually ‘clean the floors’ for ever and ever. In retros, separate causes from symptoms.
Let the team know what useful information looks like. “What is wrong with what” or for example “There is not enough X when we do Y and that makes Z more slow”. Have the prompts prepared beforehand and visible during the session.
It’s that simple. If you can give your team more physical space to share information they will. Small post-its are great for simplifying ideas, bigger post-its gives room for valuable detail to use in root cause analysis.
I often hold on to old post-its for too long. If it’s important it will come up again, people tell me. This is true only if people notice a problem and care to bring it up again. And this principle only works with problems happening regularly enough for you to remember them. A simple spreadsheet can go a long way to keep track of and make patterns of your retros.
2. When forced to dot-vote for more information.
Making decisions as a group is challenging and time consuming. Dot-voting is a way to quickly prioritise and agree on what to focus on as a group. When done well it triggers collaboration and conversation. When done badly it encourages social biases such as the bandwagon effect or strategic voting which leads to focusing on the wrong thing or making the situation worse.
I was once on a team which had gone through huge challenges as well as successes. When we dot-voted for what subject to talk about in a retro, the team had chosen to ignore the biggest problem, even though it was critical and had been prevalent for a long time. We discussed something else. Perhaps we were just tired. Perhaps we thought it was normal now. I don’t know but our problem was still a problem.
When humans need to make a decision in a short amount of time, we take shortcuts. Shortcuts like preferring things we know, or following someone who seems to know what they're doing. Or we take shortcuts like dot-voting to prioritise issues. Like any social bias this blinds our view and hinders our decision making. Like in other democratic processes: If you want to make good decisions as a group you have to have well informed individuals. We can never know everything, but we can surely try to get all we can from the group. To set your team up for successful decision making you need to ask “so what?” and also try other ways of prioritising topics other than dot-voting.
The "so what" question helped my team make the right decision before. We thought that by removing a certain time consuming and painful step in the process would make us go faster. By digging deeper by using the "so what" question we realised that by removing this step we would lose a valuable side-effect: team transparency and understanding. It might seem obvious but without asking this simple question we might have just changed our process for the worse.
If you still need to use the voting mechanism, try to reduce the likelihood of biases. Simple things you can do is to hide votes until the very last minute. Each team member can vote by themselves and then share it with the rest of the group. There is an excellent tool called Dotmocracy which physically hides votes.
Another thing you could try is to use categories of votes to give the votes more richness. In one example, I used the the categories of "Essential", "Nice to Have" and "Need more information". This can spark more interesting conversations around understanding the problems rather than rushing to solutions.
Which brings me to the last and most important point.
3. Fast marathon! Wrong race.
In the tech industry, action is the key to success. A great idea kept to yourself is not as valuable as a half bad idea tested in the real world. However, only focusing on actions often leads to unintended results. In the best case scenario we get innovation and human progress. In the worst case scenario, and quite commonly in the last few years, we get serious implications to human health, safety or democracy. There is research showing that an individual might take a non-proven treatment over doing nothing - even if there is no proof the treatment will have any effect. The danger with action bias is that it temporarily suspends critical thinking, which blinds us to the bigger picture. The "Marshmallow Experiment" shows kids taking the marshmallow in front of them (instant gratification), when they could have had two, had they only waited. How often do you go for the instant marshmallow?
Facebook’s motto “Move fast and break things” or Amazon’s leadership principle #8 “Be biased towards action”, are examples of the action bias in these companies’ cultures. The problems these two companies have caused (unethical use of data, multiple privacy breaches and unfair workers rights) are examples of what an overactive action bias can lead to.
However, action bias can also help us. If you want to be more healthy you simply have to get your shoes on and go for that 15 minute run everyday. No analysis required.
If you want to get to a certain destination, you also need to run on the correct path. The retro is where a team can find that path.
Ask the question “What is the worst thing that can happen if we don’t act now?". If the answer is "something serious" then we need to action it. Hans Rosling, the co-author of Factfulness and professor of health at WHO says: “If you are called to action - the more useful action you can take is to improve on the data”.
To be good at positive innovation for the betterment of humanity, we need to be great at learning and be brave enough to slow down. Retrospectives should be the space where positive innovation starts.
When done well, though, retros are possibly the most powerful tool in the agile toolkit. It can be used to change direction to focus on more valuable activities. It’s the time when we come together to solve real problems, learn and grow. Not only so we can go faster, but to shift energy towards doing the right thing. To where effort matters.
The question “should we?” is now more on top of technologists’ minds than “can we?” or “how fast can we go?”. With ethical failures of fast-moving technology companies such as Facebook, Uber and Amazon, the conversation needs to shift away from speed and towards empathy. Real empathy. This requires us to stop, breathe and think rather than rush through and ticking boxes. Without getting stuck in the swamp of analysis paralysis, we need to use critical thinking at the right time with the right focus. That kind of thinking is, in my view, what is missing from the retrospective.
Here are three things that are broken, and what you can do about it.
1. Information smoothie isn’t as good as it sounds.
To make an Information Smoothie, take symptoms, problems, solutions, causes and effects, chuck them into a big smoothie machine and hit the mix button. What comes out of this is a big mess full of assumptions and risk. This makes it difficult to solve problems effectively. The worst part with the Information Smoothie is that it often leads to the team spending energy on actions which will have no effect on the problem, or even worsen the situation. What we want is “Information Salad”.
Let me use an example.
My fiancé and I recently moved house. The floor got very dirty (problem). I know it was from the movers when they walked in with shoes on (cause). This is where we need to put our efforts if we are going to make the problem go away for good. We can do that in different ways: Either make the movers take their shoes off, cover the floor in plastic, leave it as it is or stop anyone from coming in. The point is that if we clean the floors (solutions) without addressing the cause (movers walking in with shoes), we will have to keep cleaning the floors until the movers are done. The same principle applies to software. A team should spend their time doing valuable things and not conceptually ‘clean the floors’ for ever and ever. In retros, separate causes from symptoms.
What to do instead
Try to create the best environment for an Information Salad. As a facilitator you can help your team to make causes more visible, which can help with more in depth root cause analysis. Remember, problem solving in an instant is easy. Effective problem solving in an instant is close to impossible. However here are some basic practical tips to get you started. The principle is: make it easy for your team to share meaningful information.
Use prompts
Let the team know what useful information looks like. “What is wrong with what” or for example “There is not enough X when we do Y and that makes Z more slow”. Have the prompts prepared beforehand and visible during the session.
Use larger post-its
It’s that simple. If you can give your team more physical space to share information they will. Small post-its are great for simplifying ideas, bigger post-its gives room for valuable detail to use in root cause analysis.
Save the old
I often hold on to old post-its for too long. If it’s important it will come up again, people tell me. This is true only if people notice a problem and care to bring it up again. And this principle only works with problems happening regularly enough for you to remember them. A simple spreadsheet can go a long way to keep track of and make patterns of your retros.2. When forced to dot-vote for more information.
I was once on a team which had gone through huge challenges as well as successes. When we dot-voted for what subject to talk about in a retro, the team had chosen to ignore the biggest problem, even though it was critical and had been prevalent for a long time. We discussed something else. Perhaps we were just tired. Perhaps we thought it was normal now. I don’t know but our problem was still a problem.
When humans need to make a decision in a short amount of time, we take shortcuts. Shortcuts like preferring things we know, or following someone who seems to know what they're doing. Or we take shortcuts like dot-voting to prioritise issues. Like any social bias this blinds our view and hinders our decision making. Like in other democratic processes: If you want to make good decisions as a group you have to have well informed individuals. We can never know everything, but we can surely try to get all we can from the group. To set your team up for successful decision making you need to ask “so what?” and also try other ways of prioritising topics other than dot-voting.
What to do instead
The principle is: Help the group make better decisions by enhancing the collective knowledge of the group, avoid the social biases.Ask "so what?"
It might sound simple, this question can quickly help surface the effects of an issue. The team can make a more informed judgement on how important the issue is if the information is clear. When the effect isn’t clear, the issue can either be ignored by the team or exacerbated by well-meaning solutions.The "so what" question helped my team make the right decision before. We thought that by removing a certain time consuming and painful step in the process would make us go faster. By digging deeper by using the "so what" question we realised that by removing this step we would lose a valuable side-effect: team transparency and understanding. It might seem obvious but without asking this simple question we might have just changed our process for the worse.
Use other types of voting mechanisms
If you still need to use the voting mechanism, try to reduce the likelihood of biases. Simple things you can do is to hide votes until the very last minute. Each team member can vote by themselves and then share it with the rest of the group. There is an excellent tool called Dotmocracy which physically hides votes.Another thing you could try is to use categories of votes to give the votes more richness. In one example, I used the the categories of "Essential", "Nice to Have" and "Need more information". This can spark more interesting conversations around understanding the problems rather than rushing to solutions.
Which brings me to the last and most important point.
3. Fast marathon! Wrong race.
Facebook’s motto “Move fast and break things” or Amazon’s leadership principle #8 “Be biased towards action”, are examples of the action bias in these companies’ cultures. The problems these two companies have caused (unethical use of data, multiple privacy breaches and unfair workers rights) are examples of what an overactive action bias can lead to.
However, action bias can also help us. If you want to be more healthy you simply have to get your shoes on and go for that 15 minute run everyday. No analysis required.
If you want to get to a certain destination, you also need to run on the correct path. The retro is where a team can find that path.
What to do instead
Be aware of the action bias and do your best to fight it. We can never be rid of all bias because we’re human. What we can do as facilitators is help teams minimise the negative fallout of psychological shortcuts.
Be brave enough to not take action.
Ask the question “What is the worst thing that can happen if we don’t act now?". If the answer is "something serious" then we need to action it. Hans Rosling, the co-author of Factfulness and professor of health at WHO says: “If you are called to action - the more useful action you can take is to improve on the data”.In summary
To be good at innovation, be it good or evil, intentional or accidental, we need to be better at ideas and faster to deliver. But it only gets us so far.To be good at positive innovation for the betterment of humanity, we need to be great at learning and be brave enough to slow down. Retrospectives should be the space where positive innovation starts.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
