On Agile retrospectives

Retrospectives are the way used in Agile (or Agile-like) environments to discover and fix problems.
You can think of it as a continuous iteration of the team's workflow.

The idea is genuinely good: the team discusses what went well during the Sprint, what problems it encountered, and how those problems were/were not solved.
The output of these meetings is typically a list of problems/improvements and a bunch of proposals to solve/fix/improve them.
The list is prioritized, and with a vote, the team picks what topic should face up.

I like the idea. Along with other Agile rituals, retrospectives play an essential role when a new team is newly formed and where people are sizing each other up.
However, after dozen of retrospectives, I started seeing a typical pattern in every project:

Without a target, teams easily fall into a loop where they try to fix random problems without experimenting any real improvement over team's agility.

Meeting after meeting, the team was struggling with productivity issues; while the team was not slowing down, the scope and complexity of the projects had grown.

While, indeed, several problems were fixed over the weeks, there is a distinct feeling of sailing by sight ("sailing by sight" means looking beyond the horizon without a given destination).

The goal of a retrospective is not to fix or discover as many as problem possible.

Frankly, I stopped counting the number of meetings where the only challenge seems to make the list of complaints bigger and bigger.

Most of the time, these meetings miss a clear long-term vision.
In Toyota Kata, there is a good approach that can be mixed with scrum retrospective.

Making retrospective something more useful starts with observing the current condition. A deeply understand of the current team state allows for setting a challenging but not too challenging list of goals.

A goal describes what we want to achieve and not the necessary steps to get there.
It's the northern start to follow until the next one.

Is much easier to find solutions when the team know where they're heading.

Once the goal is set, the team will only focus on discovering and fixing the obstacles on the way to the next goal.

This approach shifts any discussion from "What is our problem?"  to a sightly but very different "What is preventing us from reaching our next goal?".
Moreover, the entire team focuses on a single critical point and aims to fix it.

The easiest way to reach a goal is to make experiments using an approach like the Plan-Do-Check-Act cycle, where you Plan the experiment, do it, check the result, and finally, act on these results.