Is consensus required for a self-organising team to make a decision? How do we know that a decision is made?

When we as Agile Coaches and Scrum Masters servant lead teams and help them make decisions, do we need to seek consensus?

e.g. if we "take it to the team" and ask them something "do you want to do this or that" do we need to seek consensus or do we need to seek a majority vote?

How do we know the team has made a decision.

  • General consent and unanimity aren’t quite the same thing. Seek the former more than the latter. – Todd A. Jacobs Mar 14 '20 at 1:06

When “taking it to the team” should we seek consensus?

The simple answer is "yes". When people all agree on a decision or an action, they will stand behind that decision or will make efforts to realize that action.

The more detailed answer would be that it's not that simple. Sometimes people all agree on something, in which case you have the best outcome out of the bat. But sometimes, people disagree on things. Even when everyone is trying to do the right thing, they might have different opinions of what "right" is, or if they agree on what "right" means, they might disagree on "how" to make it happen.

When that happens, team members must discuss it. Similar to estimating at the Sprint Planning with Planning Poker, when people give vastly different estimates, they will then discuss until they reach an agreement and settle on an estimate value that everyone thinks is OK. You should encourage them to do the same when they don't have consensus. So a lot of it involves communication.

Of course, at some point, you will have the occasional situation in which not everyone will agree even though they talk it out. Voting would be a solution to avoid getting blocked in the discussion, but it's not always a successful approach. Even though it's a fair process, like in a democracy, it means the majority wins. Then that results in the minority losing. You then might not have the full support, from everyone, behind the decision or behind the action that needs to happen. And at this point, one of the Scrum values becomes paramount, that of "respect". Even if people disagree, they respect each other, and they respect each other's efforts, and want all to contribute to something good. So they will stand behind what the majority decided. If you lack respect, then you'll have much more work on you hands as a Scrum Master/Coach.

Other options, besides reaching consensus or voting, would be if the team lead makes the final decision, or the more experienced developer from the team, or the person with the most information about the subject, etc. It really depends on the team dynamics what other options are available.

So as a Scrum master/Coach, you should encourage, facilitate, and help the team have these discussions so that they can reach an agreement most of the times (practice makes perfect would be a cliché way of putting it).

And finally, since Scrum is about "inspect and adapt", you can keep an eye on things, pay attention to situations that end up in disagreements, watch the decisions made, see how things are evolving afterwards, and discuss it at the retrospective meetings if something is amiss. Maybe in time new solutions present themselves, you learn new things, people get a new understanding, etc. Whatever they decide "once" isn't necessarily permanent if in time they discover something better.


When we as Agile Coaches and Scrum Masters servant lead teams and help them make decisions, do we need to seek consensus?

Yes... and remember that consensus is not the same as unanimity.

This is a pretty good article on various approaches to obtaining consensus.

I like the Fists of Five technique myself (slightly different from what's in the article)**, where consensus is reached when everyone is a 3 or higher, and anyone who votes a 1 or 2 is asked, "what would we have to change to get you to at least a 3"? It's a simple structure that ensures dissenting voices are heard even if they belong to quiet people who don't always speak up. It took a while for my team to get familiar with it -- I had to re-explain it the first bunch of times we used it -- but now everyone knows it and we use it frequently.

e.g. if we "take it to the team" and ask them something "do you want to do this or that" do we need to seek consensus or do we need to seek a majority vote?

I would avoid majority vote except in simple low-stakes cases. The nice thing about fist-of-fives type consensus is that the thing you are deciding on evolves as people express concerns and the team revises the proposal and then does the consensus check again. This results in a better decision. Majority vote cuts off that possibility.

How do we know the team has made a decision.

This is part of the art of the SM or agile facilitator: to notice when it sounds like the team has made a decision, and then intervene with "OK, I think I'm hearing a decision here. Can we do a fist-of-fives (or some other consensus check that gets an explicit response from each team member) on {exact detailed statement of decision you think you're hearing}?"

**The variant I use has 5=great idea, 4=good idea, 3=ok/neutral/won't block, 2=I have concerns, 1=I have grave concerns, fist=veto.


Here are some ideas that may be applicable:

  • Rather than offering choices, present the situation to the team and have them deduce their options. Such ownership of the problem will make it easier for people to commit to a path—even if they do not fully agree. Make sure that dissenting voices are heard and their concerns acknowledged. Partner with them to find a solution they can commit to. Take it to the team again: use Liberating Structures (e.g. 1-2-4-All) to decide on a way to arrive at a new consensus.

  • Is there a small experiment or a spike that can provide more data for a better quality decision? Fail fast and learn from it.

  • Safety. Is it possible that there is a conflict simmering beneath the surface? One sign of conflict is people talking past each other. What is the ratio of advocacy vs inquiry? When the climate is healthy, people are usually quite willing to accommodate their teammates because they value their relationship. Look, you are in this for the long haul—this is not the first, nor the last, snag you will hit. The team needs to be adept at resolving disagreements and safety is required to practice and improve at healthy conflict.

  • The team is the value-producing unit. The team wins as one or loses as one, and the team members' commitment is therefore to the success of the team. Take the time to build this togetherness and unity. Introduce them to nonviolent communication and encourage any expression of self-organization or collaboration. A team in agreement will always outperform a team in discord.

  • Consensus doesn't mean that everyone must agree on everything. But they do have to support each other on everything. This is how they win. It is your job to ensure that they learn to self-organize/win.

Finally, consider the concept of “Consensus Trap” and the concept of “Disagree and Commit.” The latter has been popularized by the likes of Intel and Amazon. The Wikipedia page has some impressive quotes in the reference section. This quote is from Patrick Lencioni’s Advantage:

Great teams avoid the consensus trap by embracing a concept that Intel, the legendary microchip manufacturer, calls "disagree and commit." Basically they believe that even when people can't come to an agreement around an issue, they must still leave the room unambiguously committed to a common course of action



The preference is that a decision is unanimous.

If a unanimous decision is not possible then we may need to consider alternatives.

If no alternatives are appropriate then may make the decision by a majority vote.

If the decision is by a majority vote it is important that the people voting against accept the outcome. To achieve this we will need:

  • A team that trusts each other
  • A fair discussion and a fair vote
  • An inspect and adapt cycle to ensure if the decision does not work out it is quickly reversed

One thing the other answers don't mention is that not all decisions have the same impact on everyone, and for those that don't, you may need neither true (as in everybody really agrees) consensus or a majority vote.

For example, say that in a team of six developers, five of them estimate a story at three points and one is strongly insistent that that same story can be completed for one point. Rather than averaging, voting or coming to a "consensus" that is more likely just the one developer giving in, reframe it slightly to determine who will be taking on the story. If the one developer says not only that he is quite sure that it can be done for one point, but he will take on responsibility (in this or in whatever iteration it's selected) for that story, it's perfectly reasonable to estimate the story at one point.

Becuase I've in the past seen very strong emotional objections to this kind of thing, let me address a few of the more common objections to this particular example:

  1. What if the developer is estimating all the stories at half the cost of everybody else? This tends to be self-limiting, becuase a single developer can't take on responsibility for getting all, or even a substantial fraction, of the iteration's stories completed. "Lowball" just the stories that the developer can take on now, and negotiate and replan (with the assistance of the customer or product owner) as necessary.

  2. What if the developer is wrong about his estimate? Well, now he's learned something, just as the rest of the team will have learned something if they were wrong. Take whatever measures you need to reduce the risk on this so that the cost of the lesson will not be overly large. (E.g., agree to reduce the estimate below what everybody else thinks, but not to the one developer's level, if the risk of a very low estimate failing seems too costly.)

  3. What if the developer doesn't learn from this experience, and keeps lowballing estimates again and again? That's no longer the problem raised in the original question; deal with this different problem directly rather than changing other processes to try to work around a real problem that you're not fixing. If a developer doesn't learn from experience, you need to have a discussion with him about that and, if he continues to be disruptive to the functioning of the team, take whatever measures are necessary to mitigate that.

  4. This just feels too risky. Work on your risk management practices to manage the risk. You learn more through failure than success (if you're willing to learn the lessons from failure), and you improve more through attempting new things than avoiding them.

I won't make this post even longer by giving more examples, but the key points to take away here are:

  • When there's disagreement, to try to give space and opportunity to those who think they can overcome problems that others see.
  • Do appropriate risk management to ensure that failure is not too costly.
  • Ensure that everybody is learning from the failure or success of these attempts to do things that some people think can't or shouldn't be done.

I personally think that an Agile Coach or a Scrum Master is, and must be, a true "team leader," although one who uses a "laissez faire," or "delegative," management approach.

See: "What is Laissex-Faire leadership?

Present the issue to the team, make sure they understand it and its implications, and guide them to developing a response by consensus among themselves. You'd really like it to be a true consensus and not a "vote," because the person(s) who say "no" must have a reason to say that. Anyone who says "no" is going to feel overruled, hence no longer part of it. Not good.

Finally, IMHO: while the team is "self-organizing," the decision is yours, because you are the most-responsible party: "if a buck is to be stopped, it's gonna land in your cube." You should be satisfied, yourself, that what the self-organizing team decided to do is appropriate and justified. And that will partly depend on the team. You want to unobtrusively guide them to the best available outcome, while making every one of them a legitimate contributor to and stakeholder in the decision that finally gets made. All of them, and you, should concur.

  • regarding "you should be satisfied, yourself": I would argue that in some cases, it is best to stand back and let the team make a sub-optimal decision in order to learn from the results. Of course one should avoid high-risk or high-severity cases in which to let this happen. – Vicki Laidler Mar 14 '20 at 3:07
  • Well, generally, when I have been a team-member and I thought that the leadership was "trying to teach us a lesson," I felt decidedly ill-used. Experience is a good teacher but she leads a very painful school. If you have reason to believe that the team is making a mistake, become involved: guide them to what you consider to be a better alternative, always at the same time being willing to be guided! Don't consciously let a team waste its time. But also, recognize that they might well be subject-matter experts more than you are! They might be right! – Mike Robinson Mar 16 '20 at 15:28
  • Fair point. I'm thinking of cases where I have asked leading questions trying to guide them to see potential problems, and the team has dismissed the concerns or "that won't happen" or such. – Vicki Laidler Mar 16 '20 at 16:02

I'd like to add just one more point here. As a Scrum Master / Team Leader, you might well not be the "subject-matter experts (SMEs)" that other members of the team are. While you are the leader of the team, be sensitive always that you might not have all the answers and that you are not obliged to. You can lead a team that's doing something that you do not fully understand, as long as you know who does.

Your objective is to see to it that the best available outcomes are reached, as each member of the team working and thinking together is able to collectively achieve it. This is why you should strive to manage by consensus and should be reluctant to "decide, yourself" although I think that you must necessarily retain that prerogative. As you seek to guide the team, also always be willing to be guided. The coach doesn't win the game. The whole team wins. A good coach is vital to the fact that the team won the game, but the team will walk off the field saying, "we won!"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.