Development Teams operating in an agile environment benefit from having a high degree of freedom. These Teams are expected to make use of this freedom to make politics-free, high-quality decisions and offer companies unbeaten levels of value added in return. This is how companies give empowerment back to domain experts after long years of decision making done by managers in “Highest In Position Person’s Opinion” mode.

The quality of teams’ decisions depends not only on domain knowledge of team members, but also on the voting mechanism used to make a decision itself. There are multiple standard voting methods available for development teams such as Unanimity, Majority, Plurality and even Dictatorship (usually Dictatorship of a most experienced developer, ouch!). All of them are suboptimal though. “The Winner-takes-it-all” approach constitutes particularly nasty mismatch with agile values and mindset introducing an element of competition among team members. Plurality and Majority open field for team division as well by simply ignoring to take into account some team members views. The above-listed approaches push teams out of healthy conflict levels towards conflict escalation with all the negative consequences. The mechanism of Unanimity almost gets there to the point. However it is too rigorous, as one does not expect all the team members to reach 100% consensus. Also Unanimity increases probability that a team will get stuck with endless discussions unable to reach 100% agreement.

So what is the ideal voting mechanism for agile development teams? To answer this question let’s think in terms of its purpose. Team members use voting mechanism somewhat different than politicians or opponents: team members do not use it to overrule views of some other team members, or to win a contest, or to become more respected, or prove they are right, or prove the other guys are wrong… Teams use a voting mechanism to enrich discussion and increase understanding of the subject at hand. Only as a result they can make the best educated choice possible. And there are such voting mechanism already invented and ready to use: The Jake Calabrese’s Fist of Five Voting and the McCarthys’ Decider protocol. Both of the methods ensure that views of all team members are taken into account. Both ensure that no progress will be made if there are ‘No’ raised while in parallel offer process to convert ‘No’ to ‘Yes’ or at least to ‘Supporters’. And they are not that strict as unanimity approach is as they accept the fact that some team members will be most comfortable going no further than ‘Supporter’.

By using these mechanisms you will get all team members in “All-at-the-same-page” situation and will avoid “The-winner-takes-it-all” situation. Still, note that all group voting mechanisms are prone for phenomenons that are built-into human mind: The Confirmation Bias and The Conformity Bias.

Please share your experience! What voting mechanism does your Team use?