Retrospective - what if our idea for an improvement turns out hard to implement?

Implementing the improvement is a vital part of inspecting and adapting towards continuous improvement.

There is nothing to say the team cannot choose to implement a different improvement, or even multiple improvements., but moving on at the first sight of trouble could be a wasted opportunity for the team to get the help it needs.

In my opinion, more important than driving through any other perceived improvement would be to inspect what is learned, and adapt accordingly.

It might be more important to add transparency to this impediment. The team have committed to improve a certain aspect, and they cannot achieve it. Perhaps you need help from outside of the team. Could there be people in a leadership position who would do things differently if they understand what the team requires to work at its best?

we find out we have no influence to change this factor?

Is this change/improvement the most important for the team currently ? Do the team know the reason why they have no influence on this ? Who outside the team can help with this change ? 

Just because something is hard doesn't mean it's not worth doing.

The first step is to figure out what is worth doing. Once you have a set of problems, those problems can be prioritized. There are different factors to consider when prioritizing, such as how likely the problem is to recur in the future, when it is likely to recur, and if it does happen again what the impact is likely to be.

Once you know what the problems are, you can start to consider solutions. When you start coming up with solutions, you once again need to consider a number of factors - time to implement, cost to implement, who would need to be involved in implementing and verifying the effectiveness of the solution.

Based on the total cost (considering effort, time, money) and risk, you can figure out which problems are worth solving and which solutions are worth pursuing. You may find that it may not be worth it to escalate some problems outside of the team because the problem is not likely to recur or would have very low impact and escalation would be expensive. Instead, you may opt for solutions within the team that can help to detect when the problem is about to happen or ways to mitigate it as it is happening and these detection and mitigation strategies may be something that the team can take on fully internally.

I'd agree with Simon Mayer - implementation of the improvement is necessary for continuous improvement. But "improvement" doesn't necessarily mean "solution". It can be improving how you detect events happening around the team to better respond to them, reducing the impact should something happen, or solving internally or by escalating to people or groups outside of the team to solve or collaborate on a solution. There's also nothing that says that you can't take multiple actions, such as an internal mitigation and engage with others on a longer-term solution. It all comes down to what makes the improvement valuable.

Sprint Retrospectives are intended to aid continuous improvement. Finding out the issues and solving the problems happened only during the sprint is NOT a continuous improvement and neither intended as the aim of Retrospectives. It is like putting out a fire. When we put out fires, it DOES NOT mean that we are improving. It just means that we are putting out the fire. Unless we study what caused these issues in the first place and address the underlying causes, the retrospectives can become useless. Perhaps, it might be the reason that retrospectives lose their popularity (may not be the right word) quicker than other Scrum events. 

IMO, managing outcomes or defects is not the intention of Scrum Retrospectives, continuous improvement is. 

I completely agree with Simon Mayer, implementation of the improvement is imperative for continuous improvement. In fact, too much analysis can some times lead to "data-driven decision paralysis" and the focus on actual implementation is lost. 

However, I will defer from one suggestion given by Thomas, i.e. on basing your decision on cost of which improvments to be implemented. Instead, I would focus more on the improvments that have quality implications such as 

• provide better transparency into the system or organization
• issues that are systemic or system generated 
• hamper the customer experience if not addressed
• have more chance of linked reoccuring issues if not addressed
• can create technical debt and extended rework
• have impact on team functioning, morale, right of pride to workmanship if not addressed

But what if we choose some negative aspect and then using e.g. Force Field Analysis methods we find out we have no influence to change this factor?

What risk is presented by this deficiency and are the Scrum Team willing to accept it?

Guys, thank you so much for all your comments. 

My thoughts didn't base on a real case, I was just thinking about this kind of situation while reading the book and wasn't able to find a good answer. 

Apparently if we made a bad decision and focused on the thing that cannot be changed by us in a particular moment, we should choose more carefully during a next retrospective. 

I really appreciate your tips and now I think I know the answer for my question.