Collaboration is one of the basic tenets of agile development, but in an environment where speed is touted, how is decision-making handled when there is not agreement amongst the team? Does collaboration always mean consensus? How do you move forward if there is not unanimous agreement? Let's look at some decision-making techniques that are used in agile environments to facilitate collaboration allowing teams to come to consensus quickly.
There are certain situations where an agile team is tasked with making decisions in a certain time frame. One example of this might be a Scrum Team making sizing estimates on the user stories in a product backlog. Before beginning this exercise, the team should decide how they want to handle the decision-making process. Scrum teams are self-directed. Scrum tells us to collaborate and to operate using time-boxes, putting limits on the length of time we spent on tasks. It does not dictate that we must reach unanimous consensus on every decision or tell us exactly how much time should be spent discussing and agreeing upon that decision. The team decides these things.
Two consensus-based techniques that can be used are called "Fist of Five" and "Planning Poker." In both of these techniques, team members assign a value to their gut feel, and outliers are given a chance to explain their reasoning to the group. However, a time limit should be set and a decision made when that limit is reached.
This technique allows participants to quickly place a vote ranging from zero to five. The decision in question is presented and participants raise their hands, showing their vote by way of the number of fingers that they hold up. Often Fist of Five is used to indicate support of an assertion. A fist would indicate zero, a vote completely against whatever issue was being raised. A five would indicate full support. Raising three fingers would indicate that although there were reservations, the team member would be willing to move forward with the decision.
The team must decide how they want to operate if there are a variety of opinions. Some teams may decide that everyone must have at least three fingers raised in order for the decision to be implemented. They give those people that are least supportive an opportunity to explain their concerns. The team may decide that if, after the allotted time frame, if there are any team members that have voted with less than a three-finger response, the decision will be against moving forward with the assertion in question.
Fist of Five could also be used for initial estimates when doing sizing on user stories. In this case, the range would not indicate level of support, but relative time the team believes it would take to complete the user story. Similarly, a technique called Planning Poker is used to as a way to rank estimates in terms of size.
Each team member that is participating in the decision using Planning Poker will get cards with numbers representing the relative time it will take to implement a user story. Typically, the deck will have numbers representing the Fibonacci sequence starting with zero: 0, 1, 2, 3, 5, 8, 13 and so on. The thinking behind this is that as estimates are larger, there is more uncertainty, which should be reflected with a higher number.
In this technique, a team member that is most familiar with the feature, perhaps a lead developer, would give an overview. There would be opportunities for the team to ask questions and get clarification from the product owner and to clarify assumptions and risks.
Each player would then lay face down a card representing a size estimate of the feature in question. The units of measure would vary. They may represent days or a unit called "story points," which are a measure representing size and complexity, rather than time.
Players flip over their cards. Those with the highest and lowest values are given the opportunity to present their viewpoints to the other team members, after which the estimation process is repeated.
However, if consensus is not reached after the agreed-upon time, the team will have come up with a method of coming to a decision. One example would be to always go with the highest value when consensus cannot be reached. This would allow for a more conservative estimation. If the estimate is high, the user story will be implemented ahead of schedule which is preferable to the alternative of a late delivery. Another option is to agree that the team member with the most knowledge of the application will break a stalemate and make the final decision. Some team members that feel they don't have enough information could be allowed to abstain from voting.
Whether using Fist of Five, Planning Poker or some other technique, there should be some method for determining how the team will move forward if there is not complete consensus. Collaboration requires working together as a team, but it does not necessarily mean there will be complete agreement amongst the team on the decisions that must be made. The key is deciding together as a team how to handle those situations where there is not complete agreement and to move forward.
This was first published in February 2010