With a group of people discussing a specific issue, there is often a decision to be made at the end. We encounter these situations not only regularly in our private lives (What are we having for dinner tonight? Where are we going on vacation?), but especially in our work environment. In every company and in every team, there are more or less significant decisions to be made on a daily basis that can decisively influence the course and success of a project.
In this blog series, we explore why it’s especially important in agile development teams to address how decisions are made.
Since Scrum has established itself as the leading project management method in the field of software development, the principle of personal responsibility plays a major role here. Agile teams operate in a self-organized manner and must make decisions on their own responsibility at high frequency. In order to simplify the decision-making process and prevent possible complications, it makes sense to compare the advantages and disadvantages of the different methods and evaluate which method is the most purposeful for the respective topic.
We have compiled our experience and present the most common methods and their applicability in agile teams in this series.
In the first part of our series on the topic of “Decision-Making in Agile software Development”, we have already shown the pros and cons, as well as the feasibility of the individual decision and the majority decision in agile development teams. Since both methods turned out to be not very effective in this area, we want to take a closer look at consensus and consent based decision making in part two.
The Consensus Decision
According to the consensus principle, decisions are only made when all participants agree to a solution. That means, active efforts must be made to reach a consensus. All group members must therefore unanimously agree with the decision (if necessary at the end of the discussion).
We may be familiar with consensus decisions from criminal prosecutions in the United States, where decisions by the jury have to be unanimous.
How does it work?
There is no defined process for how to reach consensus - at most times there are discussions until all parties agree.
A possible (mediated) approach could be as follows:
- Define by which point a consensus must be worked out and what happens if no consensus is achieved: does the situation remain unchanged?
- First, visualize the problem.
- Collect possible solutions (e.g., by brainstorming) and form clusters of similar ideas.
- A non-binding vote shows the team members’ points of view and in most cases their emotions as well.
- In turn, everyone may vote for one option.
- Another non-binding vote shows how far it’s still to go to reach consensus.
- When a possible solution emerges, one can negotiate with the remaining supporters under what conditions they agree to the option.
- Repeat from step 5 until everyone agrees to one option.
|The method builds a sense of community and the “backing” of the decision.||The decision making process can be very time consuming as the decision must be unanimous.|
|Ideally, the result satisfies all team members.||Therefore, the method is not well suited for larger groups.|
|The realization of the decision is usually taken into account in the decision-making process.||The focus is (rather) on negotiating a solution and not on finding the best solution.|
|The power is distributed absolutely equally within the group.||Often, a bad compromise is the result, because people may only agree in order to finally reach a decision.|
The Consent Decision
Unlike consensus decision-making, where decisions are made only when there is 100% agreement, a consent decision means that decisions are made only without dissenting votes - “I’m all for it” (consensus) vs. “I’m not against it” (consent).
“A (mediated) group process for decision making: gather objections, and integrate the knowledge that lies behind them to further develop proposals and existing agreements”
In doing so, the solutions should be “good and safe enough up to the date of the next review.”
How does it work?
- Focus: What is the content of the agenda item, what is to be decided? What is to be achieved with the procedure?
- Imaging phase: Presentation of the topic/proposal and gathering all the information necessary to form an opinion.
- Opinion-forming phase: All participants have the opportunity to express their opinion on the topic (one after the other). Possible solutions or criteria for a solution are collected. Afterwards, there is usually a second round of giving opinions
- Decision-making phase: The final step is the consent round to pass a resolution or find a resolution without serious objection. The moderator prepares a proposal based on the criteria defined in the opinion-forming round, reads it out and puts it to the vote. Each participant gives his/her consent or states a reasoned, serious objection. Together, the argument behind the objection is then incorporated into a new proposal and put to a vote again until consent is reached.
Different practices can be helpful in decision making (they can of course also be used in other approaches, e.g. consensus building):
Gestures by hand:
- Thumbs up: No objection, no concerns.
- Thumbs horizontal: I disagree, but can come to terms with the decision and then support it.
- Thumbs down: I disagree and have strong concerns.
“Fist to Five”: With this method, agreement or disagreement can be queried more granularly (this is also used, for example, in SAFe to query agreement/disagreement or the level of assurance). Here, the number of fingers shown provides information about the degree of agreement with a topic:
|Making decisions faster than with consensus (→ “good enough”)||Making decisions will take longer than using some other methods (e.g., single decision).|
|Objections are used to improve solutions.||The process leading up to the decision often requires experienced moderation.|
|Minorities are heard (as opposed to majority rule) and can bring their perspective to the discussion.||The method is not recommended for large teams due to the extensive voting process.|
|The decision-making process is usually highly transparent.|
Implementation in agile practice
Both of these decision-making methods are very well adapted when working with Scrum. Above all, the need for all team members to participate in the decision-making and solution process can be perfectly combined with the Scrum values - in this case “commitment”.
A practical example of the use of the consensus method would be the estimation meeting, where the Scrum team meets to discuss new and/or existing user stories and estimate the workload of the respective story. Here, the discussion that leads to finding consensus is valuable and desired, as differences in background knowledge, understanding, and scope of backlog items are identified and shared with the other team members. This can lead to a better overall understanding and also a better solution. The consent method is often used, for example, when selecting the appropriate technologies, since this is usually not a decision that can be made purely from a black and white perspective. Accordingly, it is helpful to discuss the available options and to make the best choice given the current time and state of knowledge.
Due to the small, dynamic teams in Scrum, the downside that both methods are less suitable for larger groups has usually no relevance. How complex and time-consuming the decision-making process really is depends to a large extent on the interaction within the team and the moderation skills of the Scrum Master. In any case, the mutual decision should not be intangible and, in the sense of the three pillars of Scrum theory (Transparency, Inspection, Adaptation), should be continuously reviewed and, if necessary, redefined.
In the third and last part of our series on the topic of “Decision-Making in Agile Software Development”, we will introduce two more interesting methods. Then you will find out which method is particularly crucial in terms of technical expertise and what the concept of “systemic consensus” is all about.
Read the first part of our series:
Decision-Making in Agile Software Development - An Overview - Part 1