What is retrospective in Agile and Scrum? How to improve retrospective meeting? What are the best retrospective techniques? These questions will find answers throughout the post.
Retrospective, in Latin retrospectare, means look back. As an adjective means “looking back on or deadline with past events or situations”. As a noun, it means exhibit of the lifework of artists or performers.
A retrospective is known not only in software development but also in medicine or culture. In medicine, retrospective means looking back at the records and interviews of a patient, who had some disease, in order to study that case and learn for the future.
In software development retrospective is well known as one of the scrum ceremonies. Scrum is a framework in the agile world, which organizes development in iterations called sprints. At the end of each iteration, the project team meets during a retrospective meeting to discuss the sprint.
Typical sprint retrospective answers the following retrospective questions:
• What went well?
• What could be improved?
• What will we do better in the next sprint?
Can retrospective be used also for projects which do not use scrum framework? Yes! A retrospective is a great tool for continuous improvement in projects and Project Managers should use it in their projects even if they’re not working in Scrum.
A project retrospective is a tool for continuous improvement in the project. The project team uses it to constantly review the way of working and suggest what can be done better next time. Quickly identified and addressed issues do not create additional project costs or risks. Nevertheless, organizations may repeat the same mistakes in different projects, which becomes very costly. How many times did you hear about the same problem during retrospective in different projects? The project retrospective may identify project issues, however, it would be very inefficient to repeat the same mistakes from one project to another. The key aspect of a good retrospective is not to only identify project problems, but also to learn as an organization and improve the way of working in the future.
Each organization should have a continuous improvement process and lessons learned culture. Each project team should provide feedback to the organization about what they have learned and how they improved their way of working. The goal for the organization is to improve the process in the future, which is not an easy step and it may involve change management.
1. Introduction: Start the meeting with an iteration overview - present how did the team perform in terms of iteration progress and goal realization. As a Project Manager, you should have project metrics that will provide answers to those questions.
Tip: At the beginning answer the team's questions and explain how to read project metrics. After the first couple of meetings, the team will get familiar with it.
2. Review: Then continue with reviewing actions from previous retrospectives. This step is important to ensure that we act on actions identified during previous retrospectives.
Tip: Consider using a Retrospective Board, which may be a simple Kanban Board to keep track of actions defined during a retrospective.
3. Adding comments: Now it’s time to move to a retrospective tool. Ask the team to prepare items about:
• What went well in an iteration
• What did not go well in an iteration
• What they would like to improve in the upcoming iterations
Tip: agree on the time and set up an alarm. This will help you to manage the time of the meeting.
4. Group: There will be similar items raised by different people, so now it’s time to group them.
Tip: This should be teamwork, even if one person does the grouping in retro tool.
5. Voting: Continue the meeting with voting. Ask participants to vote on items that they believe are the most important. Each participant should have a limited number of votes.
Tip: When choosing the retro tool, check if it offers a voting option.
6. Discuss: Now you’re ready to start the discussion with the team. Focus on those items, which got the highest number of votes.
Tip: At this stage, it’s important to manage the time effectively. Focus on discussing the problem and defining a solution for it.
Tip: Some teams may extend the discussion about one item. Try to manage the discussion and if needed set up additional meetings to discuss the specific problem (this may be one of your actions from the retro)
7. Retrospective summary: prepare a list with action items and add them to the project retro board. Those actions need to be SMART and each should have assigned the person responsible.
Tip: You will not solve all the problems during retrospective. But it’s important to capture them and define actions.
The project Leader / Project Manager should lead the meeting. In case the Project Manager won’t be available, other team members could step in and lead the meeting. Hence it’s important that everyone is familiar with the process. On the other hand, project team members can lead the retrospective (each time another person). However, this option will not be possible for all the team, as it depends on the team's seniority.
As per Scrum guidelines, the retrospective should take 1 hour for 2 weeks sprint (iteration) and it should be part of each sprint (iteration)
The Project Team should be present during the retrospective meeting.
The sprint review is a meeting to demonstrate the iteration deliverables. While retrospective is dedicated to discuss how did we work during the iteration - what is all good, did we have some gaps in our process, what can we do better next time, etc. During the sprint, the review team focus on a product, while during retrospective the focus is on ways of working.
As retrospective is another meeting that the project team will attend, try to make it fun and encourage people to actively participate. There are several effective retrospective techniques that can be used in order to well organize the meeting. Those are especially important for an efficient retrospective for distributed teams, who may now collaborate together.
Gather feedback from project team members by asking them:
• Start - what we should start doing from the next iteration?
• Stop - what we should stop doing from the next iteration?
• Continue - what we should continue doing?
This is a technique that covers adding comments - step 3 in the retrospective structure.
.png "start-stop-continue")
4 Ls stands for:
• Liked - what team liked about the iteration, what did go well?
• Learned- what team learned about
• Lacked - what could be done better?
• Longed For - what team desired it to have, but it was missing?
You may follow the meeting structure described above and introduce 4Ls as a template for step 3 (adding comments).
This is a fun template that will encourage people to think widely about the past iteration. The team doesn’t need to be familiar with agile or scrum terminology in order to use it. Thanks to the metaphor, it’s well understood by all the stakeholders.
The below picture comes from Miro, which is an online tool that supports collaboration for remote teams. You can manage your retrospective directly in Miro and use this template.
The project team will write down comments on sticky notes and then move them to the specific area:
• Rock - what are the potential risks for your iteration, that may
• Anchor - what kept you in the same place and held you from making progress?
• Wind - what was helping you to move forward in the sprint?
• Island - what is the goal of the sprint or project, where are you heading to?
This will cover the step 3 in the process described above.
It’s a technique that helps to find out the root cause of an identified problem. During retrospective ask 5 times the question WHY something happened to understand what caused the issue. Then identify the action that will address the root cause. For example:
1. PROBLEM We haven’t closed 3 user stories with high priority.
2. WHY haven’t you closed those user stories? Answer: because we had several bugs raised (6 bugs for each user story, which is more than our average).
3. WHY did you have more bugs for those user stories? Answer: because we haven’t clearly understood acceptance criteria.
4. WHY haven’t you understood acceptance criteria? Answer: because we haven’t discussed with Business Analysts, that some is unclear, before starting the development.
5. WHY haven’t you discussed it with a Business Analyst? Answer: because we do not have a forum to ask such questions after the refinement is completed.
6. WHY don’t you have such a forum to clarify requirements? Answer: because we do not have it in our communication plan.
7. ACTION Add to the communication plan the Entry meeting to the user story. The owner of the user story (developer) sets up an intro meeting for each user story before he/she will start working on it. Developer invites BA, QE, and Developers who will work on this requirement.
You may wonder how to run retrospectives remotely. Despite the fact that we are working remotely now, due to the pandemic, It’s important to continue with retrospective, but move it to online meetings. Now it has become more important to use proper retrospective tools that will help to lead retro with an online team. There are plenty of tools available on the market, so everyone can choose what works best for the team.
Looking back at past events and taking actions for future improvements, it’s a crucial part of continuous improvement at each organization. There are some general tips that will help you to take your next retrospective to the next level:
1. Try to make this meeting fun and encourage people to actively participate.
2. Build an organizational culture that is open to changes and continuous improvement.
3. Don’t blame team members during the retrospective in front of other members of a team.
4. Ensure that you follow up on actions. It will be demotivating for the team if they will see that suggested improvements are parked for the future.
5. Manage the time of a meeting and shorten the discussions.
Enjoy your next project retrospective!
Need to develop a software project? Contact us!
Author: Marta Maciaszek
.jpg)