Retrospective meeting – Why is it important to look back?

“Progress is inevitable: in a world on the move, what does not evolve will decline.” This saying by Argentine writer, poet and philosopher Jorge Ángel Livraga became a cliché by now, but it remains valid. Our world being in constant motion, business is of course in constant motion as well, so the effort to improve is essential. One of the most obvious means of progress is conscious change based on past experience. This is not a new insight, the methodologies before agility were aware of this and provided many different solutions and techniques to achieve this (e.g. lessons learned meetings, post-mortem meetings), which can be considered as the ancestors of the Retrospective meeting. Agility has brought two major changes compared to the previous approaches: it has increased the frequency of learning from the past and reduced its scale. More reliable, lasting progress can be achieved with frequent but smaller rather than infrequent but large changes. As the twelfth principle of the Agile Manifesto puts it, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. “

Why is it important to look back

Looking back is not important. More precisely, it is not important in itself, not for its own sake.

We often get the above question in training sessions and counseling sessions, but it’s not a good question. It highlights a common thinking error: confusing goals and means. The Retrospective discussion is not an end, only a means, and therefore not important in itself. Like a Swiss Army knife, if used well, it can contribute greatly to achieving a number of different goals, both for the team and the organization.

The aim of the formal Retrospective is, of course, to improve: the team regularly evaluates its own way of working, the experiences of the last iteration (sprint), draws lessons from them and, as the latest version of the Scrum Guide 2020 puts it, “plans ways to increase quality and effectiveness”, thus improving both its own operations and the product it produces.

Good retrospective meetings can greatly facilitate and accelerate the team’s maturing, becoming a real team by continuously emphasizing common goals and finding collective solutions. Of course, the key word here is “good”, a badly conducted Retrospective can easily have the opposite effect, degenerating into blaming and scapegoating.

Although it could be seen as a side effect, it is better to see it as a goal: a good Retrospective greatly increases the motivation of the team and team members. According to Dan Pink’s theory of Motivation 3.0, autonomy is one of the pillars of motivation. A successful Retrospective requires that the team is truly free to define its own way of working, its own methods, within a defined framework of course, without compromising cooperation with the rest of the organization.

Retrospection is also a tool for improving the organization, because, although the main focus of retrospection is always on the team’s product and the team’s operation, there are often factors that are beyond the team’s control that hinder either efficiency or quality improvement. By highlighting them appropriately, the team can stimulate the improvement of the whole organization.

At the same time, as the team develops, as its efficiency increases, so must the other departments collaborating with it, otherwise they themselves will become obstacles to progress. In the development of complex business products, for example, it is not uncommon for the software development team to accelerate to the point where it overtakes the business design team, which then, if it does not want the development team to sit idle, is forced to improve its own efficiency.

For these reasons, the retrospective meeting is also a sensitive instrument that shows how serious the organization’s commitment to agility is. Only if the team is truly working towards common goals, if they have a sufficient level of autonomy, and if they are supported and helped by the rest of the organization, and are willing to improve, can we expect to see progress.

How often should we hold a Retrospective?

At the end of each sprint as suggested in the Scrum Guide. This suggestion implies both frequency and regularity. Regularity is important because a predefined, predictable schedule of sprint meetings both sets the team’s biorhythm and provides a basis for measurability and long-term planning. And, in addition to the “often, a little” rather than “rarely, but a lot” principle indicated in this article’s introduction, frequency can also be explained by simple human reasons: our memory is finite. The less frequently we look back, the more vague our memories are from the beginning of the period under study. What we cannot remember, we cannot learn from.

Even in the life of the best team, there can be times when the one to one and a half hour required by a Sprint Retrospective seems painfully expensive. For example, two months before the Olympics, the company unexpectedly wins the tender to supply a system to control the pyrotechnics and fountains at the opening ceremony.  There is a lot of work to do, the opening ceremony will not be postponed, the team will have to work overtime. As a good Scrum Master, the task is not to rigidly enforce the methodological framework, but to find creative solutions. However, in an intensive period, improvement becomes even more important. The more the team grinds, the less time there is to stop, take a breath and think. The tighter the deadline, the more a good idea can save you. In such cases, we therefore recommend replacing the formal Sprint Retrospective with discussing the experiences of the last sprint over a team lunch.

Although not at the end of each sprint, in larger organizations it is worthwhile to have a joint Retrospective at a higher level than the team (product level, project level, etc.) from time to time, in order to make small teams more effective not only individually but also collectively. The frequency of this depends mainly on how closely each team has to work together.

How can we learn from a Retrospective?

It’s worth noting that neither the Agile Manifesto nor the Scrum Guide uses the verb “learn”, rather they say that the goal of the Retrospective is to “align, tune, insert and plan”. This is probably because learning alone does not promise change, learning can easily fade into passive knowledge. The Retrospective aims at active improvement, so this kind of learning is learning by doing. Either by identifying and systematizing successful solutions that have emerged spontaneously from previous sprints, or by experimenting. One of the great advantages of the “often, little” principle mentioned above over the “rarely, a lot” approach is that it allows for mistakes. A team that sets out every year to make changes that are intended to be forward-looking will lose a great deal if those changes are not successful. If the team improves its operations every two weeks, it can comfortably allow for some of their ideas to not to work. Experimentation is not only allowed but highly recommended as a way of dealing with problems that are identified in retrospect: if the team cannot solve a problem, there is value in finding partial solutions or even in identifying experiments that might help addressing the problem.

What shall we repeat?

The only thing that is essential to repeat in a Retrospective is the retrospecting, the looking back. The regular and frequent Sprint Retrospective, held at the end of each sprint. Everything else: the form, the process, the technique of the meeting can be changed, and should be changed. One of the most common pitfalls of the Retrospective is that it gets exhausted, becomes routine and as a result fewer ideas are generated. To counter this, it is important that the Scrum Master is constantly looking for new techniques to stimulate the team, to always have a different perspective when looking at how they work. Of course, there’s no need to introduce a new technique at the end of every sprint, but as soon as the actual approach seems to be losing its momentum, it’s time to change. The truth that nothing should be set in stone other than regularity and frequency (apart from mutual respect between participants, of course) is illustrated by the fact that although the name of the event is Retrospective, sometimes, for example at the beginning of a major development effort, it is worth looking into the future rather than the past and using a futurespective technique.