Retrospective - what if our idea for an improvement turns out hard to implement?
While reading Agile Retrospectives - Making Good Teams Great written by Esther Derby and Diana Larsen, a one particular question crossed my mind, thus I would like to share it with you - because maybe I misunderstood something.
Gathering Data stage helps to identify positive and negative factors of our work - that's clear. Then we have generating insights stage in which a team should find ways to solve one of those negative factors - that's clear as well. 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?
Should we take another factor identified during gathering data stage and analyze it? It would obviously take time, but Scrum Guide stands that teams should implement at least a one improvement to the next iteration in aim to test it.
What are your thoughts? Thanks in advance for share them :)
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?