'The Good Things' in retrospectives

In Agile, everyone agrees on the concept that continuous improvement is a good thing. In Scrum and also in most Kanban practices we even have a ceremony to support this, namely The Retrospective. This periodically occurring meeting (often every other week) with the entire team plays a vital part in the process and in team dynamics.
In most retrospectives, focus is on improvement. Questions are asked like ‘What is going wrong or could be done better?’, ‘What can we do to improve things?’, ‘Did we actually improve?’. While there is real value in these questions (and they should definitely should be asked), there is another part of a retrospective that is also very important: The Good Things.
As humans, most of us are focused on what we can do better. Speaking for myself, I hardly name my strong assets or the things where I am actually good at. I focus on what I should (…) do better or what I can improve on. But I recently experienced that by focusing on the things to improve I actually lose focus on my assets and even start doing worse at the things I was good at.
In teams at retrospectives I see this happen as well. It really helps to create room during the retro to ask the question ‘What is going right?’. Examples of ‘Good Things’ are ‘Our code quality has really improved over the last iteration’, ‘Communication between our team and [some stakeholder] has improved a lot now that we visit him at least once a week’ and ‘I can focus a lot better on my work now that I blocked out at least three hours a day in my schedule in which no meetings can be planned’.
All members should really spend time on investigating the good things in the team and the process in use. These good things should be taken from the retro as well as the things to improve we listed and should also be guarded. Examples of actions to guard the good things are ‘We set up a reoccurring meeting with [some stakeholder] every Thursday so we ensure communication will remain as good as it is now’ or ‘Let’s make it a team policy to block two hours a day to make sure no meetings can be planned there’.
My schedule for a retro most of the time is the following:

1. Look back at the concrete improvements we decided on during the last retro and did we actually achieve those?
2. Take inventory of what things we think we need to improve (I don’t care how…), group them and prioritize.
3. Agree on concrete actions to take to improve the things we decided need improving in the coming period until the next retro
4. Take inventory of what things we think went well and attributed to the (increasing) performance of the team (or yourself)
5. Agree on what actions to take to hold the things that we value as good things

Ending with the good things for me is important, if only to prevent the retro from being “our bi-weekly complaints session”.
The retro is a powerful tool to use in Agile processes, aimed at constantly improving as a team (or organization). It is very important to strive for improvements, but keep in mind all those things that are actually already going well and don’t let those slip.