As I mentioned in a past post, one of the problems my team was strugling to solve was a tendandcy towards debilitating concensus. We would sometimes find ourselves debating an issues ad nauseam, finding it very hard to get to a point where we converge on a course of action.

An interesting aspect of this issue was that it didn’t affect our substantial decisions, but rather our ancillary ones. For example, choosing a caching strategy for our auction result took an single meeting, but generating buy-in for a the use of a Functional Programming coding style took months of back-and-forth debate. Even though this was only true for some of our decisions, this was disruptive enough that we felt it was affecting our ability to deliver value to the company.

This post is part of the series The secret sauce to an effective team which describes the steps taken within my team at Unruly in order to facilitate the fostering of psychological safety amongst members of the team.

Why Was It So Hard To Gain Concensus?

Consensus decision making is often thought of as a unanimous vote by the team for a single first choice. We always recognised that generating enough buy-in for such a vote on every single decision is impossible, but the team did seem to tend towards the difficulty of finding a compromise that all members felt they could support, even if it wasn’t their first choice.

The main thing holding us back, in my opinion, was a lack of constructive conflict in the team. This changed dramatically thanks to our Feedback & Cake sessions, Getting better at X sessions and our adoption of the Occupy hand signals which made it easier to conduct constructive debates; but even with all those changes, we would still sometimes find ourselves going in circles when trying to decide on a technical or organisational course of action.

As the team became more comfortable with conflict, we began to identify a pattern in these prolonged debates. In many cases, we would find one or two developers, different ones every time, who would block the proposed compromise. In most cases, this block would be expressed as a concern rather than an objection and we realisd this concern revealed an underlying lack of trust.

Specifically, the lack of trust could be described in the following manner: developers couldn’t trust their teammates to revisit a decision in the case where they might have changed their mind at a later point in time.

Elevating Experiments

Addressing this fear was actaully far easier, and more effective, than I would have expected.

We retired the word decision and replaced it with the word experiment.

An experiment differs from a decision in several ways:

1. Experiments have a specific mandate. We always define the goal of the experiment which clarifies what it is trying to achieve.
2. Experiments are timeboxed. We always assign an expiration date for the experiment after which we revisit the method defined by the experiment and unless consensus has been achieved, we revert back to our previous method or adopt a new experiment.
3. Experiments have owners. Unlike working agreements, which are decisions the team has commited to following as a group, experiments are owned by an individual in the team who is responsible nudging the team whenever the experiment is forgotten and schedules the follow up when anexperiment expires.
4. Experiments are elevated. Again, unlike working agreements, we place our experiment cards as an In Progress item on our Agile Board. Along side our User Stories you might spot an Experiment card and that card will stay in the column until its expiration at which point it moves to Review.

By placing our Experiment cards along side our User Stories we have elevated these experiments from a mere momentary decisions to an on-going evolving process. Their constant visibility demands our full attention, and the transitory nature of story cards is projected onto the experiment, reducing the concern that developers might have of decisions being set-in-stone and unchangable.

The Slow Decline Of Experiment Cards

It wasn’t even six months after introducing experiment cards that I noticed two changes taking place in parallel.

The first was a slow decline in expriments. Less experiment cards were appearing on the board.

The second was a rise in off the cuff suggestions that the team “experiment by doing X” to which people would simply nod in agreement and accept the suggestion without arguing. The team seemed to have not only become more comfortable trying ideas that their instinct labeled as possible, but also comfortable with these ideas being applied without the formality of an experiment card. To me this signaled a great improvment at trust within the team.

All in all I feel the experiment cards proved to be a very effective and easy to implement tool which I intend on utilising in the future even when there are no underlying trust issues.

1. The Agile Board is where the team maintains the lifecycle of our User Story cards, Technical Development cards and Research cards. These cards are moved, like on a Kanban Board, through this lifecycle going from Backlog to In Progress to Review and finally to Done.