Circle of Consensus

When I work as a scrum master, one of my bibles is “Agile Retrospectives – Making Good Teams Great”. It describes a number of patterns and exercises that one can use during retrospectives. When you work iteratively, especially when you have short iterations, it can easily go routine in the retrospective. It gets boring and does not give that much input into the continuous improvement that you’re after. But the book gives many tips on different exercises you can use to access information and make decisions or simply just to get a change.
The most common exercise I’m experiencing is a kind of brainstorm where everyone in the team writes down things that have been good and bad during the iteration on post-it notes and then group, prioritize and decide actions to take. It is an exercise that I feel is worn out and has some flaws. It is of course not nice to say that something has been bad so many teams mask to call it delta, i.e. what can be improved. But I think that is nonsense and prefer to call things by their right names. If you have good teamwork and an open discussion climate, you can also discuss what has gone bad. But as I said, I think there is a flaw in the exercise and that is that most of the subjects that come up have both positive and negative aspects. It often happens that the same piece ends up in both columns or is put up in between. So I have developed an exercise I call “The Circle of Consensus” which I have used at St. Jude Medical and at Mawell. I will follow the pattern from the book of how an exercise is done.

Activity: Circle of Consensus
Use in small teams (2–5 people) to analyze what the team thinks is important at depth.

Purpose
Analyze important issues and decide measures to take in consensus.

Time needed
20–60 minutes depending on team size, the depth of the discussion and how consistent the team is.

Description
Each member choose 1–3 topics that are important to them and discuss one subject a time until you have enough understanding and can reach consensus on what should be done.

Steps

  1. Introduce the activity by explaining that a regular brainstorm rarely penetrates a subject in depth and many subjects have both positive and negative aspects. Ask everyone to write 1–3 topics they want to discuss. Ask them to formulate themselves compact and to the point so that it is easy to stick to the topic. Participate yourself in the exercise if you are part of the team. “We will discuss one subject a time and I will record what we come up with.”
  2. Give the group a few minutes to come up with topics. You will usually notice when they are done.
  3. Ask them one at a time to formulate his or her subject. It is best if the same person leads the discussion which will develop leadership skills within the whole group.
  4. Encourage the group to discuss the topic from many different perspectives. Intervene if someone dominates too much or if someone is oppressed or censored. Be prepared to fill in with more aspects if the group is locked to one perspective.
  5. Usually the group reaches consensus on the subject and on what should be done. Note the topic and what actions the group decides to take.
  6. If you can not reach consensus you can either leave the topic or you can use the contradictions to analyze the group dynamics to obtain a better teamwork in the future.

Materials and preparation
Post-it notes for topics. Small patches helps to make compact and pithy formulations. Notebook or whiteboard to summarize the discussions.

Examples
This exercise often makes everyone on the team to speak and to discuss topics that are important in depth.

A team of three people has had problems with stress and have different views on how much work you should put down to write clean code. One topic discussed was what creates stress. There were many different things that created stress. One team member was stressed out just by knowing the team was behind schedule and another became frustrated by being forced to write smelly code. The third thought the client showed little interest in the work and was not told clearly what was expected of them. It was decided by consensus to talk more with the client and to work more actively to make a clear and prioritized sprint backlog.