3 Reasons Why Retrospectives Suck - Part 2 – Dot Voting
To clarify my stand point – I love Retrospectives. Learning from mistakes and getting better is essential in design and in software development, or in anything in life really. I also love teams. So much that I want to help teams to be better at getting better.
Having two thoughts in mind at the same time is hard, but it’s possible. To use the famous Hans Roslings words:
“Remember: things can be bad, and getting better.”
Just like things can be good and still need improvement.
Part 2: The problem with dot Voting
Where the first part of this article series focused on the problem of Retrospectives being too narrow focused, this part continues to probably the most important reason why retrospectives need some more work.
Pre-rant: Dot voting used in the right way can be very useful. It can harness the combined intelligence and decision making ability of a group which is hard to do as an individual. A complex decision can also be made within a short amount of time. Voting, just like democracy, requires good information and awareness of our own biases – and this is where I think we can improve.
Ignoring the difficult
We were way over the honeymoon phase. The initial excitement of starting a project had turned into a multitude of issues and successes for the team. It was retro time. There was a jumble on post-its in multiple different colours on the wall and the team had just finished brain storming. Let’s dot vote! The team members came up one by one and voted on the items they preferred talking about by putting a dot on the post-it and they sit back down again. One of the main issues we had been struggling with for a long time was again mentioned, but with a smiley face next to it. It had got no votes this time. Our main problem had just become just part of the normal.
The team had ignored one of the big hairy problems holding the team back. No-one had voted for it and no-one wanted to be the one who brings up old smelly problems.
This is just one example of a problem I’ve seen in the last 5 years I’ve been exposed to dot voting and democratic decision making. Teams unwillingly or willingly ignoring the areas which might cause the biggest pain, but also might grant them the biggest relief. Like eating your vegetables. With just a bit of butter – even broccoli can be fantastic.
I’ll get to the butter further along in this article.
The problem I think with dot voting is two fold.
Problem one: We don’t make it easy to vote
To be able to make a good decision we need good information. The information very commonly voted on in retrospective is often unstructured or incomplete or both. The information is often dense and hard to understand, often because post-its are very small and it prevents people from writing longer explanations (which is actually a good thing most of the time). Problems and solutions are mixed together, the information is at different levels of detail, and very often because of this there is no shared understanding or clarity of why certain things are happening or the effects of an issue. Having chaos of information makes it harder to objectively judge the relative importance of issues. This then makes it easier to fall into subjective opinion and social biases. I put my vote on the item other more stronger individuals on the team vote for, for example.
To clarify…
Me and my partner just moved to a new house and as expected we were faced wih a multitude of challenges. The simple goal with our move is to have our home set up within a reasonable time frame so we can start living in it. Using examples from this I might be able to illustrate the information problem I see.
Let’s start with one simple example.
This is a pretty simple example. There is a desired state – a problem – causes and a solution.
Not much discussion to be had. How we clean the floors can be done in different ways which we could brainstorm then vote on to make a decision – we just know that we need to clean the floors. We might get a cleaner in, we might clean it ourselves or maybe a friend or family member can come over. Anyway it’s pretty clear what we need to do.
The list below is more what a real list looks like at the moment for our move:
Now let’s vote for some of these to see which are the most important. Which ones would you vote for? You can only vote for 3.
Ok it’s hard. So I grouped the post-its in themes to make the decision easier. Now you have less options to choose from.
I would instinctively go for ‘Movers cancelling’, ‘no hot water’ and ‘it’s cold’ since it seems quite important. The I’m hungry problem is something we can solve a different way. For the “it’s cold” – maybe the heaters is broken, maybe it’s not running, maybe the door is open, maybe the person who wrote it is outside and it’s winter time in Melbourne. We don’t have the information we need to vote on anything until we ask why – at least once. To be able to make our new house a home we will need to do most of these things.
Some of these items are solutions and not problems. Some problems are related to each other and would be solved if you solved a different problem first. The groups are also a bit wonky, right? There’s so many questions. We don’t really know why any of these things are happening and we might not be able to do anything about it. Voting in this case could work, but it’s only because we know roughly what moving house means and the importance of the different things. If you’ve had previous experience with moving.
In software it’s often much more ambiguous. The effects might be causing the team pain, but be foundational for great customer experience. Shouldn’t we be solving for the customers pain, over the teams pain?
Making good use of dot voting
The purpose of dot voting is to make a decision as a group. It’s a way to decide on the order of importance of a topic or an issue. However when a group doesn’t have enough information it seems like it becomes more about opinion than objectivity. Before any decisions are made we need to instead draw out the details so we can avoid assumptions and subjectivity. As in the example of ‘clean the floors’, the solution can be reached in the different ways. This is where the idea generation of the group becomes powerful. In the example of ‘It’s cold in doors’ we need to understand what is causing it to be cold before we do anything useful about it.
Let’s take the costly solutions as example since we don’t really want to spend more money than necessary. Before we go and spend more money on a washing machine we really need to understand the problem here.
The facilitator plays a key role in creating the right environment for clear information by asking the right questions:
[Me] We have to buy a new smaller sofa
[Anthony – facilitator] Thinking: Sounds like a costly solution – let’s dig further. Why do we need to buy a new sofa? Could you explain what will happen if we don’t.
[Me] Our current one is too big for the living room so we will have to sit really close to the tv which is not very nice, and it will be in the way.
[Anthony – faciliatator] Why doesn’t it fit?
[Me] The sofa is too wide. It will be to tight between kitchen bench and sofa to be able to walk pass. It’s an IKEA sofa so maybe we can just return it and get a new one?
Now we’re getting to interesting stuff. You can already start to see solutions come to mind by just reading these reasons and it doesn’t necessarily mean buying a new sofa.
The sofa is too wide
Possible solutions
- Can we break the sofa apart? Can we make the sofa smaller?
- Can we move one side over the other side? (Since it’s an IKEA sofa we probably could)
- Can we move it to a different part of the room?
- Can we angle it in a different way?
Me and my partner can possibly vote for one of these solutions (but we know I’ll just win anyway).
In software, the items written on post-its on the wall, are often much more complex and complicated than this. If we can make it easier for teams to start seeing the differences between solutions, causes and problems it would be easier for individuals to put their vote on something meaningful.
Recently I saw an example of when information wasn’t adequate. When a developer finished a piece of work, there was no-one available to brief them on the next piece of work to do. This resulted in delays and work being picked up in the wrong order.
The effect was ‘There is no one available for kickoffs’. The team instinctively knew this was happening because of a multitude of meetings going on which took away time from kicking off new work. After about 3 minutes the team agreed that the solution was to prevent having other meetings take precedence over kickoffs. The team agreed to book in Kick-off meetings.
Now I’m not saying that this is the wrong solution. However solving a problem of too many meetings with more meetings seems counter productive.
Problem solving or decision making?
A retro is fundamentally a collaborative problem solving session to create a shared understanding of issues facing the team to able to solve them. What retros very much is today is not that, they are decision making sessions, which requires a different set of tools than problem solving. Decision making is the process of weighing pros and cons against each other within a certain set of constraints. Basically choosing the right option. Do you want to go to Italy or to Wollongong?
Problem solving is more like drawing a map of unknown roads which leads to the places we want to get to. We have to walk around an area and learn what is there to successfully draw where the mountains, lakes and roads are. All the pieces need to come together to arrive at your location.
Retros should be information seeking missions
“When you are called to action – sometimes the more useful action you can take is to improve on the data.”
This quote is from the book Factfulness written by Hans Rosling, Ola Rosling and Anna Rosling Rönnlund.
Successful retros I think, need to first draw out data using the perspectives of the team members to get a clearer map of the information (problems, causes and effects). When everyone is on the same page, dot voting or other group decision making tools can be used to decide how to solve the problems.
Sina Stöhr and Christoph Dölitzsch are berlin-based Business & Service Designers and workshop facilitators and innovators and they have written a great article on how to get to better decisions as a group and they say:
“If you want to make good decision in groups you need a whole bunch of informed people.”
Reason Two: The humans
Imagine suggesting the the engineering team at Boeing to dot voting to prioritise issues with the Boeing 737 Max software update. The team would just look at you funny. Then why are software engineers and designers so comfortable with making decision a popularity sport?
When faced with large sets of data – for example multiple post-its on a wall and a decision has to be made, something happens. It feels uncomfortable – now what? We need to simplify to be able to make a decision. Usually teams use affinity mapping to group similar items together and then vote on the group of items. Common biases like familiarity bias (we have a preference for things which are familiar to us) and different social biases like conformity or authority nudges our vote. We take shortcuts to save energy, which might make us miss important information, or make us ignore the difficult items like in my first example.
What also is a reason for this is the different types of thinking: type 1 and type 2 thinking as written about by Daniel Kahneman in ‘Thinking fast and slow”. Type 1 is fast intuitive and unconscious. This is the type of thinking we use when we drive, talk or walk – and very open for biases. Type 2 thinking takes a bit longer and uses a bit more energy – but more often leads us to the right place. Dot voting encourages type 1 thinking.
Even if we believe we don’t have any biases (which is a bias), it’s risky basing importance on popularity. What might be painful for a team might not be a pain for the customer. If some part of the deployment pipe line is slow we can assume that’s bad since we are waiting, which is wasted time. But if some essential process is happening as part of that, although slow, making the experience ultimately better for the customer, isn’t that desirable?
If the team is going to be effective at solving problems – they need to encourage type 2 thinking. Which might take longer and feel harder, but I think with some small changes to the retro as a method and with awareness of these biases, it can start to feel easier.
How to not suck
- Clarify the desired state before talking about problems. What is the thing we want to see happen? “We have all of our things in our new house and we can live in there”. This could be defined together with the team as a seperate exercise or as a retro activity. An example of a simple problem solving approach can be found here where the first step is to define the desired state.
- For the facilitator: Help people write complete sentences on their post-it notes. Good tip to use the larger landscape shaped notes, which fits more information. Make it easy for people to imitate by preparing some examples before hand. Use prompts and examples to get to a problem: ‘What is wrong with what’, ‘lack of x which leads to y’ or ‘we didn’t have enough A so that lead us to doing too much of x’. Prompts like themes can also be helpful for example: team and collaboration, governance and decision making or customer involvement.
- For the facilitator: Before voting on anything, ask the question ‘so what’ for all items on the wall. Capture what people say to create that shared understanding of the effect of an item. Listen out for words like ‘because’ and ‘therefore’. They can sometimes lead you down interesting paths. This should help to make the relative importance between items a bit clearer.
- To limit the impact of social biases: Have people silent vote on a piece of paper or blinded hand raising. For a really cool solution – Use the Dot-mocracy voting frames. To avoid popular voting: Categorise votes. For example having votes for ‘need more information’, ‘follow later’ or ‘talk about now’ using different colours. More in details description of this method can be found in Stephen Andersons article: What’s wrong with dot voting.
