Agile Best Practices: A Small Twist To Uplift Retrospective Efficiency

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.

The challenge

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 twist

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:

  1. Solving these items from meeting to meeting brings us the results we want, which are: improving the current process, keeping the team motivated and maintaining the utility of the meeting and the buy-in of the team for it.
  2. Not solving the internal items cannot be blamed on anybody but the team. If the team really wants to improve, they will answer to questions like: “why didn’t we meet our commitment?”, “do we really want to change this?”. “are we really committed to improve?” It is very hard to keep finding excuses for not improving the quality of our work when the main reason for this is ourselves. Who’s crazy enough to say – this doesn’t work well, I cannot work with this problem or constraint anymore – when that person is actually the one who’s not doing the right thing?

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.

The conclusion

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.

Bogdan Muresan

Bogdan Muresan

Director of Engineering

Bogdan Muresan is the Director of Engineering for 3Pillar Global, where he has transformed his background in development into a passion for project management. Following this passion has allowed him to cultivate a skill set in Agile methodologies frameworks, inciting improvements to management processes, and promoting teamwork across a multitude of complex projects.

Leave a Reply

Related Posts

Building a Microservice Architecture with Spring Boot and Do... This is the first post in what will be a 4-part series on building a microservice architecture with Spring Boot & Docker. This post will provide a...
Building a Microservice Architecture with Spring Boot and Do... Part II: Getting Set-Up and Started Introduction and Tools In this part, we'll get to work on building out the solution discussed in Part I. I'm goi...
Building a Microservice Architecture with Spring Boot and Do... Part III: Building Your First Microservice, its Container, and Linking Containers We're about ready to actually get started with building a microserv...
Building a Microservice Architecture with Spring Boot and Do... This is the fourth blog post in a 4-part series on building a microservice architecture with Spring Boot and Docker. If you would like to read the pre...
Innovation Wars, with Scott Bales Scott Bales joins us on this episode of The Innovation Engine to dive into the concept of "innovation wars." Among the topics we'll discuss are what c...


Sign up today to receive our monthly product development tips newsletter.