Consultative Individual Decision vs. Systemic Consensus Building

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 outlined the advantages and disadvantages as well as the feasibility of the individual decision and the majority decision in agile development teams. Building on these results, we then compared the consensus and consent decision in part two of the series. We are probably quite familiar with all of these methods from everyday life and our work environment. Beyond that, however, there are other efficient ways to make decisions which are worth a closer look, especially in a technical context.

Consultative Individual Decision

or the consultative individual decision, one or more persons are selected as decision-makers who are particularly well experienced in a topic or have good access to relevant consultation partners. Important: The selection of both the decision-makers and the consultation partners is based on (professional) suitability and proximity to the topic; hierarchical levels have no relevance here.

The consultation partners are to be involved as advisors in the decision-making process by the decision-maker. At the end, the decision maker (or group of decision makers) presents their solution.

This decision has to be accepted and supported: The entire company or the entire team must fully support the decision-maker(s).

How does it work?

  1. Choice of decision-maker - The decision maker should be as close to the problem as possible, the involvement should be accordingly high. In most cases, it will be the person (or group of persons) who would have escalated the decision to the next level in the “old mode”.
  2. Choosing the consultation partners - In addition to choosing the most suitable internal and external experts, it is advisable to select colleagues who will be directly affected by the consequences of the decision.
  3. Consultative dialogues - In essence, this is about sharing knowledge and experience. How have the respective colleagues dealt with similar situations, or what options would they recommend? The goal is to learn from and with each other.
  4. Choice of the solution - The decision maker now takes full responsibility as an individual (or as a group) and decides in the interests of the company, taking into account the best ideas and advice of the colleagues consulted.
  5. Giving Feedback - The group for which the decision was made gives feedback to the decision-makers. If things go wrong, everyone still has to support the decision, considering that the decision-makers have done their best.
Decision-makers usually have a lot of background knowledgeGreat trust in the decision-maker is a must
Different opinions are heardIn the worst case, wrong decisions fall back on the decision-maker (despite support from the team).
Decisions have more support than individual decisions 
Decisions can be achieved faster than with many other methods 

Systemic Consensus Building

Systemic consensus building (similar to the consent decision) aims to find the solution with the least resistance in the group. As with other methods, the objective is to reach a decision that is better than the so-called “passive solution” - that is, the decision (-method) that would be used if no agreement can be reached.

The group then determines which of the self-developed proposals for a solution receives the least rejection. For the decision-making process, each participant assigns “resistance points” to each proposal. The proposal with the lowest total number of points wins.

How does it work?

  1. Developing a question - A group wants to make a decision that is supported by all participants. It develops an overarching question that cannot be answered with a yes or no answer. In addition to the question, this phase should also define what happens if no solution can be found (“passive solution”). Example: What technology/programming language do we want to use for a new service?
  2. Creative phase: Collecting proposed solutions - In the second phase, proposals for solutions are collected, whereby creativity and diversity are desired. All ideas and wishes may be put forward and are on an equal footing. The proposed solutions are not commented on or discussed in this phase.
  3. Assessment phase - In the assessment phase, each solution proposal is evaluated by each group member with so-called “resistance points”. Zero points mean “no resistance” or “I can support this solution”. The highest number of points to be given is 10 and means “strong resistance” or “I strongly reject this proposal”. The evaluation is recorded on a matrix.
  4. Evaluation - In a final step, the points awarded by the participants are added up for each proposed solution. The solution with the lowest number of points experiences the least resistance in the group and is therefore closest to a consensus.
Participants have creative freedom in the processDifficult to conduct without moderation
Many solutions (which may even seem far-fetched at the outset) are consideredUnfamiliar/new format, i.e. experience in practice may be lacking
The method is very goal-oriented, as the danger of getting “bogged down” in discussions is minimizedProposed solutions must be phrased clearly and unambiguously

Implementation in agile practice

Especially in very complex agile environments with challenging technical infrastructure, it can make sense to use the consultative individual decision for decision-making. Particularly in larger agile teams, smaller consultative dialogs can prevent inefficient, exhaustive discussions among all members. Even if a smaller group of technically competent members discusses the solution with the later ‘decision maker’, it should not be forgotten to ensure a learning effect for all members of the team through an exchange of information afterwards.

Systemic consensus building is also very effective in an agile context. Above all, the participation of the entire team promotes agile values and strengthens the feeling of having developed a solution together and on an equal footing. Due to the fixed scheme, lengthy discussions are limited and creative solutions are explicitly greeted. However, the need for moderation increases noticeably with larger group sizes. Also, group members may be somewhat disengaged from contributing to a creative decision-making process.

Both methods can help to make a decision in complex, ambiguous situations. They should offer a solution that is “good enough” for the current state of knowledge and understanding. Experience shows that a decision based on one of the two methods is usually better than making no decision at all - moreover, the option to “do nothing” is often also a choice (or at least the “fallback” if no decision can be made).

If you want to learn more about Scrum and agile teamwork, have a look at the following articles:
Scandio Report - Scrum Edition
Why every agile project should think about a Proxy Product Owner