If I had to choose which is the simplest and most anticipated ceremony from Scrum, without any doubt I would choose the retrospective meeting. Why? Because the work of the sprint is completed, the work has been delivered to the client and now it is time to enjoy the results of our work and plan how to improve and be even better next time.
At the same time, without any doubt I can easily say that retrospectives can be one of the most controversial ceremonies. Even if everybody agrees that the idea of having a retrospective meeting is excellent because it gives us the opportunity to improve constantly, to adjust and to fine tune the current process, the reality is often different. I have interacted with a large number of projects and teams, and I can say that the number of situations where the retrospective was considered useful by the teams is very limited. I refused to believe that the problem was the only common factor which could be seen without any effort – myself – and I tried to retrospect the retrospective process and come up with improvements.
The basic idea for a retrospective meeting is to review what went well in the last iteration, what went badly, what needs to be changed, and what needs to be done in the same way. Ideally the result consists of an action item list which can, and should, be followed up on in the next retrospective meeting. There are a lot of tools which handle the logistics very nicely. There are also a lot of techniques and games which make this meeting very enjoyable and keep the people engaged. The purpose is noble and the process is clean but still there are enough situations when it fails. I have often found people not focused, people not caring and in the worst scenario people demotivated by this meeting.
How can a process implemented by the book fail? When do people start to lose faith in it? The obvious answer might be stranger than we think – when there are no results. Would you like to have the perfect soccer strike technique and not score a goal ever? A regular meeting with a great process but with no results is kind of an useless one. When we find the same problems over and over and they are not resolved then we start wondering what’s the purpose of all this. When action items are carried over meeting by meeting then of course demotivation takes control.
Going through all these different situations, I tried to identify a possible root cause of this. In many of the cases I noticed that problems enumerated or action items defined were not actually in a team’s direct influence to change or address. There were real issues most of the times and really painful ones but their resolution was not in the team’s hands. This is the fastest recipe for failure.
For an extreme example, let’s imagine ourselves in a fishing trip. Well planned, perfect place and…it rains. We do a little retrospective, we enumerate all the good things and of course we complain about the rain. We plan the next trip in the same place, same people, same type of beer with us and of course…we plan for the perfect weather. We even take into consideration to look two days before on any known weather site in order to reduce the possibility that the rain ruins our trip again.
Do we have any guarantee that the weather will be actually perfect? No, because is not in our power to control it. Is the weather an important factor of the trip even if is not in our control? Of course it is. In day-to-day work we can also find various samples of things which may affect the work and are not in a team’s direct power to change: some third-party control glitches which affect the current development; a client failing to provide in time credentials for testing environments, etc.
The analysis of the facts mentioned above lead me to one conclusion. If the main focus on things to change is stolen by issues which are not dependent on us, then the results are compromised. The small update which can make the difference is to group the action items in two categories: internal action items, which are team dependent, and external action items,which are not fully in the team’s power to resolve.
The scrum master or the project manager, whoever is leading the facilitation, should emphasize the importance of focusing especially on the internal items and keeping the team’s main focus on these action items.
This brings two huge advantages:
Focusing more on the internal action items doesn’t mean that we should neglect the external ones. Through those might be very important ones for the team and the smooth running of things. Each one should have an owner who can present the status through their completion. Since success at addressing those action items doesn’t depend mostly on us, the presentation of the results is very important. If we carefully weigh these items less than we weigh internal ones, the chances of them becoming demotivating can be reduced dramatically. When it comes to external items, even if we cannot solve them directly, we can take actions on our side which can make our life easier until problems are solved. If we want to circle back to the fishing sample, we might not control the rain but for sure we can add to the trip luggage protective clothing for rain or an umbrella. If the third-party control we are using has a glitch, we can found a workaround until new version with the fix is released.
A good purpose and a simple-to-implement process are not always enough to ensure success. The team buy-in and commitment for the purpose are vital and usually this comes from actual results. And results can be obfuscated by a wrong focus. As in many other areas we need to choose our battles wisely, so focusing on what lies in our ability to address gives us the control to make it happen and eliminates the possible frustrations created by something which we cannot control and doesn’t go well. Focus first on the team improvements and then on other stuff. Try this small twist in your sprint retrospective approach and I’m sure that results will follow.