liveBook · Manning

Unanimous vote

As explained in Collaborative Software Design: How to facilitate domain modeling decisions

A unanimous vote is a decision procedure in which every participating voter supports the selected option.

A unanimous vote is the final agreement stage of a collaborative decision: after an option gains a majority, the group works with dissenters until everyone can support an improved decision. Majority rule alone can leave a minority feeling overruled, creating resistance or hidden conflict. section 9.2.3 section 9.3.1

Treat disagreement as information, not an obstacle. Ask people who opposed the leading option why they disagree and what they would need to go along with it. Incorporate those needs into the decision, then vote again. If unanimity remains impossible, return to surfacing unspoken alternatives rather than forcing closure. section 9.2.3 section 9.4

A practical route from majority to shared commitment:

  • Present alternatives clearly and vote when one option is likely to gain a majority or voting may reveal unspoken perspectives. section 9.2.3
  • Focus on every dissenting voter, including a single person, and ask what concern or need drives their position. section 9.2.3
  • Revise the chosen option to include minority needs, then repeat the vote until everyone agrees. section 9.3.1
  • When agreement cannot be reached, resume exploring alternative viewpoints instead of treating the majority result as complete. section 9.2.3

Reconciling two bounded-context designs

Two competing bounded-context designs can become opposing camps unless participants understand what each design solves for the other side. Pair people who prefer opposing designs, have them interview each other about the problems their preference addresses, and let both designs evolve with the group’s insights before seeking agreement. section 9.3.1

Figure 9.5 The bounded context designs after the design EventStorming. Both designs started to evolve and include wisdom from the group. The left design, Back-Office Separated, started to split Visitor Reservations from Ticketing to choreograph a reservation from a paid ticket. Payments Separated, on the right, started to move toward more orchestration where Ticketing goes to Payments to finalize a ticket.

Compare the evolving alternatives to see how competing bounded-context designs can absorb group wisdom rather than remain fixed sides in a vote. section 9.3.1

How Collaborative Software Design: How to facilitate domain modeling decisions covers it

How deep it goes
Provides an iterative facilitation procedure with questions, revision, revoting, and a fallback to explore unspoken alternatives.
Examples
Uses competing bounded-context designs and paired interviews between participants who favor opposing designs.
What it assumes
Builds from a majority vote and teaches how to include minority needs after a preferred option emerges.
What you can do after
Apply it through facilitation questions that uncover dissent, revise an option, and seek shared agreement.
How it connects
Connects majority vote, minority perspectives, resistance, conflict, EventStorming, bounded contexts, and Small Group Diverge and Converge.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Collaborative Software Design: How to facilitate domain modeling decisions. The section links point to the parts of the book it draws on.