Five ways to build consensus
One of the things I struggled with at the start of my Scrum Master journey was building consensus in the team. Wanting to stay objective, give everyone space and time whilst still craving for a decision was a challenge for me. My own indecisiveness with regards to how to handle this ultimately did not serve the teams I worked with well as discussions did not seem to go anywhere and decision making was slow. Over time I learned that there are actually many already existing useful techniques that help with consensus building, and when and how to use them depends on the context and the situation you are in. Here are a few that have served me well as a facilitator.
1-2-4-All
The reason I really like using 1-2-4-All from Liberating Structures is that, as a facilitator, I can include everyone in generating ideas, regardless of how large the group is, whilst still giving people individual space. The diverging and converging aspect from 1-2-4-All lends itself well to avoid groupthink, which is something I try to avoid especially when it comes to building consensus.
In practice
- Ensure there is a shared understanding of the problem the group is trying to solve. Ideally frame the problem as a question. My personal favorite way to do this is using the ‘How Might We’ format.
- Round 1 - 1 minute
- Each person individually reflects on the question.
- Round 2 - 2 minutes
- People generate ideas in pairs, building on ideas from the first round.
- Round 3 - 4 minutes
- People share options and ideas gathered in round 2 and build on those in foursomes.
- Round 4 - 5 minutes
- Each group shares one important idea that stood out to them with all
Thirty-Five
I was introduced to the game of thirty five when I saw Dave Gray’s article on the Game Storming website. I like how quick it enables reaching consensus, even in larger groups. The game is designed in such a way that people cannot cheat the system and influence the outcome.
One example I have used thirty-five for is when Scrum Teams are looking to agree on which new ideas for their product to take forward.
In practice
- The team has a list of different ideas generated from a brainstorming session. Each idea is written on an individual card, so there are a bunch of cards to choose from.
- One by one, each person picks a card with the idea that they believe is best. If someone else has already picked what they believe is the best idea, then they can take what they think is the second best idea and so on. Once everyone has a card, the game can start.
- The group form pairs and decide between them, how they would divide 7 points between the 2 cards/ ideas they have. They add their scores to the back of each card.
- Pairs swap cards and partner up with someone else. This is repeated for 5 rounds in total, so that each person has worked with others to distribute 35 points across the items.
- At the end of the fifth round, add up all points at the back of each card.
- Sort the cards/ ideas with the highest score on top.
Buy a feature
Although primarily seen as a collaborative priortisation technique, buy a feature can also be used as an excellent way to reach consensus.
Buy a feature is an innovation game invented by Luke Hohmann where “players” - this can be team members, stakeholders, users and so on - are given play money and come together to “buy” the features they want. The clever part is that some of the items are priced so that no one person can buy a feature on their own, leading the group to have to negotiate with each other to agree on the features they want the most.
In practice
- Present a list of the potential options.
- Ensure each option has a price - this can be set based on estimated development costs, assumed customer value or anything else you want.
- Invite a group of 4 to 7 players. They can be your stakeholders, or actual potential users of your product. If you use it to buy improvement actions, then it would be the team members.
- Each of the players receives some play money, but not too much - options should be priced so highly so that no one player can buy them by themselves, and not all options can be paid for by the whole group.
- Observe your players as they negotiate and pool their money to buy the options available.
Dot Voting
Dot voting is one of the quickest ways to gain or evaluate team consensus.
Dot voting can be used when a team looks to choose a few options from a large pool.
An example of how I use dot voting as a facilitator is in the Sprint Retrospective when, as a team, we need consensus on which improvement action we will be working on next.
In practice
- Ensure that the list of retrospective actions is available and visible in one place. This can be on a wall, on a table, on a (virtual) board etc. Once there is a shared understanding of what the various options mean by everyone it is time to vote.
- Each team member is given the same number of dot votes. This might be 3 to 5, but the number of votes each team member has should be less than half the number of retrospective actions they will need to vote on.
- Each team member places their dots on the retrospective action(s) they feel will be most impactful. A team member can decide to place all their given dots on one single retrospective action if they feel very strongly about it, or distribute them across multiple actions.
- When everyone has placed their dots, voting is over and it is time to assess the results.
- The Scum Team agrees that the action(s) with the most votes will be the ones they will work on in the near future or even in the upcoming Sprint.
A nice twist on dot voting I was introduced to comes from Gerjon Zomer’s Lean Story Design. In this variation, people do not use dots, but instead each team member adds a sticky note onto their favorite option with a concise explanation for why it is their favorite.
Fist of Five
Fist of five helps me as a facilitator to gauge a range of agreement and still enables a collaborative decision. In contrast to dot voting, I use fist of five when building consensus is needed on making a single decision at a time, rather than deciding between multiple options.
One example of how I use fist of five as a facilitator is when we as a Scrum Team have an idea or proposal that we need to agree on. Shall we take it forward? Should we refine it? Or should we abandon the whole idea entirely?
In practice
- Ensure a shared understanding of the idea or proposal the team is voting on.
- Agree the degree of consensus required. How strong the consensus needs to be depends on the context. For example, if you are holding a vote on an idea that has a great impact on everyone in the Scrum Team, then it can be agreed that it will need everyone to hold up at least four fingers. However, in many other cases, a Scrum Team can agree that having a majority of at least three finger votes is good enough for a decision to have been made.
- Once the team has agreed on how strong the consensus should be, they can hold the vote. The team discusses the option and when ready, on a count of (usually) three, each member shows their vote (one to five fingers).
- Five fingers: Awesome idea! Let’s go for it!
- Four fingers: Good idea! It has my support.
- Three fingers: I am on the fence. I think it is neither good nor bad.
- Two fingers: I don’t like the idea, I would prefer that we look for other ideas.
- One finger: I cannot support this idea. Let’s look at alternatives.
- Check the results. If the team has reached consensus then only one round of fist of five voting is needed. If the team has not reached consensus then they can discuss and refine the idea and vote again.
Conclusion
As I discovered there are many ways to help teams reach consensus. It depends on the context as to which ones I choose to use. What other consensus building techniques have you used?