Chapter 11 Death by Postponement
. . . in which the team is so busy with “real work” that the retrospectives are postponed again and again, and the facilitator helps the team see how valuable these retrospectives are and that they are real work
In our little team, some problems arise. Some of the code committed to the version control system is not in good enough shape to be committed to the rest of the system. Later, tests and integrations fail and changes have to be rolled back, which means a setback not just for that code but also for the code that depends on it. Frustration starts to build up, and people are looking at the causes for the bad code. A few people start thinking that one of the team members, in this case, Peter, should work on simpler or unrelated problems. Team members become increasingly frustrated, but since they know there is an upcoming retrospective where they will be able to discuss the problems, they wait and abide.
At the next retrospective, the room almost explodes with blaming, and a lot of aggression is vented. The retrospective itself is immediately a success, since Sarah is able to divert the blaming into a constructive discussion of code quality and what it means for the system. The team comes up with experiments to make in the next sprint to achieve better code quality. Among these are standards and pair programming. But at this retrospective, no new problems are discovered and no news is shared. It is merely a focused discussion for that particular problem.
The team has learned that the retrospective is the venue for sharing incidents. They are happy with this arrangement, since it means they have a structured way to discuss issues. Also, many of the team members would rather not talk about things that go wrong, so postponing those discussions feels good.
After a period of time with regular retrospectives, teams tend to accept that retrospectives are now the setting in which to discuss problems, and so they do not want to “waste” time discussing problems during sprints. When something happens that angers or frustrates them, they simply try to forget about it until the next retrospective.
There are two major negative consequences of this antipattern solution. One is that solutions to problems are delayed if you have to wait for up to 3 weeks to solve them, and the issues that are arising may be symptoms of a larger problem that needs to be addressed right away. It could be that someone is getting too stressed to do his or her job properly or that the team is working in the wrong direction. Precious time is wasted waiting for the right time to address these issues.
The second problem is that if you postpone everything until the retrospective, you could end up with too many problems at the retrospective and consequently not have enough time to explore what was not known at the start. Some of the beauty and power in retrospectives come from seeing the whole picture or seeing it from someone else’s viewpoint. The sharing of knowledge and reactions to events are as important as the experiments you choose to make on the basis of the knowledge.
If the data gathering feels like an explosion with a single, or very few, subjects, this is a sign that we have entered Death by Postponement. If you work closely with the team during the sprint you may also overhear comments such as “Let’s discuss this at the retrospective” or “Here is a thing for the retrospective.” At the retrospective, you might notice that some issues are not being addressed because there are too many issues.
This antipattern is in itself a symptom of a problem: if a team waits for a facilitator to plan a retrospective before they start discussing important issues, then they are not a self-organized team. So, when you notice this antipattern as a facilitator, you might want to work on this issue with the team, even if they are not aware of it themselves.
A retrospective should happen every 2 weeks. When the time between the retrospectives is longer than that, it becomes increasingly hard to remember what happened and what you felt about it. Some teams, especially the ones that practice mob programming, have a retrospective each morning to see what they can learn from the day before. In those cases, the retrospective is naturally very short.
Some teams have retrospectives every 3 or even 4 weeks because that is the amount of time they choose to set aside for learning. Then the time between a problem occurring and a solution being found can get very long. Instead of waiting for a retrospective to discuss the issues that arise, address the problem when it occurs. You could, for instance, use a continuous retrospective timeline, as shown in Figure 11.1. This solution was described to me by Linda Rising, only then she called them real-time retrospectives.
This is an implementation of the retrospective activity Timeline, described in Agile Retrospectives (Larsen & Derby 2006). Since it is most effective if everyone is able to view it every day, it should be placed in the project room if possible. If not, then it could also be posted online. With a continuous retrospective timeline in the room, team members experiencing something that makes them happy or sad or angry can put up a Post-it Note when it occurs. In that way, you have a shared vision of what is going on with people during the sprint. It should be possible to add Post-it Notes anonymously, and someone should be responsible for keeping the timeline free of blaming, much like a moderator on social networks.
When a bunch of red notes accumulate together in a continuous retrospective timeline, it may be time for a conversation regardless of when the next retrospective is scheduled. In setting up the timeline, it is understood that anyone can call an immediate meeting or even a retrospective if he or she thinks the problem needs a more time-structured discussion. This solution has two benefits: (1) the problem is handled in a timely manner, and (2) there is time in the regularly scheduled retrospective for new issues to be dealt with.
I know companies that use this real-time timeline and are able to shorten the next retrospective because problems were addressed in an impromptu retrospective during the sprint. Most of the time, however, the retrospective proceeds as planned, since we often need some time to get into the right mindset to get something out of a retrospective.
For an online retrospective, I often set up the online document that I plan to use in the Gather Data phase right after the last retrospective. In that way, the team members can add items to the document during the time between the retrospectives, and everybody can keep an eye on what is happening. It is my experience, though, that you have to remind the team of the online document from time to time so that they remember to add items.
When I entered the room, I could immediately feel the elephant. This was a team for which I had facilitated retrospectives for about a year. Although it had not been so in the beginning, they now looked forward to retrospectives and saw them as an opportunity to vent, to share, to laugh, and to come up with experiments that would slowly but gently turn this great team into an awesome team. They were, in other words, really on board with the retrospectives.
We started the retrospective as usual, with a round of comments related to the sprint (sometimes the comments are unrelated, but that is not the point here), then we went through the experiments decided on in the last retrospective to share the status and find out if the experiments had achieved the expected result.
Sometimes this opening takes a long time, because people have experienced events in different ways, but this time it went really quickly. Two of three experiments had been performed; there had not been a chance to do the third, and I made a note of that in my little black book. Then it was time to gather data since the last retrospective. We used the Timeline, which is one of my personal favorites and also the one that this particular team wanted to use every third retrospective. They liked to try new things, but they also appreciated knowing some things in advance.
The timeline was the first place where I noticed the contours of the elephant in the room. Actually, looking at the timeline, everything was somehow connected to this elephant. Everybody had the recent change in management as a focus area. It turned out that the boss of their boss had quit the job (or had been fired—they did not know) a week ago, and they were all worried how this would affect them.
The last time this had happened was no more than 6 months earlier, and it had had really unpleasant effects on the team. Their immediate leader had been let go, and one of the team members had been transferred to another branch.
It was great that the team—all of them—wanted to talk about this situation, and it was great that they felt safe enough to share their worries. What I was not so happy about was that they had not felt they could talk about the change in management and possible ramifications without a retrospective.
I am always hoping that regular retrospectives strengthen the reflection muscle and that people start reflecting on a daily basis and changing what needs to be changed. To me, it is like waiting until Monday to start a diet: postponing does not improve the experience or the effectiveness.