Your Agile team(s) is incrementally delivering a product for a long time. Let’s say 4 years. After every sprint a new version is delivered into production successfully and many feedback loops are giving information on what can be improved.

There is this one issue with some stakeholders complaining that all that prioritising leaves them waiting too long before they see their needs being fulfilled. In his best judgment, Product Owner has decided to postpone some requests from a particular group of users in favour of others, mostly driven by defined business strategy. This impatience from users is effecting collaboration with team(s).

The issue is discussed in a retrospective meeting, and action is defined to solve the problem. Unfortunately, the same issue arrises again 2 sprints later. It could be from same group or this time from another group of users. The cause here is deep and might be due to lack of alignment between management and users, or different business departments.

Teams spend a lot of time on this reoccurring problem, and more important, a lot of negative energy. It is a waste, a big waste. After each retrospective, the problem is not solved, but often just postponed.

A good thing to do in this situation is first to be aware of that problem has reoccured. The second thing is to prevent statements like “We’ve tried to solve this. It is very difficult, let’s keep trying.” or “We need to do more of what we did last time.” as a possible solution. This usually does not solve the problem. Instead, try approaching the problem from a completely different perspective, maybe discovered by applying completely different retrospective techniques. E.g. Fishbone Diagram. A solution might also be to ask for help from someone outside if problem falls outside the influence of teams.

The main point is, if the possibilities for solution are exhausted, teams should also be prepared to simply accept the problem as given or work around the problem without really solving it. In case of reoccurring problem syndrome, this is better than wasting time and energy in retrospectives in the name of continuous improvement, at cost of giving attention to achievable improvements. From systems thinking perspective, improving something different that is perfectly achievable, might influence in positive way this seemingly unsolvable problem. For example, repeating the business vision and path as understood from business at the beginning of sprint review meeting.