Chapter 3 In the Soup
. . . in which team members discuss things that are outside their power to change, and the facilitator helps them focus their energy on what they can change and accept what they cannot change
The team is now really comfortable with retrospectives, and Sarah is happy about this progress. They have had many discussions and conducted many experiments, and the team can see cooperation, code quality, and overall happiness increasing over time. At the last two retrospectives, alas, the team ended up choosing to discuss the missing test framework. When they dot-vote, this issue is always voted as the most important problem to solve.
Unfortunately, these discussions always lead to the same conclusion: that management resembles a stingy Uncle Scrooge. The team ends up discussing prices, possibilities, technologies, and management, but they make no progress toward a solution. Sarah knows the missing test framework will most likely be the subject of the next retrospective as well. She is as frustrated as the rest of the team about this issue.
It is often the case that, after clearing the small issues during the first round of retrospectives, the team encounters a real hurdle—a problem that is out of their domain of power. They might not realize at first that this problem is out of their hands, and they happily spend hours discussing solutions they have no power to implement. After a few retrospectives, however, the discussions become more frustrating than happy.
A subject that needs management approval/action can become the starting point of many frustrating retrospectives, since the team cannot resolve the problem. The retrospectives turn into groundhog days,1 where the same issue seems to be discussed from different angles at every meeting.
1. Referring to the film of the same name, where a man is destined to relive the same day over and over again, ad nauseam, until he learns to be a better person.
The antipattern solution is simply to do what you were taught initially as a retrospective facilitator: you let the team decide what the biggest obstacle is and let them discuss it in search of a solution. It seems like the right decision, because retrospectives are about reflection and the team finding the best solution themselves, but in some cases, it can lead to the negative consequences described next.
When the team encounters a situation they cannot change, it is sometimes because they lack the skills to do so, but more often, it is because they lack the authority to do so. Retrospectives spent looking for solutions that the team has no power to act on are doomed to unfruitful outcomes. In addition, team members may form a negative view of retrospectives in general, seeing them as an unproductive use of their time.
Sometimes, of course, what the team wants aligns beautifully with what management wants, but at other times, management has different priorities, and the situation stays the same. Retrospectives degenerate into complaint sessions and are a waste of time.
You hear people make comments such as “We want to work on the things that really matter, not just which coffee we should buy” or “We are always discussing the same thing.”
After the “problems” are collected, draw two circles on the board, as shown in Figure 3.1. The innermost circle contains issues that the team can control—that they expect to have the power to change (e.g., “start doing code review” or “change location of standup meetings”). The next circle contains issues over which the team has some influence. It is for issues the team cannot directly change but for which they can take persuasive action.
Typical issues in the outer circle are the way the management asks the team to start new things or how the team cooperates with another team—issues related directly to the team in one way or the other but that involve people not present at the retrospective.
The space outside the circles is endless, so a third circle is not used. This space contains all the issues that are part of the environment, “the way it is,” or the soup. These are issues that affect the team but that the team has no influence over (e.g., the company is losing money and has to lay off employees). Other issues in this space might be the geographical placement of the offices or the personality of someone in the company.
This activity is called Circles and Soup (Larsen & Derby 2006), but it is also known as circles of influence. The activity is to be used much like the Serenity Prayer: “God, grant me the serenity to accept the things I cannot change, courage to change the things I can, and wisdom to know the difference.”2
2. The prayer is often attributed to the Protestant theologian Reinhold Niebuhr, although he conceded he might have been influenced by a forgotten source.
What makes the Circles and Soup activity productive is that it gives the team a realistic perspective of the issues they want to resolve and the scope of their power to address them. As they examine the causes of “soupy” issues that seem beyond their control, they sometimes find that those issues can be moved into the circle of influence or even into the circle of control. For example, maybe the team wants to sit closer to their testers in India, but a cause-analysis activity such as 5 Hows or Fishbone reveals that the real reason for needing more communication is that the initial communication is insufficient or that the documentation received from the testers is misunderstood. And now it is suddenly an issue the team can do something about.
For the issues that remain in the soup, it is sometimes beneficial to invite someone from another team, or perhaps a manager, to the retrospective. However, as discussed in Chapter 15, Curious Manager, “outsiders” may inhibit the team members’ participation. In general, my viewpoint is that the only people you invite to a retrospective are the people in the core team. But if the Circles and Soup activity shows you that some important issues would benefit from having someone outside the team present at the retrospective, I would ask the team if they would object to inviting that person to the next retrospective. This goes for managers as well as other teams’ members.
If it is not possible, due to geography, to have the other person present in the room, you will have to arrange an online retrospective. A whole new set of retrospective antipatterns awaits there, though (e.g., see Chapter 16, Peek-A-Boo, and Chapter 24, Dead Silence).
Another solution to avoid always talking about the same issue is to be strict in the voting process—for instance, by allowing only one vote on one subject from the outer ring, the soup, thus focusing on the issues the team can actually do something about.
As an alternative, you can ask the team how they can make the issue in the soup worse. If they can make it worse, they can also make it better, which shows they have some influence. This approach is called paradoxical intervention and is used in therapy and coaching to make people aware of their free will. It is often dismissed as reverse psychology, but where reverse psychology is used to manipulate people into doing what the manipulator wants them to do (by proposing the opposite), paradoxical intervention is meant to support the person’s ability to make choices by making them aware of the power in the situation.
I sometimes use an approach like this in my computer science teaching when the students have no idea what to do in an assignment. I ask them what they definitely should not do, and then we can start a discussion from there, because when they know what would not work, they can move toward what will work. It kicks their brains out of the deadlock they are in.
If the retrospective is online, it is not practical to do the Circles and Soup activity on a whiteboard. I often prepare the activity in a diagram and send everyone a link to it. Then, all the virtual Post-it Notes can be copied to that diagram and divided into sections, or else one note representing each group of Post-it Notes can be added to the Circles and Soup diagram.
In one team, the testing was an issue. The team wanted automated tests of the entire system, and they wanted to buy testing software cooler than Cucumber or perhaps assign a person exclusively to operating Jenkins. Management did not see the point of spending money on new software, and at every retrospective, at least 5 minutes were spent discussing the issue. Now, it is not an uninteresting issue to discuss, but when nothing can be done about it, time is better spent figuring out how to learn to live with this fact.
Once we tried the Circles and Soup exercise, the team understood that this was indeed one of the issues that are better treated as a fact of life and that time was better spent discussing alternative solutions. The team invited the manager to the retrospective to try to make management understand how big an issue testing was and what impact it had on agility, speed of development, and time to market. Unfortunately, the manager did not understand the problem, and the team decided to learn to live with it.
In the end, the team members decided they could build the tests themselves in Python, little by little, and get the tests exactly right, so they would no longer be afraid to change the code. They could do it without management’s approval to spend more money on the testing framework. Obviously, their extra work also had a cost, but this one could be hidden from management.
Of course, the whole issue was a symptom of a larger problem: the team’s relationship with management was poor. This relationship could have been improved by better communication, understanding, and respect between the team and management. In an ideal world, the team would not feel the need to hide things from management in order to do their best work, but sometimes the world is not ideal, and we have to make do with what we have.