Agile Retrospectives 101
Get the basics you need to start with your first Agile retrospective to establish a continuous improvement process.
Save 35% off the list price* of the related book or multi-format eBook (EPUB + MOBI + PDF) with discount code ARTICLE.
* See informit.com/terms
This chapter is from the book
This chapter is from the book
This chapter is from the book
The primary purpose of this first chapter is to introduce you to retrospectives. I’ll tell you how to use retrospectives in a family context, introduce you to the phase model, and give you some hints for how to fill these phases with life. After this chapter, you will have all the basics to start with your first retrospective, so let’s get started.
1.1 What Is a Retrospective?
Generally speaking, a retrospective (lat. retrospectare, “look back”) is a review, a look backward. When you lie in bed at night and let the events of the day cross your mind, that is a retrospective. When a family sits down to dinner and talks about the day—the children talking about school and the parents talking about their experiences—that is a retrospective. Looking back over the life’s work of an artist, author, or director is also a retrospective. As part of a retrospective like this, various events take place at which a range of the artist’s work is shown. All the important pieces are collected in a single place to provide a complete picture of the artist’s work. This makes it possible to get a good overall impression and affords the opportunity of comparing and contrasting the different works of art. This would be impossible if we had access to only one example. Only by getting the overall impression is it possible to see the whole and have the opportunity to speculate about why the artist did one thing and not another.
Another kind of retrospective takes place on television, usually at the end of every year, in the form of a year-in-review program, where the different broadcasters compete to have the funniest, most beautiful, or most famous people on their programs. Entertainment is the priority here, and there’s not much emphasis on getting a full picture. These year-in-review programs are therefore rather patchy and aren’t really suitable for drawing conclusions or looking at the connections between different events.
When I speak of retrospectives in this book, I mean something else. The retrospectives I discuss also involve looking back, but that is just the first step. Much more important is to gain knowledge and insight from this activity. This knowledge and insight can help us learn from the past and adapt accordingly. We can learn from both successes as well as failures; good things can often be made even better. You could compare it to evolution: things that haven’t worked become extinct, but everything that contributes to the preservation of the species is kept and developed further. In the end, each of these adaptations is nothing more than an experiment, because you never know for sure what the result will be. At best, these experiments lead to an improvement of the current situation. Sometimes they do just make things worse, which we then must analyze in the next retrospective.
Every retrospective is led by a facilitator, who ensures that the group achieves the goals it sets. He helps the groups to develop practical results that will be the foundation for future success. The facilitator is not a participant (although in small teams this is not always avoidable); he accompanies the process but is not actively involved in implementing solutions. A good facilitator is essential for a successful retrospective.
This kind of retrospective was first described by Norman Kerth in his book, Project Retrospectives: A Handbook for Team Reviews [1]:
A retrospective is a ritual gathering of a community at the end of a project to review the events and learn from the experience. No one knows the whole story of a project. Each person has a piece of the story. The retrospective ritual is the collective telling of the story and mining the experience for wisdom.
In his book, Kerth explains how retrospectives differ from so-called “postmortems” and “lessons learned.” The main difference is that retrospectives focus on positive future actions and use them as a catalyst for change. They represent not the end of the project, but milestones in the process of continuous improvement.
In 2001, several people met in a ski lodge to write a manifesto for agile software development [2]. The foundation of the manifesto consists of four pairs of values and twelve principles. The last of these principles is an excellent description of what happens in a retrospective:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This manifesto is one of the main reasons that the agile community in particular enthusiastically incorporated retrospectives into its work process. These people realized that they did not have to wait until the end of a project to learn from what had happened and make appropriate changes. Instead, they organize a retrospective after each iteration; that is, after a certain period. This interval should be no longer than one month. Otherwise, you run the risk of stretching the feedback cycle too far.
I use the term iteration to describe the process of running a project in clearly defined, short, repetitive steps. After each iteration, you stop to determine whether and to what extent the project objective has been realized and, if necessary, adapt the original plan. The goal is to keep the risk of uncertainty and surprises to a minimum. The same procedure can also be used in change management.
Holding retrospectives enables you to establish a process of continuous improvement, which constantly checks whether or not you are on the right path and also gives you the opportunity to intervene and make any necessary changes promptly. By scheduling a dedicated time for reflection, you give yourself the opportunity to solve problems immediately, instead of having to wait until the end of the project. If you do not hold the retrospective until the end of a project, you run the risk of forgetting what you have learned before the next project. You also gain the opportunity to implement improvements in every iteration.