- 1.1 What Is a Retrospective?
- 1.2 New Year’s Eve Retrospective
- 1.3 The Retrospective Phase Model
- 1.4 Finding Activities for Each of the Phases
- 1.5 The Prime Directive
- Summary
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.3 The Retrospective Phase Model
If you were paying close attention in the preceding section, you might have noticed that we went through six phases during the New Year’s Eve retrospective, as illustrated in Figure 1-1.
)
Figure 1-1 The six phases of a retrospective
These form the structure of a retrospective and are based on the original phase model in Esther Derby and Diana Larsen’s book [5]. The model I describe here is an expanded form of Derby and Larsen’s, the big differences being that I introduced the “Check Hypothesis” step and extended the “Define Experiments” step to include hypotheses. I explain the reasons for this later in the book. In the following sections, I explain the six phases in more detail.
1.3.1 Phase 1: Set the Stage
The first phase of a retrospective should set the stage. This phase is very important because every participant has to be mentally “picked up” from somewhere else. If you leave out this phase, you run the risk of one or more participants being mentally absent from the retrospective as they are still thinking about the last piece of work they were doing before walking in. Preparing the ground serves to get all the participants’ attention and get them involved. Starting with a few words of welcome and thanking everyone for taking part is best. Then you as a facilitator briefly explain the reason for and the aim of the retrospective as well as the timeframe and the agenda. The agenda is important because, after all, we all want to know what we’re spending our time on.
The last step of the first phase is also very important. The aim is to create an atmosphere in which difficult topics can be addressed. Only in an atmosphere where even unpleasant things can be discussed is it possible to get to the bottom of things and to address the real causes of problems. Moreover, that is the basis for a successful retrospective. What happens in Vegas, stays in Vegas.
You create this atmosphere by establishing the rules for cooperation, or the “working agreement.” Some teams have already defined the values they have for their daily work, and in that case, you should use those values and simply remind the team of them. You might need to adjust a few values to the retrospective. The same applies, of course, if the team has already defined rules for collaboration. Many agile teams create a team charter at the beginning of their collaboration.
If there are no rules for cooperation yet, now is the time to define them. However, why are these rules so important? The following is a brief example.
Let’s say your colleague James has the habit of taking his laptop with him into every meeting. He uses the time in these meetings to answer his e-mails or surf the web. If you start the retrospective without clearly pre-established rules, he will probably do that same thing. It will annoy everyone, but no one will have the rules to point to and ask him to close the laptop. However, if the rules have been defined in advance, they can be pointed out at any time. Another advantage of having common rules for cooperation is that all the participants are responsible for observing them. This makes it easier for the facilitator to concentrate on the actual work of the retrospective.
Unfortunately, this is the phase of the retrospective that is most frequently skipped because people want to save time and get started right away. In my experience, taking a team through this phase has never been a waste of time. If the team has been working together for a long time, it often takes no more than five minutes. Five minutes
that minimize the risk of someone not speaking
that make sure that everyone feels they are in a safe environment in which to work
to get everyone present and let them clear their heads for this important meeting
Sometimes it can also be five minutes of fun. For example, you might ask the team: “If the last iteration were a car, what kind of car would it be?” All it takes is one or two words, and you get everybody mentally present.
As a reminder, in our New Year’s Eve retrospective, we set the stage by looking at the photos and videos from the past year. Believe me—it’s a lot of fun!
1.3.2 Phase 2: Check Hypothesis
The purpose of the Check Hypothesis phase is to review the hypotheses created at the last retrospective. Ideally, these hypotheses are created from the experiments chosen (see section 1.3.5). However, why is this step so important?
Let’s say that during the last retrospective you discussed the problem of very poor communication with the product management team. The product manager is hard to reach, and questions are only answered after major delays. At the end of the last retrospective, you decided on a measure to be taken: The product manager would now be available to the team for a specific time slot every day. This time would be for discussing current questions and getting answers, thus reducing delays to a minimum. The hypothesis that you connected to this experiment might have been as follows: “Current questions will now be answered in less than 24 hours.” This would be a real improvement on the recent situation, in which the team sometimes had to wait several weeks for a response.
After the stage has been set, the team checks the hypotheses. It turns out that the experiment was wrong. It seems that although the response time is getting a little better, it is still far from the 24-hour mark. So, the problem remains. In the further course of this retrospective, the team will, therefore, try to pinpoint the causes of this problem and then either adapt the current experiment or define a new one. During this process, it might discover, for example, that the product manager was never consulted about the new change and was simply told to implement it. Rather than motivating him to work more closely with the team, this just made him angry. Using hypotheses enables the team to work on a topic until the problem is either solved or reduced to a tolerable level.
This example shows that hypotheses are an important tool. Some teams merely check whether or not the measures chosen in the previous retrospective were actually implemented. Only a few bother to check whether those measures also had the desired effect. However, only by checking for the desired effect can you actually create improvement. This is certainly not a panacea, but it is effective in most cases. Hypotheses also help to make retrospectives meaningful and help you to stay focused on a topic instead of letting the discussion wander.
1.3.3 Phase 3: Gather Data
Now we come to the actual looking back invoked in the word “retrospective.” The aim of the Gather Data phase is to collect data on a clearly defined period from the past. This could be the last iteration (or sprint in Scrum), the period of an entire project, or even the last working day. The time between an event considered and the retrospective should be kept as short as possible. Your main goal in this phase is to create a common understanding of the period you are considering. Without this common picture, the participants might not understand one another’s perspectives and opinions and will tend to project their feelings onto others. To create a common picture, everyone gets the opportunity to present his or her view of things.
You start by collecting the hard facts. These facts can be anything that took place during this period, from meetings and decisions to personal experiences. Include everything that had and has a meaning for anybody on the team here. Numbers (measures) might also feature in this step; for example, the number of completed requirements, or the number of closed, open, and new errors. The more memorable the result, the better.
You could simply talk about all of these things, but including a visualization is much better. A visualization simplifies the recording of information and is indispensable, especially in the case of longer retrospectives. One example of a visualization is a timeline laid out on a wall, which allows you to see the temporal relationships between events (see Figure 1-2).
)
Figure 1-2 Gather data using a timeline
Although the hard facts are important, they are still only part of the story. Just as important are the personal perspectives that people have on the time being considered because these tell us which events are more important and which are less so. Collecting both facts and personal perspectives helps to focus on the issues that have most affected the team. At the same time, the emotional quality of these perspectives also reveals the situations in which people felt good. Knowing when people felt good gives you the opportunity to re-create this situation more often. A further reason to discuss emotional issues is that, though they have the potential to become a drain on energy and motivation in daily working life, they are often overlooked.
Only by talking to your team can you find out what is going on and put yourself in a position to address concerns, eliminate negatives, and strengthen positives.
Before moving on to the next step, take the time with the team to get an overall picture of the period you are reviewing. You can do this by having each team member present his or her insights, or by giving the whole team some time to reflect on the information you have collected (using the timeline, for example).
Reminder: In the New Year’s retrospective, we collected the data by sorting events into three categories:
What did I like this year?
What did I not like at all this year (or what made me angry)?
Thank you
Each of us then briefly presents the topic we’ve chosen. By using emotional words in the question, we set ourselves up to get a combination of hard facts and feelings. Experience has shown me that this phase of the retrospective should be varied very often. I will talk about possible variations in the chapters throughout this book. If you can’t wait, have a look at the later section 1.4.
1.3.4 Phase 4: Generate Insights
You use the Generate Insights phase to understand the context of the situation as well as possible causes and connections. You analyze the events collected in the previous phase and then ask, “Why did these things happen?” What you are looking for are insights into the fundamental causes of the events that took place.
After the first phase, this phase is the next most frequently omitted. Many teams skip this phase and immediately try to define future experiments without considering the possible causes of the current situation. This means that they only ever scratch the surface and that their measures will only treat the symptoms instead of dealing with the root causes. It’s like using pain killers, when you actually broke your leg. The pain will vanish for a short period of time, but because the root cause wasn’t addressed, the pain will come back. This is not a good idea because what might seem a promising path out of your problem often leads you straight back into it. On the other hand, carrying this phase out well provides you with a solid foundation for the next phase: define experiments and their hypotheses. Do not try to tackle all of your problems at once. Instead, choose the issues that the group feels are the most important. You won’t be able to solve all of your problems in a single retrospective. This phase is designed to help the team step back, see the whole picture, and start looking for the root causes. It doesn’t make sense to work on more than three topics during the next iteration, as these topics won’t be the only thing you have to work on, right? You need the insights gained in this phase to define reasonable and effective measures.
Remember, during our New Year’s Eve retrospective, every family member is allowed to choose the topic that is most important to him or her and which he or she would like to discuss at this stage. We currently use the “5 Whys” to look for causes. When our children get older, we will vary the technique we use.
1.3.5 Phase 5: Define Experiments
The first four phases have set up a strong foundation for the Define Experiments phase. You’ve created an overall picture and common understanding of the period under consideration and have also gained some insight into the various events that took place. At this point, most of the team will already have some ideas about what to improve or try out next. So the team’s next task is to choose one or two actions and to agree on how to implement them. This also ensures that the team will have the time to implement its decisions. After all, the daily workload still must be done. Trying to implement too many changes at once can lead to problems. It also makes it more difficult to tell later which experiments actually had an effect.
I use the word ‘experiments’ deliberately here. Nobody knows what will happen if you try something out. Although we may have an idea of what might happen (our hypothesis), no one can actually be sure. An analogy for this is a lab researcher who creates an experiment to test his hypothesis. Only at the end of the experiment will he be able to tell whether or not it actually worked. The most effective way to work with these experiments is to repeat your retrospectives at regular intervals that are as short as possible. This creates a safe space: An experiment that is going wrong will make less mess if you cut it off quickly rather than let it run rampant.
Just as important as the definition of the experiment itself is the definition of the corresponding hypothesis. You carry out experiments not (just) for fun, but because you think it will create an effect. The hypothesis allows you to determine the extent of an experiment’s effect in the next retrospective. So, hypotheses must be testable. A hypothesis such as, “This will lead to fewer errors in the software” is vague and harder to assess meaningfully. A better version of this hypothesis is, “The number of known errors in the software will be reduced to ten or less.” You must always consider how your hypothesis is to be tested. This is the only way to make hypotheses meaningful and to use them to define new experiments if the first proves unsuccessful.
Making the results of the retrospective visible to everyone is good practice. Agile teams, like a Scrum team, always include the defined experiments in the next planning session. The experiments chosen are considered part of the normal workload and are not extra tasks. That’s exactly how it should be. It is also important that the team is willing to carry out these tasks. Having a single person take responsibility for each experiment is best. This person does not have to carry out the experiment alone but is responsible for ensuring that action is taken. If nobody is assigned responsibility now, you’re likely to find that no one feels responsible for carrying out the experiment.
We used sticky dots (like those shown in Figure 1-3) to choose the experiments during the New Year’s Eve retrospective. We then displayed these experiments on our corkboard to keep their status in mind. There’s nothing worse than task lists that get lost in some document, wiki, or email.
)
Figure 1-3 Dot voting
1.3.6 Phase 6: Closing
To conclude, spend a few minutes on a short review and celebrate the results of your retrospective. This honors the time and energy that the team has put into both the retrospective and the preceding time span or iteration. You should also document your results appropriately. There are many ways to do this, including taking photographs of the whiteboard and keeping the flipchart paper the team used to develop their ideas. As described earlier, display these things very visibly in the team’s workroom. Finally, the facilitator summarizes on how to proceed. This is to check that everyone understands the plan.
As a very last step, having a brief retrospective on the retrospective itself is always a good idea. After all, you want continuous improvement to extend to your retrospectives, too. One tool for this is a ROTI (Return on Time Invested) graph, as shown in Figure 1-4.
)
Figure 1-4 ROTI (Return on Time Invested)
My family and I were able to celebrate our New Year’s Eve retrospective with a beautiful fireworks display. Unfortunately, you can’t do this every day, but a delicious slice of cake at the end of a retrospective can also provide a great ending.
The phase model provides you with a simple framework that will help you to plan and carry out retrospectives effectively. Keep to this framework, and you’ll have an ideal foundation. Remember, though, that each and every retrospective is unique. These six phases have been tested many times, and they work. In the rest of the book, you will learn how to bring this model to life as well as how to deal with the typical difficulties that can arise.