The importance of reflecting in software

Henry Ford said, "Coming together is a beginning. Keeping together is progress. Working together is success".

We sometimes need to reflect on the past to keep together and work together. We can do this as a team in software by running a retrospective. Retrospectives provide us with an opportunity to look back. By doing so, we can explore and review what has worked and what has not. This assists the team as a whole in working well together. Through treating areas that have worked less well as opportunities, we can improve processes. Overall this can create higher value and deliverables as a team.

What are retrospectives, and why do I need to run them?

Although they vary on a team-by-team basis, retrospectives generally follow an agile methodology. Concentrating on a certain timeframe, such as a sprint. The meeting will then evaluate what worked, what did not, and what areas could be improved. From this, action points are often created. The meetings are a chance to more deeply explore any problems and allow you to search for the root cause. Creating space for the different team members to share their experiences lets the voices of the entire team be heard, not just the more vocal ones.

In order to run a retrospective efficiently, you will need to have achieved enough work over a certain time frame to reflect upon. Creating action points when you have not done anything is using this tool too fast. Additionally, the team needs to be able to be open with one another. Create the space for discussions from a place of curiosity. Psychological safety needs to exist, and the conversations that occur should be free of blame.

Reading tip: Why retrospectives are essential

What are the goals of a retrospective?

One of the main goals of a retrospective is to look at what can be improved. If you are going to run them, you need to be able to attempt to implement changes. Suppose you run retrospectives but never make any changes to the action items, the engagement or morale of your team will drop. If, during the process, you find reaching a certain action item unrealistic, be transparent. This will encourage the team to do the same and will prevent you from trying to change something that, in reality, you are unable to.

Overall, the retrospective will enable you to learn from your past, create improvements for the future, and avoid repeating mistakes. Hopefully, this will lead to better-focused sprints with increased performance and efficiency. For the team as a whole, you will be fostering a culture of continuous improvement, knowledge sharing, and collaboration.

Who should attend the retrospective meeting?

Ideally, it would help if you created as much diversity for the retrospective as possible. You may wish to include the product owner, the sprint team, and additional stakeholders. Keep the retrospective limited to those actively involved and ensure you have a safe space for everyone to speak up. Additionally, you may wish to assign a minute taker. Creating a reference for the meetings will enable you to track action items better, promote accountability and assist with evolving communication and planning.

How do I run a retrospective?

Before you start the retrospective, you should have some goals for what you want to achieve. If you are running the meeting with the whole team in person, you should have sticky notes and a wall to place them on. If you are running the call remotely, you will want to look for an equivalent tool to do this digitally via screen sharing. Notion is one example. Consider using a timer to keep the meeting on schedule and assigning a minute taker so the meeting is documented.

Also read: 5 documents every startup should have

Starting the retrospective meeting

Kicking off the meeting itself, you should explain the intention and objectives to all the team members. This is also the time to set any specific rules. Emphasise the importance of transparency and the need to listen. Foster an environment where everyone is relaxed and able to converse with one another. Some teams like to start the meeting by reading the prime directive. This was defined by Norman Kerth in his book Project Retrospectives: A Handbook for Team Reviews," and it sets the foundation for the session.


At this point, you may wish to warm the team up with an icebreaker. Even if your team meets every day it can help to prepare the team to be more interactive with one another. At this point you may then wish to check in with the team that they are ready to proceed with producing feedback.

Exploring the good and the bad during the retrospective

With the ice broken, you will want to get your team to explore what went well and what did not go well. Refrain from creating action items just yet, and try to lean away from looking at one-off errors. Keep the focus on the sprint or time frame in question. It is easy to drift off course if you start to look too far backwards. This can also isolate newer members of the team. The intention here is to focus on the good and the bad parts. There is no specific right or wrong approach, but listed below are approaches some teams use:

  • Mad, sad and glad
  • Start, stop and continue
  • Good, bad and better. 
  • Starfish method (includes keep doing, less of, more of, stop doing, and start doing)

Gaining feedback during the retrospective

One of the biggest challenges for running retrospectives is a lack of feedback from your team members. They rely on honest feedback so you can explore what has and has not worked. If you struggle here or your team comprises more quiet members, you may wish to experiment with different methods, such as anonymously acquiring it prior to the meeting with email forms.

When using any of the approaches, generally, the team will be given a set period, such as 5-10 minutes, to write out their cards and place them into the relevant categories. Once this time is up, the team can share their thoughts and place votes on the most essential items. From here, you can start creating action items. 

Once you have enough good and bad feedback, you should start exploring the overall insights and creating action items based on this feedback. This will help you set any ongoing goals. Make sure there is no misunderstanding, and check for patterns and themes. If necessary, hold a vote to help guide assigning priorities.

Ending the retrospective meeting

At the end of the meeting, look at the overall themes and emphasise the action points you created. Metrics can help you get the most out of a retrospective and measure impact. Ideas for what you could use here include KPIs, completion time, team satisfaction, stakeholder feedback, and overtime.

In terms of frequency, you will want to find a schedule that works for the rhythm of your specific team. You will not want to organise these meetings too often. Aside from taking time, you will want enough of a gap between meetings to offer the opportunity for improvements to show. Some teams run these meetings monthly or after sprints.

Retrospective meetings should be enjoyable

We advise you to set a specific time for the retrospective, keep track using a timer, and ensure the action items created are achievable. In order to make the retrospective process successful, you should attempt to make it as fun and enjoyable as possible. Many ideas on how to achieve this are available here. If your team is not remote, providing food and drink can also help! Although the sessions are to continually improve, you can also use them as a time to thank your team.

When your team looks forward to these sessions, they will contribute more, and you will get more from them as a whole. Altogether, retrospectives offer a chance for a team to grow beyond their goals, remaining as motivated as possible whilst promoting team cohesion. 

Reading tip: Habits, retrospection, and ancient reptiles