Thanks Asad, you are really right when we often end up pursuing low-priority impediments.

But I have observed a bigger problem.

At the end, the objective of all of this Agile is developing software. It is to create a good enough code that implements the requested feature. But that requires a code easy to manipulate.

Yet, a question that I rarely hear by retrospective facilitators is: "Did you, developers, have observed some part of the code that has created some resistance in the latest implementation that might benefit from some reengineering?"

Why? Because in the retrospectives there are usually three roles involved, in which only one can maintain a conversation about that. And somehow, we lower the bar, so it can be an inclusive, but not very useful meeting.

And consequently, retrospective often ends up being more political than practical.