Preface – Retrospectives Antipatterns


This Book Is for You

I have wanted to write this book for you for a long time. Actually, I have worked on it for so long that it has become a running joke between my family and friends.

I imagine you sitting on the sofa in the evening, frustrated with all the things that you experience as a retrospectives facilitator, and you want to know that someone shares your pain. If that is the case, this book is for you. I am about to tell you about all my mistakes and how I saw them repeating themselves to an extent that enabled me to write patterns about them.

Don’t be discouraged by my describing them as antipatterns: each has a solution as part of the antipattern description as well. Most of the solutions entail planning things differently the next time around; for example, I might give you ideas on how to remember to explain the reason for an activity. But there are also some real-time solutions that can be applied spontaneously in response to events during the retrospective—for example, ideas on how to encourage people to talk when they are silent.

When reading this book, you may notice that most of the antipatterns I describe, in the setting of a retrospective, could be found in the wild among other types of meetings as well. I would claim that the solutions described in the antipatterns could hold for whatever type of meeting you are facilitating. Because you do have a facilitator for all your meetings, right? Jutta Eckstein, in Retrospectives for Organizational Change (2019), also made the supported claim that the structure of a retrospective can be used in more settings than the cyclic team check-in that my context describes. She describes how retrospectives can also help you implement an organizational change on a much larger scale than the Scrum team we often relate the concept of retrospectives to.

If you are very new to all this facilitation business, it might be a good idea to read my book, because then you will be aware of all the challenges you might run into. On the other hand, who are we kidding? We almost never learn something before we need it, so you will need to make mistakes of your own before you can start to appreciate this book. Reading it now might only give you a laugh: “Did she really do that?” “What on earth made her think it was a good idea to say that?” But a good laugh is important, so there still might be value in it for you.

How the Book Came to Life

At the beginning of this millennium, I was a co-organizer and program chair at the JAOO Conference (now known as GOTO) in Aarhus, Denmark, where Linda Rising was an invited speaker. Among many things, Rising is the coauthor, with Mary Lynn Manns, of Fearless Change (2005), and she introduced me to Norm Kerth’s seminal book Project Retrospectives: A Handbook for Team Reviews (2001). I always enjoy listening to talks by Rising, but this one was special. The idea of retrospectives intrigued me, and I could see how they could be very useful to a lot of the teams at our clients’ organizations as well as teams in our own company. Reading the book after the conference did not discourage me, and in 2007, I started facilitating a few retrospectives.

The next step in my journey was to attend a course about facilitating retrospectives with Diana Larsen as teacher. This really opened my eyes to the possibilities and the challenges. I was lucky enough to assist Diana in later courses in Denmark, and as a teacher you learn even more than as a student. Ever since, I have been fascinated by the thought of helping people and teams reflect and learn. I started facilitating more retrospectives, first for my colleagues in the IT industry and later in other companies and settings. In the last 10 years, I have facilitated hundreds of retrospectives in dozens of organizations and delivered talks on retrospectives at conferences, geek nights, and, frankly, wherever people didn’t get a chance to run away.

I read many books and articles and watched numerous presentations, both online and at conferences. I learned, of course, a lot of activities, but I soon understood that being a good retrospective facilitator is not just about knowing which activities to use—there is much more to it. I spent some time learning about body language, and The Definitive Book of Body Language (Pease & Pease 2004) gave me many insights about the importance of eye contact, handshakes, and the effects of positioning yourself in relation to other people in different ways. I drew inspiration from numerous books that were not directly aimed at facilitating retrospectives; see the References section at the end of the book.

Prompted by my husband’s reminder of my poor memory, I kept notes over the years on what I saw and heard while facilitating retrospectives. I noted in a little black book the techniques I tried, what worked, and what didn’t work to help teams make forward progress and avoid getting stuck in a rut. If I improvised a way of redirecting a discussion that was going around in circles, I wrote a few sentences on it. When a group of developers needed a prod in the right direction to keep their meetings constructive and useful, I used the little black book to remind myself what I had already tried and whether it worked. If I invented or stole a silly game or an exercise that got people moving when their minds and bodies were weary from sitting and talking, I jotted it down. The retrospectives in these notebooks to date add up to 296 retrospectives facilitated for 68 different teams in 27 different companies, and I know that I did a lot before I started taking notes.

When I started using the notebook, it proved helpful not just for reminding me about what I had done that worked or did not work but also for following up on experiments a team may have decided on in previous retrospectives. I also wrote plans A and B for each retrospective so that I had all my plans in one place and could get inspiration from my earlier work. Some people might rely on their memory for past successes and blunders, but that is not an option for me. When I started facilitating online retrospectives, I used online tools and initially forgot to make use of the notebook. After some less-than-successful online retrospectives, I learned that the notebook was equally useful in an online retrospective because it gives me a quick overview and helps me remember.

This book, which I started writing in October 2013, is a distillation of my little black book—or rather, books. At least it’s a distillation of the bad parts, because this is a book of antipatterns. These are the traps people have fallen into, the mistakes I’ve made, and my best tips for getting out of the traps and fixing the mistakes. Facilitating retrospectives is never the same twice; if it is, then that’s an antipattern in itself. I never want to stop learning how to make meetings more useful and how to get teams to work better together. I also take great pleasure in showing skeptical software developers, who just want to be left alone to type in code, what they can gain from communicating with their colleagues for a small part of their working week.

Although the process of learning never ends and I am still learning, I want to share with a wider circle what I have learned so far. A lot of great material can be found in books and online about how to facilitate a good retrospective, but over the years, I have seen many people struggling with the same problems. That’s why I decided this book should be structured as a collection of antipatterns. Retrospectives are not easy to facilitate and are easily ruined, or at least made less efficient, and I think the time is ripe for a book of antipatterns. But don’t be put off by the negativity of antipatterns. Every antipattern contains a refactored solution that has worked for me and the teams I help.

Also, when you read the Refactored Solution sections in this book, remember to consider your own context before applying my proposal. As Diana Larsen used to say whenever I asked her what to do in a retrospective: “It depends,” by which she means that it depends on the context.


I assume that since you are reading this book, you are familiar with retrospectives and the role of the facilitator. If you need a refresher, you could spend some time reading about retrospectives on the Internet and, of course, read Agile Retrospectives: Making Good Teams Great (Larsen & Derby 2006).

I have added a lot of info boxes in the book to explain concepts that you might not know about or have forgotten. Feel free to skip them if you are already aware of what the different concepts cover.

What Is a Retrospective?

A retrospective is a chance for a team to reflect and learn from the past within a structured meeting. The main aim is to inspect the situation and adapt to the reality. Inspect and adapt is the core of any agile process and was first popularized with the Japanese word kaizen in The Machine That Changed the World (Womack, Jones & Roos 1990). To get a true inspection and be able to adapt to a situation, we need to create an atmosphere of trust in which people can share what they have experienced. The facilitator makes sure that every voice is heard in some way and that the team decides together what to spend time discussing or doing cause analysis on. The outcome of a retrospective is often a few experiments that the team can make in order to improve how they work. Or, as Larsen and Derby (2006) put it, retrospectives are about “making good teams great!” A retrospective is also a time to share with your team how you have experienced different events since the last retrospective and to gain a clear understanding of each other. As my late father used to say, “To understand everything is to forgive everything.”

The Five Phases of a Retrospective

Among the various definitions of retrospectives, Agile Retrospectives (Larsen & Derby 2006) describes the life of a retrospective as five phases:

  1. Set the Stage: The facilitator creates an atmosphere of trust, makes sure everyone’s voice is heard, looks at earlier experiments, defines the theme for the retrospective, and manages any other tasks necessary to start the retrospective.

  2. Gather Data: The team gathers data (on experiences, events, tests, sales, etc.) for the time that the retrospective is focused on.

  3. Generate Insights: The team looks behind the data to find the stories and the causes behind them. This phase can be done as a free discussion or a cause analysis.

  4. Decide What to Do: The team decides together what experiments to carry out to improve the way they work together.

  5. Close the Retrospective: The team decides who is responsible for following up on the experiments. The facilitator wraps up what happened and perhaps provides an evaluation of the retrospective if he or she feels it would be valuable—retrospective over the retrospective.

Often, I hear people claim that for short sprint retrospectives, it does not make sense to go through all five phases. But that way of thinking is exactly what leads to premature decision making, as described in depth later in Chapter 1, Wheel of Fortune.

What Is a Pattern?

A pattern is an abstract solution to an often recurring problem. Patterns are a means to disseminate experience in a literary form. Their names make up a common vocabulary for design, programming, or whatever domain for which the patterns describe solutions. A pattern can be a way to describe how things are done in an organization. A pattern contains a description of the context and the forces that define the problem you need to solve, the pattern solution, and the benefits and consequences of applying the pattern. A pattern also often refers to other patterns, because the consequences could be helped with a solution found in another pattern.

Figure P.1 The elements of a pattern

The concept of patterns was originated by the building architect Christopher Alexander and his coauthors in A Pattern Language: Towns, Buildings, Construction (1977). Just over a decade later, patterns were introduced for use in software by Kent Beck in a Smalltalk Report article, “A Short Introduction to Pattern Language” ((1993) 1999), with a focus on communication. Two years later, the concept was made popular by Design Patterns: Elements of Reusable Object-Oriented Software (Gamma et al. 1995), now known as the GoF book because the authors became collectively known as the Gang of Four.

When working with patterns, such as the Observer, Composite, and Strategy (Gamma et al. 1995), it is useful to refer to the names of patterns instead of having to explain a design or concept from scratch. Patterns are effective because of the way the brain works with cognitive patterns and cognitive automation. When you learn something, the details of that new knowledge are “glued” together in your long-term memory as a cognitive pattern. Together with the cognitive pattern, which helps you recognize the situation as a situation in which you have learned how to act, the cognitive automations, or how to react to the pattern, are also drilled into the brain. My former manager Michael Caspersen, who taught me almost everything I know about learning, includes many examples of and references to cognitive patterns and cognitive automations of the brain in his PhD dissertation (Caspersen 2007).

My PhD dissertation (Cornils 2001)1 focused on software patterns, and I have noticed that I always see patterns in things, which is not uncommon among humans.

1. Observant readers will realize that the name on my dissertation is not the name on this book. It is the name of my first husband, which was also my name at the time. Incidentally, this is also an antipattern: Do Not Change Your Name. At least not after publishing.

What Is an Antipattern?

An antipattern is a way to describe experience. The antipattern as a concept was first named and described by William J. Brown and his coauthors in AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (1998). It is a description of a solution to a frequently occurring problem in which the consequences outweigh the benefits.

The antipatterns in this book are the result of a facilitator not knowing better or not having the time or opportunity to do the right thing. Maybe the solution worked once for the facilitator in another group because the group members had a different way of communicating or knew each other better, but then it unexpectedly did not work in a new context.

I set the scene of antipatterns by giving you two examples of antipatterns. The first is an old one that led to a famous disaster. Late in the evening of April 14, 1912, the RMS Titanic hit an iceberg, and in the early hours of April 15, she sank, killing more than 1,500 of the 2,224 people on board, both passengers and crew. To understand why the ship sank, you have to look at a number of small things that, together, led to a disaster. The thing I choose to focus on is the antipattern you could call “following orders from an uninformed superior.” If you look up superior orders on Wikipedia, you find, “Superior orders, often known as the Nuremberg defense, lawful orders, just following orders, or by the German phrase Befehl ist Befehl (‘an order is an order’), is a plea in a court of law that a person—whether a member of the military, law enforcement, a firefighting force, or the civilian population—not be held guilty for actions ordered by a superior officer or an official.” This antipattern has been identified in numerous places and times, and also, as it happens, in the middle of the tale of the Titanic.

The two wireless radio operators on the Titanic worked for the Marconi Wireless Telegraph Company. The operators’ orders were to relay passengers’ messages to and from friends and family on land in order to demonstrate the wireless communication service provided by the Marconi Company. It was also a factor that the company was paid for every message to and from the passengers, and thus their income increased by prioritizing them over the ship-to-ship courtesy messages. Almost from the beginning of the voyage, they had received warnings about icebergs and passed most of these messages to the bridge. Unfortunately, some of the messages sent to the Titanic were lost because the radio operators focused on following orders from their company. Their superior was the owner of the wireless company, not the captain.

This explains why, when at 9:40 p.m. the Mesaba, a ship sailing in the same waters as the Titanic, sent a warning of an ice field, the message never reached the bridge. At 10:55 p.m., another nearby cruise liner, the Californian, messaged that she had stopped after becoming surrounded by ice, but one of the radio operators on the Titanic scolded the Californian for interrupting him, since he was busy handling passenger messages. Consequently, the captain was not warned about the ice situation being worse than expected, and thus he continued to sail at full speed. It was not until 11:40 p.m., when an iceberg was spotted from the crow’s nest, that the ship altered its route. The bridge crew started to turn the Titanic, but since she was a large ship sailing at high speed, it was too late. The side of the Titanic scraped along the iceberg, and the ship ruptured. We know how the story ends.

Often, a pattern in one context can be an antipattern in a different context. In the case of the Titanic, for example, the wireless radio operators were obligated to follow the orders of their superiors. However, had they known that the context had changed, that the ship faced an emergency, they would not have followed orders blindly—to do so would have constituted an antipattern.

Patterns also can become antipatterns over time, as technologies and processes change and improve. When a good solution is replaced by a better solution, the original solution can come to be viewed as a bad solution to a recurring problem.

The second example is the Microservices pattern, which is a design described by Martin Fowler and James Lewis (2014) whereby developers create a set of small services, each with its own functionality. The Microservices pattern proved to be maintainable, flexible, and resilient in software architectures, and it was hailed as the best thing since sliced bread (and design patterns). This pattern promoted the development of independently deployable, reusable components, enabling developers to create scalable systems built with microservices. The success of these systems led to the conversion of many monolithic systems to microservices architectures.

What happened then was what sometimes happens with patterns: the pattern was overused.2 Microservices can have negative consequences if the organization lacks the expertise required to maintain the system, a domain that would benefit from this implementation, or well-defined boundaries between the services. Increased complexity is a major consequence of a microservices architecture, and in the wrong circumstances, the system becomes a more complex monolith instead of a suite of smaller, well-defined microservices. All the expected benefits, such as scalability, independence, and reusability, are lost, and if used in the wrong context, the Microservices pattern becomes an antipattern. The context in which you use a pattern is important, and there will always be a context in which the pattern solution does not apply, resulting in an antipattern.

2. The Singleton pattern from the GoF book is a brilliant example of pattern overuse.

Figure P.2 A pattern becomes an antipattern when applied in the wrong context

An antipattern described correctly contains a general description, a list of the factors that led to the symptoms and how to recognize them, the consequences of the original solution, and a refactored solution that describes how to solve the current problems or at least how to do better next time.

All patterns have consequences. In some situations, it is a good idea to use a particular pattern, and in others, the same pattern becomes an antipattern. It is important to understand the context-dependent implications when you want to use a pattern. This helps you get the full picture, including the side effects of the antipattern solution. Like a pattern, an antipattern is not some abstract theory a person has invented but a series of causes and effects that he or she sees in often-recurring bad solutions.

You should read this book to learn to recognize antipatterns within retrospectives as (or perhaps even before) they happen to you. My goal in writing Retrospectives Antipatterns is to help you avoid making the same mistakes I have made so many times.

As an experienced retrospective facilitator, you may notice that you already know a lot of these patterns and how to deal with them. The added benefit of this book is that now you have a vocabulary to discuss it with other people, and it might be easier for you to recognize when you find yourself in an antipattern. If you share them with your colleagues, their memorable names can help to make you aware when you or your team is slipping into a Wheel of Fortune or Prime Directive Ignorance.

Lastly, you could read this book for the schadenfreude3 because, as one of the authors of the original antipattern book, Antipatterns: Refactoring Software, Architectures, and Projects in Crisis (Brown et al. 1998), said at a presentation when that book was published, “[One’s own] happiness is good, but the misfortune of others is better.”

3. Schadenfreude is a German word meaning that you take pleasure in other peoples’ pain.

How to Read This Book

The Octopus

You might wonder what an octopus has to do with retrospectives. The short answer is: nothing. But that is just the short answer.

I got intrigued by octopuses when I learned about their intelligence. They can learn tricks by watching other octopuses being rewarded for learning tricks without even getting a reward themselves. They can crawl out of an aquarium and through a tiny pipe that leads to the ocean. They can climb out of an aquarium, get down on the floor, cross the floor, mount another table, enter another aquarium, eat all the fish there, and then go back to their own aquarium as if nothing happened.

Most of all, I am stunned that 60 percent of an octopus’s brain is in its eight legs, divided into eight individual little animals, almost, each with its own will and yet all working as a whole with the rest of the octopus in a synergy that is unique in the animal kingdom. I see a team with a facilitator at a retrospective as an octopus: the team and facilitator work together toward a common goal while still being individuals, with individual focus and strengths.

For every antipattern, there is an illustration with an octopus that captures the essence of the antipattern. In the antipattern In the Soup, the team works together to lift a weight that is still too heavy, because the problem they are trying to solve is In the Soup of things they cannot change but just need to accept. In Prime Directive Ignorance, the team starts blaming one person instead of trying to find the faults in the system. In the Disillusioned Facilitator, the team mocks the facilitator for trying out activities they find ridiculous.

The Literary Form of Antipatterns in This Book

Based on the literary form for antipatterns found in Antipatterns (Brown et al. 1998), I have decided on a specific form to make it easier to read the antipatterns. As you will see, this form fits better with some antipatterns than with others. For example, sometimes the symptoms are obvious, and other times they are subtle and worth describing in detail. For brevity, I have left out the section on forces that you would normally see in a pattern. In my literary form, I have folded the forces into the context and related context descriptions. Forces could be, for example, haste, eagerness to be heard, or lack of people.

Name: The names of patterns are important because names allow you to extend your vocabulary about retrospectives and enable you to communicate efficiently with others about those patterns. An interesting thing about giving something a name is that the name can encompass a large set of concepts, processes, and conditions in a succinct way that organizes information so that your brain can quickly access all of the elements associated with that name.

Context: This book is written as the learning journey of a retrospective facilitator from a Danish company. The story and the people will be introduced later, but for now it suffices to know that every antipattern will include a description of the context in which we find the antipattern in our story.

General Context: This section covers the environment you will be in if this antipattern occurs, a description of what may have led to this problem, and the urge to go for the antipattern solution. This is a more generic way of describing the situation in which you may find yourself tempted to implement the antipattern solution.

Antipattern Solution: This section explains the chosen path based on the problem described. The antipattern looked like a solution at the time, based on education, earlier experiences, time constraints, lack of courage, or simply orders from above. It might have been the right solution if it were not for the negative consequences in this context. If you are aware that you can end in this situation by choosing an antipattern solution, you might avoid making some of the numerous mistakes I have made. The antipattern solution is not to be confused with the refactored solution.

Consequences: All solutions and decisions have consequences. In the original book about design patterns (Gamma et al. 1995), they were listed as positive and negative consequences, and depending on context, one might outweigh the other. In antipatterns, the point is that the antipattern solution might fit well in another context, but in this context, the negative consequences are much larger than the benefits. I usually say that this listing of consequences is what makes patterns differ from mere methods or recipes found in other books.

Symptoms: Symptoms are the indicators enabling you to see that a particular retrospectives antipattern is occurring. Symptoms might include comments you hear either outside of or during the retrospective, behaviors you observe, moods you sense, and so on.

Refactored Solution: The refactored solution suggests how to improve the current situation so that you and your team are gaining more benefits than negative consequences. In some of the antipatterns, you will learn that it is not possible to implement the refactored solution once the situation has already arisen, and what you gain from such an antipattern is merely an awareness of how to avoid it next time.

Online Aspect: For some of the refactored solutions, there are differences in how you would overcome the challenges in online and offline settings. A growing number of the retrospectives I facilitate are online, so I share my experiences with this medium as well.

Personal Anecdote: In this section, I tell of my own experience in sighting the antipattern. Sometimes I found a way to refactor it while it happened, and sometimes it was a lesson learned for the next time.

Outline of the Antipatterns

Structural Antipatterns

Structural antipatterns describe problems with the structure of the retrospective, such as how the activities are chosen, how the flow of the communication is facilitated, and where a change in agenda might solve the problem either at the present retrospective or at the next retrospective. These are the structural antipatterns:

Wheel of Fortune …in which the team jumps to conclusions in the retrospective by solving symptoms instead of problems, and the facilitator makes the team members spend time on finding the causes behind the symptoms

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

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

Overtime …in which the team gets sidetracked at the retrospective by talking about one development that is not the most important for the team as a whole, and the facilitator helps the team get back on track

Small Talk …in which the team members spend time on small talk in small groups instead of focusing on sharing and learning, and the facilitator changes the activities to make them work together as a team again

Unfruitful Democracy …in which, to the frustration of the minority in the team, democracy is used to decide what to discuss and what to do, and the facilitator finds other ways of deciding that makes everyone happier

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

Political Vote …in which the team members wait until the last moment to vote in order to game the system, and the facilitator finds a way to make the voting system more fair

Planning Antipatterns

Planning antipatterns describe problems with the planning of retrospectives. Whom do you invite to a retrospective? Who should facilitate the retrospective? When should you have a retrospective? How much time should you set aside for it? When you find yourself in a planning antipattern, you cannot change the current retrospective, so you need to be aware to plan differently next time.

Team, Really? …in which the borders of the team are blurred, and the team members all help each other figure out who should attend the retrospective

Do It Yourself …in which the facilitator is wearing several hats, which is suboptimal for both the facilitator and the retrospective, and the team finds other facilitators to take over at times

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

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

Disregard for Preparation …in which the facilitator initially misjudges how much preparation an online retrospective requires and later learns how to prepare for it wisely

Suffocating …in which team members get tired and hungry and unfocused during the retrospective, and the facilitator makes sure to feed them and give them oxygen so that they can concentrate a bit more

Curious Manager …in which a manager is curious about what happens at the retrospectives and wants to listen in on them, and the facilitator, in a nice but firm way, says no to the manager

Peek-A-Boo …in which team members will not show their faces on the video in an online retrospective, and the facilitator learns why and finds ways to make it safer for people to show their faces

People Antipatterns

People antipatterns describe problems with the people in the retrospectives. You often cannot anticipate these antipatterns because they can occur quite suddenly. Knowing the people will help you be aware of these antipatterns, and the refactored solutions described for these situations can help you navigate out of or around these antipatterns.

Disillusioned Facilitator …in which the team mocks the facilitator for using ridiculous activities, and the facilitator explains why the activities are useful

Loudmouth …in which a team member needs to hear him- or herself all the time, at everyone else’s expense, and the facilitator applies various tactics to ensure the rest of the team is heard

Silent One …in which a team member chooses to be almost completely quiet, and the facilitator applies various tactics to make sure the Silent One is heard

Negative One …in which one team member’s attitude has great negative impact on a retrospective, and the facilitator shields the other team members from the negativity

Negative Team …in which the team wants to talk only about the negative things because they think these are the only things they can learn from, and the facilitator shows them that a focus on positive aspects can be equally valuable

Lack of Trust …in which the team members do not trust each other enough to share anything of importance in the retrospective, and the facilitator helps them build that trust

Different Cultures …in which the assumptions the facilitator or the team members bring from their own culture are preventing them from seeing how the retrospective is experienced by others, and the facilitator finds ways to make them more aligned

Dead Silence …in which the team members are completely silent, often in an online retrospective, and the facilitator uses various tactics to hear their opinions despite their reluctance to participate