How your team can reduce the scrum retrospective time
No matter what project management methodology your team is adhering to, continuous improvement should always be the focus. And the only way to achieve this is to get together regularly to discuss the project’s strengths and weaknesses. This meeting is called the sprint retrospective.
The sprint retrospective is the last thing done in a sprint and is the time when the team comes together to discuss the performance of individual members as well as the team as a whole. This is an important event for scrum teams since the focus of the agile methodology is continuous improvement.
Different companies call this meeting different names. Sometimes it’s called “sprint retrospective”, sometimes “sprint retro”, sometimes just “retrospective”. No matter what your team calls it, this event serves one purpose and that is for the team to reflect on their way of working, and to continuously become better.
However, the more you do something, the more it becomes a drag. When the team gets bored with this repetitive activity, the process can become dull.
Retrospectives doesn’t have to be a drag. They don’t even have to be long!
Here are some tips on how your team can reduce the scrum retrospective time to make your meetings more productive:
Pre-planning
There are some advice against planning retrospective meetings stating that the conversations during the said event should develop organically. After all, the Agile manifesto clearly states that responding to change should be given more importance over following a plan.
However, there’s just something very assuring to have a plan laid out even if it’s not needed.
If you are in charge of planning the retrospective, keep in mind that there’s a high chance that your team won’t be sticking to your “perfect” plan anyway. You will end up adopting the original plan heavily and adjusting it according to the team’s need as the meeting progresses. But having a plan that could be adjusted as you go is the best way your retrospective can accomplish its goals.
Follow the pattern
Diana Larsen and Esther Derby defined the good pattern on retrospectives as the following:
Set the Stage
Approximate time: less than 5 minutes
Setting the stage helps team members focus on the work at hand and this practice also contributes to setting atmosphere where people feel comfortable discussing issues. The facilitator can start with a simple welcome message and appreciation for people’s investment of time. He or she should state the purpose of the retrospective and the goal for the session.
Gather Data
Approximate time: 10 minutes
Gathering data creates a shared picture of what happened during the sprint. Without a common picture, members of the team tend to verify their own opinions and beliefs. Gathering data expands everyone’s perspective.
Data during this part of the meeting is categorized into two types: facts and feelings.
Facts:
Start with collecting the hard data. This includes events such as meetings, decision points, milestones, celebrations, adopting new technologies or any event that had meaning to someone on the team. Metrics is also considered as hard data and this includes burndown charts, velocity, defect counts, number of stories completed, amount of code refactored, effort data, and so on.
The facilitator can ask people to report verbally on data and events or use the team’s task board and big visible charts.
Feelings:
This is also the time when members of the team share their thoughts and feelings regarding the sprint. Some people don’t actively talk about their feelings about work unless they are encouraged to. Creating an organized way for people to open up makes it easier to raise topics that have an emotional charge. Emotional discontent doesn’t go away - it goes underground and saps energy and motivation. The only way to solve it is to voice it out and let others contribute their input on how to solve the problem.
Generate Insights
Approximate time: 10 minutes
This is the part of the retrospective where the team discusses what to do differently. The facilitator should lead the team to examine the data gathered and look for patterns that can lead to success. This is the time when the team thinks together and consider possibilities, look at causes and effects, and reflect about them analytically.
Decide What To Do
Approximate time: 5 minutes
At this point, the team has already come up with a list of potential improvements. However, there are times when the retrospective has developed a long list of changes that needs to be executed. But keep in mind that too many initiatives can overwhelm your ability to change.
It’s a good practice to focus on one or two improvements for the next sprint. The facilitator should help the team choose items that they can truly commit to and that will have a positive effect that is sustainable over a long time. .
Close
Approximate time: less than 5 minutes
The retrospective should close with an appreciation for the hard work everyone did during the sprint and during the retrospective.
The team should also decide how they will retain what they have learned during the meeting and how they can track the progress of the new practices they are about to implement in the next sprint. All the notes and visual records should be distributed to the team so they have something to look back to after the retrospective is over.
According to the Agile Retrospectives by Diana Larsen and Esther Derby, using this structure will help your team do the following:
- Understand different points of view.
- Follow a natural order of thinking.
- Take a comprehensive view of the team’s current methods and practices.
- Allow the discussion to go where it needs to go, rather than predetermining the outcome.
- Leave the retrospective with concrete action and experiments for the next sprint.
The Scrum Team of Today
Originally, the scrum framework of Agile project development was imagined for teams physically located together in the same office. But let’s get real, most businesses today have a few distributed teams that work on projects remotely. In fact, a survey found out that 57% of the respondents were having geographically dispersed teams.
What is a distributed team exactly?
As soon as your team is not sitting in the same office building to do your work, you are considered to be a distributed team.
Different companies have different reasons why they chose to have teams work remotely but most of them face the difficulty of coordinating their time-zones, building rapport, collaborating among different development cultures and not having all the benefits one can get when having face-to-face interactions.
It’s a good thing that there are online tools distributed teams can utilize to facilitate retrospectives. A good example is Fun Retro, a fun retrospective tool you can use for your regular sprint session to discuss what went well and what didn’t. You’ll be able to easily identify obstacles and discuss ideas for improvements that will allow you to move forward unhindered.
Tips for Distributed Team Retrospectives
The concept of a functional remote team is still a new one which is why there’s still a lot to figure out. Being on a distributed team is not easy but it’s also not as complicated as many people think! Your team has to make use of tools but the secret in working well with your team (distributed or not), is to focus on self and team improvement.
Here are four tips in making retrospectives with your distributed teams fun and effective:
1. Create a regular schedule
When working with a remote team, it is easy to push back meetings to prioritize other on-site issues. On top of that, coordinating calendars across multiple time zones is a nightmare! But by giving your team a regular time to get together, you are creating a setting ideal for effective collaboration.
2. Be nice
This might sound like such a simple advice but it really does make a huge difference. Even though you don’t see them that much, try to get to know members of your remote team and understand that they probably have a lot more going on in their lives than work.
You can even set up a casual group time outside your retrospectives just so team members can get together and chat casually.
3. Be honest
Retrospectives are pointless if team members aren’t honest in voicing out their thoughts and opinions regarding the recent sprint. Be truthful and also encourage other team members to share their feelings as well. Sprint retrospective is a safe place where team members can share their feedback honestly and everyone should be able to reveal difficult issues.
4. Make actionable commitments
During retrospectives, the team should determine measurable actions that they can implement in the next sprint for continuous improvement. For distributed teams, it’s important the actions are measurable. Again, choose one or two goals that would be achievable in one sprint. Focusing on too many improvements would make the team lose focus.