Agile development approaches thrive on quick and specific feedback. Whether it's about a new product feature, an idea, or the development process itself, validating or disproving assumptions promptly enables informed decision-making for the way forward. Collecting feedback can take many forms, and one effective method is through retrospective sessions, commonly referred to as "retros."
When organizing retrospective sessions, there are key principles to keep in mind:
1. Regularity
Retrospective sessions should be an integral part of your team's processes, conducted consistently. Typically, at the end of each sprint, the team gathers to analyze their progress and identify ways to move forward. Failing to make retrospectives a regular activity can hinder process improvement, lead to slower and less systematic progress, and prevent important opinions from being shared. In the long run, this may result in team frustrations.
2. Openness
Retrospective sessions should foster a trustworthy atmosphere where everyone feels safe to provide honest feedback. Keeping comments and feedback secret inhibits the team's ability to address and resolve issues effectively. Therefore, it is crucial to create an environment where transparency and open communication are encouraged.
3. Trackable Outcome
The results and outcomes of each retrospective session should be documented and made accessible to the entire team. By saving and sharing these outcomes, anyone can refer back to them, take action based on the feedback received, analyze patterns over time, and use them as a foundation for future discussions and improvements.
How does a team actually address its problems in a retrospective session?
Here are the main topics you could focus on:
What works well and what needs improvement?
During the retrospective session, it's important to acknowledge practices that are working for the team and helping them achieve their goals. These practices can be both from the Agile framework and from team rules or agreements that the team developed together. These practices make the delivery stable, predictable, efficient, and valuable. So the team needs to highlight what works for them in the best way so that these processes can be preserved.
On the other hand, there is always room for improvement, and these details might be even more important to talk through. Any problem that the team faces shows where something is missed. So describing the problem lets the team think of a solution and therefore strengthen their processes.
How to keep good and how to change wrong?
This would be a follow-up to the first topic. When the team has outlined what makes their work efficient and what is still missing, it's time to discuss how to actually address these points. Of course, it's more valid to think about how to introduce improvements. Ideally, team members need to generate their own solutions. First of all, they see problems from their side and usually have an idea of what change is needed, and what impact it will make. Second - when a team provides a solution, they are eager to implement it with much higher involvement.
Plan tasks for the team as the solutions for issues and negatives.
When the team knows what needs to be improved and how to do it, the final part would be to track the needed action and plan it in the upcoming sprint. If there are multiple actions planned, focus on the most important one and try to include it in the very next sprint so you can evaluate the result of it during the next retrospective. Other improvements can be postponed to future sprints. In some cases, if improvements don't overlap and you will be able to evaluate the progress of more than one process change, you can include more than one in the sprint.
Check the progress and tasks from the last retrospective.
At the next retrospective session, this could be the starting point of a discussion. The team can analyze the results and see if the improvements have been successful or not. This serves as additional input when planning the next actions.
It should become natural for the team to think of improvements, share them, come up with solutions, and evaluate the efficiency of these changes. Regular retrospective sessions help the team to develop such a habit and make use of it.
Who attends retrospective sessions?
During retrospective sessions, only members of the development team attend, while the scrum master facilitates the discussion. The development team includes developers themselves, QA engineers, and sometimes even designers and solution architects, depending on how the team is structured. People outside of the development team are usually not allowed to attend.
However, as an exception, a team may decide to invite someone from outside who they work with to exchange feedback, such as a product owner or a customer representative. Such exceptions could be useful when discussing a large finished milestone or a sudden big issue in collaboration.
Some additional tips
If you're leading the retrospective session, here are some tips to make it great:
1. Engage everyone on the team in the conversation. If someone is quiet, give them a chance to speak by directly asking them. Try to set up the conversation in a way that everyone wants to share rather than being pushed to say something.
2. If the team says everything is good without any additional details, reformulate the questions to be more detailed. Perhaps the team is shy or reluctant to speak about a specific problem, or they don't know how to formulate their thoughts properly.
3. Don't stick to the same format for every session. Feel free to experiment with different formats and perspectives.
4. Add some ice-breakers or gamified activities that are unrelated to the project. This can help the team relax and create a more trustworthy atmosphere, allowing them to share more insights.
5. If there is tension with someone on the client side, organize a special open session with that person or group of people. Prepare topics for discussion that are problematic, questions as well as feedback towards the client. Be very attentive to detail and steer the conversation in a way that solutions for problems are identified or at least the next steps are clear to everyone. These sessions help to establish more trust and transparency between parties and see things from different angles.
6. Retrospective sessions are a good chance to analyze the team's velocity. It can serve as a trigger to ask specific questions about why the velocity changed or remained the same during the sprint. Make sure that the reasons behind changes in velocity (both negative and positive) are tracked and understood by everyone. Actions tracked as the output of these discussions should be aimed at stabilizing and increasing the velocity over time.
In conclusion, a retrospective session is not the only chance to exchange feedback and plan improvements, but it is usually the most focused and thorough discussion about various aspects of teamwork. If you want to achieve better results with every iteration of your work, it's important to learn from your experience and define improvements so that it becomes a regular part of your work, ultimately bringing more value to your product users.
Epilogue
A retrospective session is not the only chance to exchange feedback and plan improvements, but it’s usually the most focused and thorough discussion about various aspects of teamwork.
When you want to achieve better results with every iteration of your work, you need to know what will make this result better. So practice learning from your experience and defining these improvements, so it becomes part of your work along with bringing value to your product users.
Reach out for more information.
Nikita Lamonov, product owner
