When "taking it to the team" should we seek consensus?
Alberto last edited by
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.
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.