Defining & Creating Consensus with Teams

Lately, I have been reading The People’s Scrum by Tobias Mayer.  It is full of short essays on Scrum dating back to 2005.  Near the end of the book, I found a very interesting essay titled “Seeking Consent” that examined the impact of how decisions are made.  In the opening of this essay, Tobias described two common decision-making techniques – have the leader decide versus consensus.  What compelled me to write this entry was how Tobias pointed out that we commonly define consensus as complete agreement, but a more accurate definition of consensus is “no one is opposed”.

But what is consensus?  To me, consensus is the desired outcome of dialogue.  During dialogue, participants work together in conversation to create a shared understanding of an issue before them.  This type of dialogue can be challenging and time-consuming since it requires all participants (who want to participate in the dialogue) share what they know about the issue, their concerns, fears, wishes and hopes and be open to hear the same from the other participants.  To develop consensus requires patience, the ability to offer other participants the opportunity to share what is true for them and a willingness to have your ideas challenges.  At some level, consensus is normally facilitated either by an official facilitator or a participant acting within a facilitative mindset.

When the participants in a conversation decide to act as result of their dialogue, this is when consensus becomes important.  Actions that do not have the full support of all participants tend to be poorly implemented and are short-lived since not everyone was behind the decision to act in the first place.  And this is where we see many consensus tools come into play – Fist of Five, Roman Voting, Near-Unanimous Consensus and others.  In this essay, I want to share one of my favorite tools from the Core Protocols – Decider and Resolution.

At a high-level, Decider is a lot like Roman Voting, but with more structure.  The basic idea behind Decider is to give each Team member an explicit say on making decisions as a group and the means to hold one another accountable for the result (or action).  This protocol helps move the Team immediately and unanimously toward an outcome.  The steps of Decider are:

1. The proposer says, “I propose [a concise, actionable behavior].”
2. The proposer says, “1… 2… 3.”
3. A Team members vote simultaneously in one of three ways:
   • “Yes” by giving a thumbs-up,
   • “No” by giving a thumbs-down,
   • “Support it” by giving a thumbs-sideways.
4. The proposer tallies the votes.  A proposal succeeds when all the Team members vote “Yes” or “Support it”.
5. If not, the proposer uses Resolution to adjust the proposal so the outliers (“No” votes) can vote “Yes” or “Support it”.

If someone votes “No”, the proposer needs to determine if they are an “Absolute No”, i.e a veto, or if the person merely is “No”, i.e. they are movable.  If a person is an “Absolute No”, then the proposal dies immediately.  In the context of group decision-making, if someone is going to veto an idea and are unmovable, then there is no point in further discussing the action.  It is just a waste of people’s time.

However, there is an important check on the ability to veto. If someone on the Team vetoes an idea, they should be prepared to offer a better idea at once.  Only use an “Absolute No”, when you are convinced you have a significant contribution to make regarding the direction or leadership of the Team or when integrity requires you to act.

If a member of the Team is merely dissatisfied with a proposed action, then use Resolution to make the proposal better.  This is truly the essence behind Resolution – for a Team to work together to come up with the best ideas that have the support of everyone.  The steps of Resolution are:

1. The proposer asks each outlier, “What will it take to bring you in?”
2. Each outlier provides a short, declarative sentence precisely describing what is needed to gain their support.

The only people who speak during Resolution (and Decider) are the proposer and the people who voted “No” (or “Absolute No”).  This is to preserve the quickness of the decision-making process and not get bogged down in why the idea was good in the first place by the people who voted “Yes”.  Finally, the outliers are not allowed to discuss the reasons why they voted the way they did.  These concerns should have been identified during dialogue.  The outliers only discuss what the proposer needs to do in order for them to drop their resistance.

I find both of these techniques to be powerful tools to help Team members feel comfortable with group decision-making and ensure that only the best ideas are acted upon.  Not just the ideas that are popular or driven by forceful personalities.  At your next Retrospective, introduce these tools to your Teams and offer a proposal to begin using them in your next Sprint.