Progressive Retrospective, Happy Engineering Teams
Doing retrospective the right way
As an engineering manager, you have to gauge your own and your team’s mindset and intention going into the retrospective meeting. How often are you having retrospectives 🕺🪩💃 for the sake of having it? you can assess it from the mood, participation and the kind of discussions happening in your team.
Retrospective is not a mere 💍 formality. If conducted well, it can be the MOST IMPORTANT ceremony in all of your team meetings 🤝. In this post, I’ll provide templates and share how to make your retrospective progressive from my experience and make it the most important ceremony of all.
Let’s start with mindset 🧠
Whenever your engineers come together to meet, you have to get the intention and mindset right to make that meeting successful. Have you checked with your team on their mindset and intention while in the retrospective meeting and what do they expect? - Are they feeling productive? Do they see the value out of that meeting? How do they bring up concerns without any fear and suggest improvements?
In retrospective meetings, discussions should be centered around continuous improvement in a progressive mindset. There’s no room for finger pointing, hiding the fact and casually coming in and going out without an intent.
As an engineering manager, you need to have a structure on how you conduct retrospective meetings promoting collaboration, transparency, driving continuous improvement and ownership.
Review last retro action items (spend 5 minutes) 🔍
Start every retrospective by looking into the action items committed in your last meeting.
Have you made any progress?
Did you see the intended change?
What is blocking your team in performing an action item?
Review sprint goals set (spend 5-7 minutes) 🎯
If you have a dedicated sprint review meeting where you review your sprint goals, that’s great. If not, you should take a look in your retrospective.
Start by reviewing high level goals that you set for that sprint and how well it has been achieved. If a goal is achieved, great - it’s time to celebrate. If it is not achieved, then you should dig deeper. Was it due to the fact that you’ve over-committed? Has your team been blocked by someone? Was it under-estimated? - Try to understand the root cause at this point and discuss improvements later.
Pro-tip 💡: Most probably, as an engineering manager, you should have a better understanding of what can be and can’t be achieved based on the progress and reviewing it mid-sprint. Once you identify it, it’s recommended to communicate to concerned stakeholders about goals that can’t be achieved and the new timeline.
Start looking into your team’s sprint JIRA board so that you shall discuss with your team on unfinished tasks, why and what could be the impact.
Burndown chart can be a great tool as well to understand where was the bottleneck, where it slowed down and what are the injections you had after you committed for a sprint.
Understand your team’s mood (spend 5 minutes) 😐
We use emojis or express how your sprint is in one word as an ice breaker activity before every retrospective and everyone shares their feeling short and crisp. As a manager this gives me a quick feeling around the room and prepares me to get into the core of the discussion.
Roses 🌹 Thorns 🌵 Buds 🏵️ (spend 25 minutes)
Here comes the core part of your retrospective meeting. To discuss what went well, what didn’t and what could have been better.
Roses 🌹 - What went well?
Thorns 🌵 - What didn’t go well?
Buds 🏵️ - What's something that should be developed related to the focus area?
Watering 🚰〰️ - What are the action items and person responsible?
Roses 🌹
What went well so far in your sprint? - Is it about good and productive technical discussion that happened in your team? Is it about timely delivery?
Don’t shy away in appreciating your teammates whenever they deserve a pat on their back and encourage your team as well to come up with all the good stuff that happened. Realization is the first step to become a progressive team.
Thorns 🌵
Thorns are the things that didn’t go well or that stand right in the middle, that’s affecting your team’s performance.
Are there too many injections or distractions that disturbed your team’s focus and flow?
Performing a code review takes nearly a week, which is not ideal
Requirement specifications weren’t complete and changed twice in the middle of the sprint
If the real thorns are not being discussed or brought up, it either shows your team is insecure about it or they don’t recognize something is a thorn at all or your team is totally awesome (I hope this comes true for your team one day).
As a manager, you have to come prepared with thorns that you observed in your teams and check whether those have been transparently discussed. You don’t have to bring up immediately in the retro, check with the individual in your 1-1 and get more clarity on why they don’t think that as a thorn. Either they have forgotten about it or they will come up with what they feel and why they didn’t share it in the retrospective setup. Ensuring them a safe space and guaranteeing their concerns will be discussed, will give them the confidence to bring it up in the bigger stage like retrospective.
Buds 🏵️
What could have been better?
Discuss about situations that could be better than now.
Could you have an automated CI/CD process?
Could you be unblocked if you raised your hand in a timely manner?
Could the design be well thought out to avoid to-and-fro unproductive discussions?
Always open for new opportunities and potential improvements that could take your team further on the right track.
Rose Thorn Bud Retrospective template: https://miro.com/templates/rose-bud-thorn/
Action items along with priority, person responsible (spend 5-7 minutes)
Plan action items for improving thorns and buds and turn that into roses. As a manager, advocate and create necessary space and time for you and your team to take the ownership and execute action items instead of dreaming about it retro after retro.
Bonus 🎁
Are you not part of retro? 🤔
In some teams, managers aren't part of retrospectives to make the environment and discussion to be more open, collaborative and fearless.
I'm sorry 🤷 to say that you're doing it wrong ❌.
If one thinks the manager should be out to let the team be more transparent, there's some serious culture issue that you need to address. To make it worse, there's no point in having a manager for the team and they can’t understand the team's concerns and challenges.
Instead:
promote full transparency, safe-environment and continuous improvement as the only focus instead of turning your retrospective into finger pointing 🫵, blaming 🗣️ and scary 😰.
When to have retrospective session?
End of the sprint - Typically retrospective are being done end of every sprint
Completion of a project - Retrospective can also be done end of a specific project where your team had quite some learnings and shall drive some improvements
Retrospective in the form of post-mortem for a technical incident
How long retrospective can be? ⏳
I believe in conducting meetings of 25-minute cadence whenever possible. With retrospective, I tend to finish it in 50 minutes. But it’s based on your team size and topics to be discussed. Sometimes retro can prolong for 10 more minutes which comes up to an hour. If it goes beyond an hour, I prefer to create a follow up meeting with only respective individuals so that we don’t stretch the retro too long. A meeting that goes beyond an hour takes a toll on participation and engagement. Be wary about that!
I’ve shared here few more insights on how to get your meetings right:
From your experience, how do you conduct your retrospective meetings, team’s mindset and how can you make sure you conduct a progressive retrospective?
I would love to know your thoughts.