Chapter 7 Nothing to Talk About – Retrospectives Antipatterns

Chapter 7 Nothing to Talk About

. . . in which the team believes it has become so good that it doesn’t need retrospectives, and the facilitator shows the team how it can learn to keep improving

Context

The team is doing really well. The team members like working in an agile way, and their work product consistently adds value for users. The past two retrospectives have not shown any problems to deal with, and all Post-it Notes have been green except for a few about bad weather (it is Denmark, after all). Sarah overhears Rene and Andrea talking about whether Sarah expects them to invent problems.

It seems there is no longer a need for the retrospectives, since everything is going well. Sarah urges the team to think of issues that need to be addressed, but to no avail. Although she is frustrated, Sarah must agree with the rest of the team that perhaps the retrospectives are no longer useful.

General Context

I have seen this pattern of the life cycle of retrospectives in almost every organization and team I have introduced retrospectives to: first, the team might find the retrospectives to be a waste of time—until they learn how helpful and efficient (and fun) they can be. Then comes a period when they find a lot of things to talk about during the retrospectives. It feels good to do something about the problems in the teamwork, the communication, the technology, or the system they work on. After some time, though, the team “runs out of problems.” Discussions revolve around the same issues, and the retrospectives become stale and useless. Routine has set in, and the retrospectives become just another meeting that people want to be done with.

Antipattern Solution

The obvious solution to this is to ask every time a retrospective is planned whether the team members have anything new to talk about, and if the answer is no, the retrospective is dropped.

Consequences

To understand the consequences of missing out on retrospectives, first look at the expected benefits: a shared story about what has happened or is happening, a way to let off steam when something is subpar, and a shared decision making about what to do next. The personal factors are also important in retrospectives. This is often when you are all together to have a laugh, share feelings about various issues, and learn how to help each other or yourself. Facilitated in the right way, retrospectives can help you learn and grow as a team. Often, it is the one opportunity for a team to go beyond the obvious and look at the deeper issues. As J. P. Morgan said, there are two reasons for every decision and every action: the official reason and the real reason.

Symptoms

You hear on the grapevine, “We do not need the retrospectives anymore,” “There is nothing to talk about,” or “We are a good team now—no need to waste time on inventing problems.”

Refactored Solution

As suggested by the subtitle of Diana Larsen and Esther Derby’s book (2006), Making Good Teams Great, retrospectives are useful for all teams, not just for teams that are dysfunctional in some way. We can always get better at what we do: we can go from good to great.

World-class skiers still try to improve how they ski: they continually inspect what they do and adapt their technique, their sleep, or their food patterns according to what they find. Even if you go to the dentist to get your teeth cleaned or to a mechanic to get the wheels on your car balanced, you still have to get it done again on a regular basis. This is what I sometimes say to a team that has started the part of the retrospective journey where they believe they no longer need retrospectives.

And then I introduce something new to their retrospectives. I try a new kind of retrospective, such as a positive retrospective or a team radar retrospective (see Figure 7.1), or I make a futurespective that will show what they fear or what they hope will happen. As described in the Negative Team antipattern (Chapter 21), the team can learn not only from the positive aspects of an issue but also from the negative—which good practices can be made even better.

Figure 7.1 The team radar retrospective with four topics

Another useful exercise is The Ship (Figure 7.2), which can also be a good way to try something new in a retrospective.

Figure 7.2 The Ship retrospective

Another alternative is to ask the team what the worst-case scenario is or how they would work if they had less time, more time, fewer people, more people, and so on. Try to set up another worldview for them and see what they can come up with. Usually, when they cannot see what to change in order to improve, it is because they are so used to the way things are that they have trouble imagining a different situation for the team.

Some teams have learned only to look at their communication, cooperation, and process in the retrospectives, and while these considerations are important, hard data can also be worthwhile to look at in the Gather Data part of the retrospective. Hard data might include burndown charts, regression test overviews, peer review statistics, user feedback, and so on.

Choosing a theme for the retrospective can also be a way to focus and dig deeper into a particular subject. The theme might be a specific release, the test strategy, how we learn as a team and individually, the architecture, or whatever could be interesting for this team.

Sometimes you can allow yourself to play a slightly more active role in the retrospective. For instance, when I hear questions and comments such as “Why don’t we just get better at estimating timelines for tasks? Then we don’t need to talk so much all the time—we just check in when the work is due to be finished,” or “Do we have to discuss the things that go well? Can we not just focus on the things that are bad?” I like to sometimes raise questions about how the team members really want to work. Do they believe in agility? And humanity? And what are their aspirations with this team?

You can also use one of the assessments, such as Agile Fluency, to make the team aware of how they work with respect to agile methods, standards for code quality, or team happiness. Then you can start a discussion about where they want to be or where they thought they were.

The point of this refactored solution is to support them in finding ways to improve every aspect of the team and their work, if only in small ways.

Online Aspect

If the retrospective is done online, all the same points apply. The only difference is that it is harder to change the agenda of an online retrospective, so you might not be able to change this antipattern when you encounter it, but you will be able to plan for it for the next retrospective.

Personal Anecdote

As mentioned previously, I have seen this particular part of the retrospectives life cycle with numerous teams. With one particular team, it was hard for me as well to see how they could improve. They seemed to be doing everything just right and were very nice to each other while doing it.

I decided to prepare a retrospective around the word brave. The Set the Stage phase included a question on how each team member had been brave in the last month. I asked for just one example, and it could be at work or in private. (Naturally, we also went through the action points from the last retrospective and discussed whether the experiments had been successful, what they had learned, and what they would continue doing.)

In the Gather Data phase, I asked the team members to think about three things they would do if they woke up one morning and were ten times braver than usual. At least two of these items should be related to their work. You might argue that all three items should be related to their work, but I chose to include a possible private setting for two reasons.

First, this question can lead to some fun facts about each other, things they have always wanted to try but never dared. Fun facts can give the team a laugh and create a stronger bond among the group. Sometimes, the team members even find out they can help each other achieve a “brave goal.” One time, for instance, when someone said that he wanted to learn how to fly, another team member invited him to be her copilot next time she went flying.

Second, by leaving room in the question for people to think outside of work, you may encourage them to talk about an important personal wish that they wouldn’t ordinarily talk about at work but that nevertheless preoccupies their thoughts. When they share their important dreams or goals instead of trying to stifle their thoughts, they are less distracted and better able to focus on their work.

What came out of this exercise were answers as different as “talk directly to future users of the system in the nearest mall,” “try mob programming,”1 “ask for help when I run into something I cannot understand,” and “reeducate myself into a backend developer.” The next phase, Generate Insights, was about the stories behind their answers. If people wanted to, they could share the experiences that led to their list of what they would do if they were ten times braver. Had they already tried and failed? What happened when they tried? What made them try, and what did they expect to gain?

1. Like pair programming but with the whole team programming together following the rules written by Woody Zuill.

For the Decide What to Do phase, each person chose one idea to focus on or to help someone else focus on. And then I helped them figure out what a less frightening first step could be. The retrospective brought some new issues to the surface, because the team members were forced to think in a different way. It was easier for some than for others, but everyone in the room had some reflections about their normal behavior and whether something could be improved on a personal level.

Another aspect of this antipattern is that a team thinks right from the outset that retrospectives would be without value for them for a certain reason. I recently had somebody tell me that “agile coaches and scrum masters are getting nervous, because DevOps is happening everywhere around them. If scrum masters and agile coaches knew about DevOps, their whole perspective on retrospectives would change. DevOps is about measuring outcomes. In that case, the retro should focus on those outcomes, and many DevOps outcomes are technical: production incident rate, feature cycle time, mean time to recover/restore service. You can’t facilitate discussions about those things without knowing some DevOps.”

I really like statements like this one because it gives me a chance to explain why I think retrospectives are valuable. At least the person who made this statement will not implement retrospectives just for the sake of retrospectives. I replied to this comment that, first, even if people are using DevOps, they are still people, and they still have all the same people problems as everyone else.

Second, even though I know most people think about data gathering in a retrospective as gathering data about incidents and feelings, I also often see burndown charts, regression test results, recovery time, and reply time. I sometimes facilitate retrospectives where the team has decided to look only at technical subjects, which can work really well. Often, though, we talk about people issues as well, because of questions such as “How did we end with that response time?” or “Why did we get that regression test result?”

Third, I know I benefit from my technical background, and when people dive into technical discussions, I am able to shortcut them sometimes because I can understand what they say and know when they start repeating themselves. But many facilitators do not have that background and are still perfectly able to facilitate retrospectives. We, as facilitators, are supposed to be invisible and supportive of the discussions, and with the right amount of understanding of body language and team dynamics, it is still possible to facilitate a meeting about something you know nothing about.

Fourth, and this is specific to DevOps, I currently facilitate retrospectives for two teams, an operations team and a development team, who are in the process of being merged into a DevOps team. They have specific issues relating to their separate teams being merged into one. The dream, of course, is that they work as one team and that developers have not only sympathy for the operations but also empathy because they will learn what is done in operations—and vice versa for the people in operations. This poses some challenges when it comes to respecting each other’s knowledge and skill sets as well as creating a learning environment in which they learn from each other so they can make it possible to collect data and react to that data. There is a lot of tension between these two teams, and the retrospectives are helping them respect each other, albeit slowly.