Chapter 12 Get It Over With
. . . in which the facilitator rushes through the retrospective in order to “waste” as little time as possible for the team, and the facilitator finally decides that to have a decent retrospective, sufficient time must be allowed for discussions
All the different antipatterns that the team experienced made people wary of the retrospectives. Even Sarah lost her enthusiasm because of negative feedback and the uncomfortable situations that prior antipatterns put her in. Therefore, when the developers asked to shorten retrospectives from 1.5 hours to 1 hour to give the team more time for “real work,” she agreed.
After a few months, it was decided that half an hour would be enough time, and slowly but surely, the retrospectives became nothing more than standup meetings where people were paradoxically allowed to sit down. They would go into the same room (those who did not have better things to do) and take a round to say how things were. On those days, they would skip the morning standup meeting because they already had a status meeting. This antipattern is also described as the Rushed Retrospective by Stefan Wolpers (2017) in his blog post about sprint retrospective antipatterns.
As developers, we are often taught that the only time we are creating value is when we are writing lines of code. Thus, time for coding is more important than for other tasks, and time spent on retrospectives seems to be wasted. This can become a self-fulfilling prophecy if people spend so little time on retrospectives that they get very little out of them. Bad retrospectives are a waste of time, as discussed in Chapter 1, Wheel of Fortune, and sometimes having a bad retrospective can be worse than doing nothing, as described in Chapter 2, Prime Directive Ignorance.
If the retrospectives start to go stale, the team often decides to spend less time on them, and this shaving off of time continues until the retrospective has turned into a complaint session1 or a status meeting. In the end, the retrospectives vanish and the chance to learn and adapt diminishes. Also, the sharing of stories becomes more difficult, and the improvements that retrospectives promise can now happen only with a team that is communicating often and working closely together either in real life or with support for distributed work.
1. Also called “regrettospective” by Daniel Terhorst-North AKA Dan North.
The actual time spent on retrospectives is saved, but the time savings is offset by errors and miscommunications that could have been avoided through retrospectives. Additional time is lost when people leave, taking their knowledge and skills with them, because they are dissatisfied with the work environment or the communication within the team.
You hear people saying, “Let’s skip this retrospective. We are busy now—we can have one after the delivery,” or “Couldn’t we do this in a shorter time? How much difference can 15 minutes less make?” You may even notice that people attending the retrospectives are working on their computer or focusing on their phone, just waiting for something that is important to them.
How do you resolve this antipattern solution, that the retrospectives are unpopular and are slowly disappearing? When such a trend occurs without a specific decision or discussion beforehand, I tend to go back to the basics. Ask the team why they think they have retrospectives: Is it just because management says they must, or is it for the sake of the team? I also ask if they have ever gotten anything out of the retrospectives or been surprised by anything they learned about each other, the cooperation among team members, or the communication dynamics that influence their work.
These questions are difficult to answer because if they already had positive answers, the team would not try to eliminate the retrospectives.
As a facilitator, you might have to remind the team of experiments and of things that happened or were shared at a retrospective. You can do this only if you have taken notes about action points, experiments, surprises, or highlights at the retrospectives you facilitate. You do not need to take copious notes during the retrospective (you will not have time for that), but you can make short notes about big things and after each retrospective write down what they decided to try.
You could also restart the retrospectives with new activities, a new facilitator, perhaps an external facilitator, as described in the Do It Yourself antipattern (Chapter 10). Sometimes it helps to get management to back up the decision of having reflection with retrospectives. Norm Kerth once very wisely said to me: “You cannot sell retrospectives, nobody wants retrospectives. But you can sell solutions to the problems they already know about.” Of course, by sell, he meant “convince people that it is worthwhile.”
An assessment, such as the Agile Fluency diagnostic (Chapter 7, Nothing to Talk About), could also be used in this situation to enable the team to visualize where retrospectives might be most helpful.
Since this antipattern is about planning how long the retrospective should be, the difference between an online and an offline retrospective is not significant in this context. Bear in mind that because of the often short attention span of human beings, online retrospectives must be shorter than offline ones or should have a break or some break-like structure built in with time set aside for laughter. This time for breaks is often the first thing some people want to get rid of in order to save time for “real” work, and you might have to insist on keeping this extra time in the retrospectives. As in an offline retrospective, you have to convince the team that the time spent on retrospectives is valuable and that breaks are there for a reason.
I have often been in this Get It Over With antipattern. It tends to happen when the same facilitator and team work together and repeat the same activities over time. The retrospectives seem less rewarding and consequently are seen as a waste of time—or at least as a use of time less valuable than actual coding.
In one situation, I had heard a rumor that the team got very little out of the retrospectives. I decided to start the next retrospective by asking them what they expected to get out of these next 1.5 hours. From two members the answer was “nothing.” Had I been a less experienced facilitator or known these people less well, this answer would have freaked me out. Instead, it kindled my curiosity and my drive to make this a very good retrospective.
I made them very aware every time they decided to discuss or not discuss something. I also made sure that they had one to three actionable experiments with them when they left the meeting, that someone was responsible for making each experiment happen, and that a time frame had been established for each experiment. After the retrospective, I asked what the team thought they would get out of these experiments, and since the ones they had decided upon could be traced back to issues and challenges, it was an easy answer. In my experience, even the most code-driven developer can be won over if the retrospective is visibly valuable. As can be seen in Chapter 20, Negative One, the hardest critic can turn into your best champion for retrospectives.
For another team, I had been facilitating their retrospectives for years, and yet the feeling of not accomplishing anything crept in on them. For the next retrospective, I took all the experiments they had decided upon in the last 6 months and lined them up on the whiteboard, one Post-it Note for each experiment. Then I drew a figure on the board with some space for items that were done, some space for items that were now irrelevant, and a bigger space for items that were still relevant. In the space for the relevant items, I made a vertical line with “Long term” at the top for the long-term goals and “Action points” at the bottom for experiments that could be started today. See Figure 12.1.
The exercise with the team was now to go through all these Post-it Notes and figure out what category they should be in. Most were categorized as Done, and the team had a short talk about what they had gotten out of those items; even small things such as “say good morning every morning” turned out to have made a difference to the team. Some of the experiments that had not been done due to timing or forgetfulness turned out to be no longer relevant. We spent very little time on those. In the end, we arrived at some experiments they could try out immediately and some that were actually too big to be carried out as they were and needed a specific meeting to figure out the best way to achieve them.
In the debriefing after this activity, we talked about how even small changes can have a huge impact and how we should be more aware in the future of the need to make the experiments immediately actionable or to plan a follow-up meeting to slice them into smaller steps.