Decentralised Decision Making
Agile project management and decision-making in the world of remote and hybrid teams.
Agile project management dominates the software development world. In recent years, remote and hybrid teams have also become dramatically more prevalent. Consequently, the software development industry must adapt to a globally changing world with remote and hybrid workflows. Decentralised decision-making is not new to modern work-life, but has become a necessity to sustain teams that may not be in physical contact or even share overlapping time zones.
Decentralised decision-making is a useful tool for empowering teams to distribute authority and autonomy across geolocations, buildings, office floors, and organisations — all while enabling more efficient decision turnaround times, increased ownership, and improved collaboration.
There are very many flavours of decentralised decision-making that include in-person or remote teams, team or independent work, hierarchical or flat organisational structures, etc. The most important property of any decision-making framework is clear and transparent expectation management with the teams and team leaders.
Although we will lead the discussion towards an Agile framework, it is important to understand the different options and how they could complement each other.
- Agile/Scrum/Kanban (i.e., software development standard) integrates the decision-making process from the self-organising principles of a scrum team. The team meets to collectively decide on the tasks, timelines, capacity usage, sub-team allocations, and project ownership. The decision process can be democratic, informed consent, and/or swarm mentality — each person works on what they believe is best for their skill set and timeline. Swarm mentality is more akin to the Agile/Kanban methodology.
- Integrative decision-making process builds a solution through collaborative dialogue and debate among the team members. This can be seen as a form of brainstorming or puzzle solving, where each member presents their solution(s), and discusses the merits and challenges of each others’ proposals. Each person can then decide to work on a piece of the whole puzzle or collaborate on more complex pieces together. This works for both Scrum and Kanban variations of Agile project management.
- Consent-decree (or Sociocracy) establishes that a decision has been made by the consent of all relevant parties, as opposed to the requirement for majority vote for one proposal. If two groups disagree about a decision, then one group can consent to the other group's decision. More often, in practice, if a direct majority cannot be attained, then the team can consent to the majority-minority proposal— especially in the iterative-by-design Agile framework.
- Decider Protocol establishes the understanding amongst the team that if a decision must be made before the dialogue or debate has been completed, then the team elects a decision maker (i.e., “Decider”) who is designated with final decision-making authority. The decision maker should be elected before the dialogue has begun to avoid biasing the election of the decision maker later. More often than not, the decision maker is allocated to be the Product Owner or the Scrum Master, depending on the team structure and dynamic. An effective Decider does not need to remain objective, but must be trusted to be fair and transparent — especially if they presented and decided upon their own solution.
- Open allocation or Lattice methodology creates a grid of team members, skill sets, timelines, and capacities. Then, team members can allocate their skill sets and capacities to a given project as presented by the (usually) product owner or project manager. In doing so, the decision for a given project or plan is created when the team member(s) chooses the project component on which to work — this is similar to Kanban above. Team member(s) — with oversight — may allocate a portion of their time to various projects based on their skill set, timelines, and capacities. Moreover, group decisions could be weighted by the “buy-in” for how much proportion of each member’s capacity they decided to contribute to the project or product.
The best-laid schemes o’ hamsters an’ humans
In the modern workplace, with various capacities, timelines, timezones, skill sets, and cultural expectations on leadership, well-organised and decentralised decisions making has become fundamental to product team leadership and product development. With the great variety of complexities with working remotely, across timezones, languages, and cultures, the most essential component of any decision-making process is clearly defined, transparent, and agreed-upon expectations per role, per team member.
An effective strategy to build a positive team, department, and organisational culture is to trust that all team members want the best for the product, while only being able to provide what they can in the moment — with respect to time, skills, capacity, focus, and authority. In particular, a blending of multiple team structures and decision-making frameworks will most likely result in a productive and coherent development team — as long as that blending is clearly defined to manage each person’s expectations.
In particular, Agile/Scrum allows teams to re-evaluate their requirements, priorities, and understanding of the product, user experience, market, business environment, and community at regular intervals. An Integrative decision-making process is normative. It provides a robust framework for collaborative decision-making, ensuring that each member’s input contributes to the final decision. It provides trust that each team member is being heard and respected — especially if consensus becomes challenging to reach.
The more number and diversity of opinions expressed, the better the outcome will be
To both contrast and complement the collaborative expectations of the Agile project management framework, deliberations have to be timely. If consensus is not effective within the predefined planning timeframe, then the scrum master or product owner could ask for a consent decree. Each team member could consent to a specific — often majority-minority — plan for the immediate project management phase; e.g., the sprint or other iteration of product development.
For a team to effectively consent to forego a direct majority, each team member must only agree that the majority-minority proposal is “good enough for now, safe enough to try”. This is the defining principle of Sociocracy. It is a technique practised by psychological safety and personal ecology coaches alike. Sociocracy helps to minimise conflict by accepting that failure is a part of the iterative, Agile process. In many cases, teams would benefit greatly from starting all decision making processes from there Sociocratic perspective: “good enough for now, safe enough to try.”
Without the consent decree, the team must still move on to begin development along one of the plans presented during the planning phase (e.g., Sprint Planning). The Decider (pre-elected decision maker) has the explicit authority to finalise the decision for the sprint or product development. For sprint planning, the Decider is often the Scrum Master. For Product planning, the decider is most often the Product Owner. In both cases, the person must coordinate all facets of the product/project development life cycle, and thus should have the most complete picture of the product/project itself.
Agile coaches make plans while experienced developers laugh
The methods above for decentralised decision-making were often developed or implemented independently. Below, we will show how well they can work together. First, let us examine the three procedures independently.
Integrative Decision-Making Procedure
- Define the decision to be made
- Establish a shared understanding of the problem
- Facilitate team members sharing their perspectives, ideas, and concerns
- Identify overlapping and collaborative interests in order to find common ground
- Evaluate a set of potential solutions as a team
- The Scrum Master (or Product Owner) presents the most viable solution that includes or best addresses the collective needs and concerns
- Vote on the final solution that includes or best addresses the collective needs and concerns [This is the physical act of deciding]
- Establish a plan for implementing and monitoring the decision
Consent-based Decision-Making Procedure [skip to #7]
- Define the decision to be made
- Establish a shared understanding of the problem
- Facilitate team members sharing their perspectives, ideas, and concerns
- Identify overlapping and collaborative interests in order to find common ground
- Evaluate a set of potential solutions as a team
- The Scrum Master (or Product Owner) presents the most viable solution that includes or best addresses the collective needs and concerns
- Instead of voting to accept the proposal, the team votes on whether they are willing to consent to the proposal as “good enough for now, safe enough to try”.
- Establish a plan for implementing and monitoring the decision
Decider Protocol Decision-Making Procedure [skip to #6]
- Define the decision to be made
- Establish a shared understanding of the problem
- Facilitate team members sharing their perspectives, ideas, and concerns
- Identify overlapping and collaborative interests in order to find common ground
- Evaluate a set of potential solutions as a team
- The Scrum Master (or Product Owner) decides the most viable solution that includes or best addresses the collective needs and concerns
- Establish a plan for implementing and monitoring the decision
Steps 1–6 and 8 have always been the same — literally copy/pasted. The difference becomes if the collective votes or consents on the solution, as oppose to the Decider deciding for the group.
Cohesive, Decentralised Decision-Making
No one method is best for all teams — nor for all decisions. Being aware of a variety of team management and decision-making methods allows leaders and decision-makers to be flexible, versatile, and agile (pun intended) to the problem(s) before them. As such, a cohesive, decentralised decision-making process could be implemented to allow the team to step from collective to necessary decision-making practices.
For the psychological safety of team members, all available voices must be heard; and more often than not, the final decision should be collective — i.e. the Integrated Decision Making Process or Consent-Decree Process. The consent decree is an especially effective technique to maintain the team’s collective mental health, while moving the product forward. With great restraint, if the team is unable to consent to a given solution, then the (pre-elected) Decider should be allowed by the team to make the final decision.
Cohesive Decision-Making Procedure [skip to #7, 8, 9]
- Define the decision to be made
- Establish a shared understanding of the problem
- Facilitate team members sharing their perspectives, ideas, and concerns
- Identify overlapping and collaborative interests in order to find common ground
- Evaluate a set of potential solutions as a team
- The Scrum Master (or Product Owner) presents the most viable solution that includes or best addresses the collective needs and concerns
- [Integrated] Vote on the final solution that includes or best addresses the collective needs and concerns
- [Sociocratic] The team votes on whether they are willing to consent to the proposal as “good enough for now, safe enough to try”
- [Decider Protocol] The Scrum Master (or Product Owner) decides on the path forward for a given task, sprint, project, product development stage, etc.
- Establish a plan for implementing and monitoring the decision
In all cases, once the decision-making process has been completed, it is in the best interest of the team to accept the results and develop the decided tasks or product increment. All team members would have ample space to present their findings at the Sprint Retro — or request their solutions again at the next Sprint Planning. The team relitigating a decision before the next Sprint Planning would be highly inefficient, ineffective, and unproductive, as well as likely inhibiting the mental health of the team members and decision-makers.
Asynchronous Decision-Making
Many teams are deliberately remote and often do not coexist in a centralised timezone. As a result, Sprint Planning, Retros, Dailies, and the like cannot occur seamlessly with synchronous methods: i.e., in-person or on-video calls. Instead, these teams must use techniques that have been developed for asynchronous decision-making. Teams that coexist within the same building, city, country, or timezone range can equally benefit from these methods and techniques.
Asynchronous decision-making techniques, such as pull requests, issue documentation, threaded conversations, code reviews, and cryptographic document signing are already pervasive in the software development community. These methods can also be implemented outside of software development by using an agreed-upon system to digitally discuss, vote, consent, decide, and sign off on decisions.
For example, the product backlog can be seen as the Issues on the repository. The team can present a pull request for the sprint tasks per sprint iteration. The pull request includes a dialogue conversation section, as well as a poll for voting. Specific people (or the full team) can be delegated as required to sign off on the pull request as Assignees. The decision would become final once it has been merged into the development branch of the Decision repository.
Note that GitHub, GitLab, and their competitors provide the capacity for private repositories, which could be used for decision-making if public discussions are not amenable to the team dynamic.
Another technique would be to use asynchronous, online, collaborative document development. In a document or spreadsheet, the product owner or scrum master (or together) could present their plan for the next iteration of the product development before the sprint starts. The team could then discuss their breakdown of the tasks and justify their opinions asynchronously — as they find time within their work-life timeline. Then the sprint planning procedure would be for each team member to sign off on this document before a specified date.
In both the git (pull request) or online document versions of asynchronous decision-making, a majority vote or official consent would enable immediate development by the team members. If neither is viable before the sprint is scheduled to begin, then the product owner or scrum master would digitally call for a consent decree (lack of veto) by opening a second poll on the pull request or online document. Each team member would be expected to consent or justify the lack of consent by a specified time — e.g. 24 hours later. After which, a lack of veto by any member would allow the team to proceed.
Finally, if none of the above becomes viable — e.g., an unresolved veto— then after the established consent timeframe has passed, the product owner, scrum master, or other pre-elected Decider would have to make a final decision on the sprint plan, task assignments, prioritisation, feature direction, task breakdown, or any other decision that could not be finalised otherwise. This should be done transparently and with effective communication to all team members. It should also be documented to avoid the implications of bias from onlookers with clouded hindsight.
In any of the above cases, for asynchronous and decentralised decision-making, the resulting decision will be “accepted” (pull request) or “closed” (online document) as a record of the process for the sprint retro (short-term) and product development life cycle (long-term).
The most important property of any decision-making framework is clear and transparent expectation management with the teams and team leaders
Expectation Management
In all cases, the decision-making process must be transparently documented and clearly defined. It is highly unlikely for the team to function effectively during the decision-making process if members of the team do not agree on the protocol for decision-making itself.
As an analogy, if members unconsciously or unknowingly build a different product because expectations were not managed accurately, then the product is not likely to function. Similarly, if members unconsciously or unknowingly process decisions differently because expectations were not managed accurately, then the decision-making process is not likely to function. Both situations would lead to reduced mental health for team members and, especially, decision makers.
Join the Medium membership program to continue learning without limits. I’ll receive a small portion of your membership fee if you use the following link, at no extra cost to you.
If you like the article and would like to support me make sure to:
- 👏 Clap for the story (50 claps) and follow me 👉
- 📰 View more content on my medium profile
- 🔔 Follow Me: LinkedIn | Medium | GitHub | Twitter
- 🚀👉 Join the Medium membership program to continue learning without limits. I’ll receive a small portion of your membership fee if you use the following link, at no extra cost to you.