Scroll down for a free chapter!

I have written a book about antipatterns for retrospectives, because I seemed to be making the same mistakes over and over. It all started at GOTO Aarhus in 2013, where I was asked to do a lightning talk with 30 minutes to prepare one. I decided to talk about antipatterns for retrospectives, since that was something I could talk about without preparing for long.

After this I started writing about them, and speaking about them.

It took me 7 years to write this book, mostly because there were long periods where I almost forgot about the book, but in 2019 I decided to cut down on my consulting work and focus on the writing.

The book is published by Pearson and is for sale e.g. on Pearson’s own page , or Amazon.com. The octopus illustration on the cover (as well as the other wonderful octopus illustrations inside the book) are made by Nikola Korać, who was able to make all the illustrations better than I even imagined them!

Things people have said about the book:

“I think this is a super important and wonderful book providing real treasures for retrospective facilitators.” Jutta Eckstein, author of “Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy”, “Retrospectives for Organizational Change”, “Agile Software Development with Distributed Teams” and more

The promised chapter from the book:

Prime Directive Ignorance

…in which the team members ignore the Prime Directive––”Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand” (Kerth 2001)––because they find it ridiculous, and the facilitator reminds them how important this mindset is for a successful retrospective

Context

For her next retrospective, Sarah has done her homework. Not only has she read Agile Retrospectives: Making Good Teams Great (Larsen & Derby 2006), she has also read Project Retrospectives: A Handbook for Team Reviews (Kerth 2001). She discovers that there is a lot to think about when planning and facilitating a retrospective, but luckily, Larsen and Derby’s book has made planning an easier task by proving suggestions for entire retrospective agendas.

With a planned retrospective ahead of her, Sarah is excited and a little bit worried. The thing she most worries about is how to present Norm Kerth’s Prime Directive (2001) to the developers, since she believes they might find it ridiculous. In the end, she decides to drop it.

Prime Directive

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. –– Norm Kerth

The last sprint had been a disaster with everyone working overtime and no one feeling good about the result. Well, almost everyone worked overtime––Peter had not. He went home every day at the usual time; he would sneak out thinking nobody noticed him and arrive late in the mornings. There had been some grousing about this by the water cooler and in the corners, and it was secretly decided that the retrospective was the place to deal with . Sarah and Peter were the only people who did not know of this plan.

At the retrospective, they looked at the data––the regression tests and the feedback from the demo with the users––and they put Post-it Notes on a timeline to share their experiences. It was obvious that Peter was being blamed for the team’s overall dissatisfaction. There were Post-it Notes with his name on the board, and he became even more silent than he usually was. Since there were so many notes, Sarah decided to read them all out herself, thinking it would take too long if they all had to read a portion. But there was also another reason Sarah chose to read the notes: as she read them aloud, she tried to avoid the Post-it Notes with Peter’s name on them. Everybody had already seen the notes, though, so Sarah’s effort to shield Peter was in vain. Peter left the retrospective in complete silence, and the rest of the team members felt unsure about what to do next. They had hoped that he would apologize to them or explain his behavior, but they had never really given him a chance to enter the discussions.

Timeline

In this activity, the facilitator prepares by drawing a timeline on the wall of the retrospective room. This can be done either by writing dates or events on Post-it Notes and placing them in a line or by actually drawing a line on a big whiteboard and adding the start and end dates. The team members are asked to think back on this time, from beginning to end. They will be given Post-it Notes in different colors, red for events that took away their energy (made them sad/unhappy/mad), green for events that gave them energy (made them happy/relieved), and yellow for events that puzzled them, for questions, or for events that are both good and bad.

Then the team and the facilitator look at the board and the colors and decide which parts to start discussing. For an explanation of why this discussion is important, see Wheel of Fortune. The purposes of using a timeline are that some people find it easier to have that framework and that a sprint or an entire project development phase can be seen as an overview with the colors indicating the happiness/energy at different times.

Sometimes, the occurrence of this antipattern is a symptom of another antipattern: Lack of Trust (Chapter 22). In these cases, the problem is deeper ignorance of the Prime Directive and cannot be fixed simply by emphasizing Kerth’s words of wisdom. The real problem in the antipattern solution for Prime Directive Ignorance is the lack of trust that makes it impossible for Peter to share what is going on with him and for everybody else to expect that he is doing his best under the circumstances he is in.

General Context

Kerth was the first to write about retrospectives, and he coined the term after they had been called postmortems for some time. He wrote the Prime Directive, and it has been the center of much discussion in the IT community:

Can we really, regardless of what we discover, understand and truly believe that everyone did the best job they could? Even if we made allowances for what they knew at the time, their skills and abilities, the resources available, and the situation at hand?

At the end of a project, everyone knows so much more than at the beginning. Naturally, we look back on decisions and actions we wish we could do over. This is wisdom to be celebrated, not judged and used to embarrass people. Adhering to the Prime Directive, we want to combat confirmation bias in retrospectives. If we are filtering information to accept data only that supports our preconceived opinions, we are missing a chance to learn.

The problem is that it feels awkward to follow this directive, because it is hard to really and truly believe that everybody else is doing their best when you know they are slacking or being lazy. One of the reasons that we find this hard is explained by the fundamental attribution error described in The Intuitive Psychologist and His Shortcomings: Distortions in the Attribution Process (Ross 1977). This error explains how we attribute flaws in the behavior of other people to internal traits, such as laziness, stupidity, and so on, instead of attributing it to the circumstances this person is in. As an example, if you are late for a meeting, you might attribute your tardiness to the problems you had with getting the kids to school or to the bus being late. But if someone else is late to the meeting, you might roll your eyes and think he or she is an irresponsible person, according to the fundamental attribution error.

In the IT industry, which is the one I have worked in the most, there is a focus on errors (bugs) and bad work (which carries legacy bugs and poor programming to future iterations). Maybe this focus on the negative exists because of the need for precision when working with computers, and perhaps this need attracts perfectionists to the IT trade. Perfectionism can be a good thing for most of what we do, but it is not helpful when we are trying to understand why things happened and find sound solutions to problems.

Antipattern Solution

Just forget the Prime Directive. It’s too touchy-feely for a logical bunch of programmers. As simple as that. Ignore it. Or, recite it with a mocking smile on your face, signalling that everybody can just forget about it. Go ahead with the retrospective and get on with the data collection.

Consequences

Your retrospective will now be like any other review session, where we, like most people, are interested only in finding a scapegoat to direct blame away from ourselves. Scapegoating is a common non-solution to problems, and you probably experienced it in childhood when your parents asked you and your siblings, “Who started it?” or “Who broke the vase?”

The consequence could be that participants bring all their assumptions and negative expectations to the retrospective instead of anticipating a chance to share and learn. They do not really listen to what others are saying because they already believe they know whom to blame. The retrospective can easily become a blaming and shaming session, where the people being blamed are afraid to share and in the end refuse to attend the retrospectives because they become too painful.

Symptoms

Team members are afraid to go to the retrospectives when something has gone wrong. They are not eager to learn to become wiser but instead are afraid of what might happen at the retrospective. People arrive in a defensive mood, armed with angry counterarguments to the attacks they expect and unwilling to explore the issues together.

Refactored Solution

Bring the directive to each retrospective, and start with it. I have found that some groups react negatively to the wording of the Prime Directive, and in those cases, I reword it but maintain the core idea that we should all look for the problems in the system, not in the people.

The Prime Directive should be seen as a way to think about , a state of mind to enter when you walk into a retrospective. It is a team thing to have a retrospective, so you should think of everyone as part of the team, or as part of a system, and find ways to improve that system. If you start out by thinking they purposely have not done their best, you will not have a fruitful retrospective.

Remember what Yoda said to Luke when Luke said he did not believe he could lift his spaceship out of the swamp: “That is why you fail.” Yoda succeeded, after some time, in putting Luke into the right mindset when he tried to tackle problems.

Had our Danish team entered the retrospective thinking about the Prime Directive, they might have learned that Peter’s wife was terminally ill, and that this was the reason he was not pulling his weight at work. Maybe Peter would have shared, had he felt secure and safe at the retrospective. Then they might have found something that Peter could do together with someone else or given him less work for a period while he figured out what would happen to him emotionally and financially as he went through this very difficult and painful part of his life.

It could also be that Peter was uncomfortable sharing this at a retrospective and needed a more private setting to share this personal information and its consequences. In any case, accepting that Peter was not to blame and acknowledging that the way the team worked together and communicated was faulty would have been a more likely and positive result had they focused on the mindset proposed by the Prime Directive.

Online Aspect

If the retrospective is conducted online, you can add the Prime Directive to the email that is attached to the calendar invitation. You can also have the Prime Directive on a poster behind your head as a constant reminder of it. You might also be able to send messages directly to the people you think are not following the directive to remind them about it without making them loose face in front of everyone else.

Personal Anecdote

Many years ago, in a retrospective not facilitated by me but for my team, something very sad happened. During the data gathering, one name was singled out on the board with some negative comments. The facilitator did not stop it, and soon a whole swarm of Post-it Notes about that person filled the board. Not surprisingly, this experience was unpleasant for the person in question, but it was about a behavior that everyone was tired of and that affected our work together. The facilitator allowed us to start talking about the different Post-it Notes on the board, what they meant, and the stories behind them.

The person in question started defending himself, but in the end, he stormed out of the room. We never got anywhere near understanding what actually created the behavior or what we could do collectively to help this person or at least learn to work around it. The time spent on that retrospective was more than wasted––it harmed us for good.

Another time, I witnessed something touching concerning a young man who had recently joined the team. I could see from the start of the retrospective that he felt really bad about something. It turned out that he thought he had done a disastrous job of working on the front-end of the system, taking too long, making mistakes.

But the rest of the team turned to him, when they realized how he felt, and gave him a veritable love-storm. They let him know that of course he needed time to learn about the system. In addition, they told him that because of his work, they had learned which parts of the system needed more documentation or even a rewrite. The young man was so happy and relieved, it almost brought a tear to my eye!