A Developer's POV on Creating Retrospectives

As the year comes to a close, this blog post will discuss the importance of Retrospectives from the perspective of a developer.

What is a retrospective? Let’s begin with Wikipedia's description:

A retrospective (from Latin retrospectare, "look back"), generally, is a look back at events that took place, or works that were produced, in the past.

First, why is it important to write a personal retrospective

• Avoid Recency Bias: It is a typical fact that we tend to remember recent events better than events that occurred in the past, giving the recent event more significance. It's wise to pause, take a step back, and reflect on our past actions in order to avoid this bias.

  
  

• To comprehend what you have learned: To identify the important areas where you need to improve, make a list of all the lessons you've learned.

  
  

• To consider what went wrong: Reflecting on situations when your work fell short of expectations or where you encountered difficulties will help you identify potential mistakes you shouldn't make.

  
  

• Understanding your preferences: There will be many different jobs that you have worked on. While some may be of interest to you, others won't. You can request more tasks if you have a detailed list of your preferences.

What can be the format of the retrospective?

• If you worked on several projects over the quarter or year, you can break up the retrospective into each project's learnings and successes part.

  
  

• The alternative strategy involves combining ideas like learning, successes, failures, preferences, and dislikes.

How can you start with writing your retrospective?

• Gather all the data points: This, in my opinion, is the most crucial action. You can review the data from the SCM you use to understand all languages, code bases, and even the kind of issues you worked on. To learn the theme and the list of languages, look at the commit messages and file types. Moreover, you can look at project management systems like JIRA to determine whether you focused more on Debugging or Features throughout your time. Review all the different architecture-related guilds that you have been a part of.

  
  

• Random notes from the past: Due to recency bias, which we discussed above, there are likely to be some little but significant events from the year that you will soon forget. These may be difficult problems to fix, a team discussion about the architecture, a few support tickets, or anything else. The notes don't have to be flawlessly formatted; a few bullet points can do the trick and serve as a recall of the entire scenario when you go back to it. I personally record everything that comes to me using the self-messaging function in Slack.

  
  

• Initial Thoughts: Wait a while before beginning to write a well-organized reflection. Make a list of all the things in the form of bullet points that come to mind when you think of retrospect as you stop. I usually prepare a list of every point I want to make in my retrospective before going into more detail on each one.

  
  

  Even while we may believe that writing a retrospective is simple, it actually requires a lot of thought and perseverance.

  
  

  A personal retrospective is written similarly to a Root Cause Analysis of any technical incident, with the exception that in this case, the RCA is based on the individual.