Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Which actions could be done in the Retros (- or, how could I guide the Retro) to turn the ceremony more attractive to the Dev Team?
Lately we've been just collecting what should be improved + what went well in the previous sprints, and this seems to easily turn the ceremony boring.
Would you have inputs on what could be done to turn this moment into something that could make the team more open/focused to give deeper/better inputs?
Indeed Retromat is very inspirational for spicing up the Retrospectives for your developers. But at some point I faced the same issue of minor effectiveness in my team -after one year of working together, after 20 retros .. - so I started as well to think about some solutions to get higher again the attention level.
Discussion was going not really somewhere so I thought to point out a Retrospective Topic.
Now I prepare the team, before the Retro, with a couple of Topics to discuss, maybe some issues we had, or some improvements that I see that are needed, but also the team can come up with topics. Plus I also leave the total freedom to improvise topics directly during Retro. That helped a lot to give new energies to the people.
I'd look at the 5-stage retrospective approach. Retromat provides a lot of different activities that you can use for each stage. Also, there should be experimental changes (usually limited to 1 or 2) that come out of the retro with a clear idea of what should improve. These should also be reviewed at the beginning of the next retro. As long as they are seeing valuable improvement coming out of the meeting, you should be fine.
Here are few suggestions, which you can bring together or one-by-one.
SUGGESTION 1: Bring awarding best team member of the sprint in your Retro:
SUGGESTION 2: Things that were identified in previous Retros (whether practices or procedures), try to gauge their improvement paths - Identify maturity level on a scale of 5 and make team to discuss it.
SUGGESTION 3: Identify wastes in the previous Sprint - This helps to understand why something is not necessary and make the Team to qualify it.
SUGGESTION 4: Discuss Customer Satisfaction Index/Factor from previous deliverables.
SUGGESTION 5: Bring innovation - Any change to an existing approach - Determine if there any new way of trying to do something, and implement them - Brainstorm.
SUGGESTION 6: Every 3-4 Sprints, show a 5 minute demo of the product before the 3-4 Sprints' and show the current one. (Maybe record a video of the product every Sprint-end). This actually gives great motivation to the Team as, with the speed in which things are delivered, people get less time to look at the path traveled.
The first step is to talk to the team. This is their time to reflect and improve. It's also an opportunity to look toward the future to find opportunities for change (and hopefully improvement). Make sure that the team understands the purpose and value of having this time, and see how they would like to use it.
Instead of just looking at things that went well and things that didn't go well, you can look at different types of retrospectives. When I facilitate a retrospective, I set aside about an hour. For the first 15-20 minutes, we go over past successes, pain points, and any other thoughts or comments. The last 40-45 minutes is more wide open, and may have a number of different activities.
Instead of just looking at a historical focus (what went well or poorly in the past Sprint), you can look at the future and identify some changes that the team feels comfortable making and introducing something new, or focus on one particular problem or success and try to fully understand it to either avoid or repeat it in the future, or invest the time to learn something new that can help the team's performance in upcoming Sprints.
Which actions could be done in the Retros (- or, how could I guide the Retro) to turn the ceremony more attractive to the Dev Team?
Here are some ideas you can try out:
Would you have inputs on what could be done to turn this moment into something that could make the team more open/focused to give deeper/better inputs?
One way to approach this is to ask better/deeper questions from them. Instead of "what would you like to improve", one could ask "what causes the most pain". Ask them what is the bottleneck in the current system (from receiving a feature request, for example, until it's used in production). Once they have cast their opinions, ask how you could find it out together and let them figure out how the metrics will be gathered. Ask them what's the most important thing they learned during the Sprint (not only at work) and request them explain it to the team. Draw some smileys on a whiteboard (e.g. sad, uninterested, and jolly faces) and first ask everyone to put their feeling of the Sprint there. When that's done, ask them how we could get more faces to the wide smiling direction.
The first question you and the team should ask, "What's the purpose of the Retrospective?" In Scrum, every event has a purpose. If there is no purpose, the event would turn into another boring meeting.
Retrospective need not be fun and surely need not be boring. In general, following are the stages of a Retrospective
From the Scrum Guide,
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
I recommend for the Scrum Master to read through the Agile Retrospectives Book
Simply, all what you needed to have is the actions to be done.
If you do not have actions associated with time then there is no need to have the retrospective.
Do not forget the time to be bound with the actions and the team members responsible for these actions.
