Apply the Active Learning Cycle, which mixes the ideas behind the Lean A3 Process, and the Toyota Kata. The first one is helping to identify the root causes of a problem, while the second helps to define the future better condition that the team should aim for and also target a potential next step in that direction.
Take a sheet of flipchart paper and divide it into 3 areas: Keep, Try, Observations (Breaks and Accelerators). The most common form looks like this but you can always use a different form if it suits you better.
To give focus to the continuous improvement of the team, we want to identify longer term goals, longer than 1 or 2 sprints, but not too far ahead in the future.
As a facilitator, you can help the team to identify (possibly through actionable metrics) the things that slowed down the team, and the things which made the team faster in the past Sprint.
Ask the team to come up with post-its for each of these categories:
Brakes: Things which are slowing the team down.
Accelerators: Things which the team thinks makes them faster.
Make sure the team is reflecting on the reasons why either Brakes or Accelerators happen and identify the things which need to be addressed or leveraged. Once these are clear, the facilitator asks the team to define a goal (which could be in the far future) either to focus on things they would like to amplify or by removing things which are slowing them down.
Once the goal has been defined, the team will have to identify the criteria that will prove that the Goal has been reached, something measurable (e.g: 70% test coverage, less than 2% new bugs…).
Write a post-it with the Goal, and the measurement criteria a place it on Try (indicating the team is going to try to reach that Goal).
To reach the goals they identified, the team will choose the first step towards that goal that will be achievable within the next Sprint. The team should not be too ambitious and focus on 2-4 things that they are actually confident they can achieve.
These concrete actions will go into the Try area, directly below the high-level Goal identified. It is also important to determine what is the condition of satisfaction in order to be able to evaluate the progress at the end of the next Sprint. How long should we try the new thing (every day, every second, two people only...)? Who should try it (volunteers, the whole team, the product owner...)? How would we measure the impact of the change (can we already use the long term Goal metrics? a subset of those?)?
At the start of a retrospective, we evaluate the concrete steps we took in the last Sprint. We decide if they helped us to reach our goal(s) based on the metrics that we have decided to measure in order to determine the impact of the change toward the long term Goal.
Are we satisfied with the improvements? Is there already something we can persist as our standard way of working? Can we keep it? If so, we can guide the team to identify changes they can explicitly do to:
In the retrospective itself, the team can either identify further steps to reach their continuous improvement goal(s) or when they have reached one or more goals, they can try to identify new goals.