Building Teams Through Retrospective Feedback
As part of Scrum, a retrospective meeting (“retro”) is held at the end of a sprint to look back on factors that affected the sprint and provide feedback, good or bad. The purpose is to learn new lessons and take action to adapt in the future. My belief is that the retro is as important as 1-1s with your manager for career growth and business impact.
A retrospective can serve to improve the processes within an organization and to share personal lessons learned. Used correctly, it’s a tool to transform an average team to a high-performing team. Even if there are no changes made to the organization or its processes, the insights gleaned from a retrospective allow each individual to have a deeper understanding of team dynamics and how it affects team performance.
Retrospective Structure
A retrospective usually starts off with some dedicated time for individuals to write out their feedback or insight, then someone (scrum master or team lead) reads through the feedback. At times, the individual who wrote the feedback may provide more context, or brainstorm on what the impact is and how to adapt for it. Although the written feedback is always visible to everyone, the author of the feedback may be anonymous depending on the team.
Depending on how frequent retros are held and how much the team participates, I’ve seen retros take as little as 10 minutes, or as long as 4 hours (even on a Friday afternoon).
Feedback in a retro is usually categorized as one of the following:
- What to stop doing: List things that didn’t go well
- What to continue doing: List things that went well, or at least well enough to continue trying
- What to start doing: List action items that may improve the workflow. Depending on the team culture, this can be prepared by the feedback author or decided by the team during the retrospective.
What I don’t see enough of is a Kudos section, where the team mentions positive actions or accomplishments by their team members. I find that it’s not very natural for people to explicitly give positive feedback on the spot, or for people to track their own accomplishments. A Kudos section where this is mentioned can boost team morale and provide a trail for you to track your own accomplishments when it’s time for performance reviews.
Effective Participation
Most retro participants speak the most when it’s their own feedback being discussed. It’s important to be ready to discuss your feedback in more detail than what’s written on the board. Similarly, if you have questions or insight on the feedback that someone else provided, you should speak up to help push the dialogue further.
The following sections provide some advice on how to prepare good feedback.
Prepare Feedback Early
It’s difficult to think back and mentally summarize the good and bad parts of the past sprint on the spot. Instead, I encourage having a local notepad where I write down whatever happened whenever I feel an intense emotion - good or bad - complete with the raw emotions.
I might bring up the positive points as-is, or tie them in to something that a teammate had done so I can give credit where it’s due. For the negative points, I definitely spend the effort to rewrite the feedback in a more professional tone by removing the subjective parts and focusing on business impact.
Why even write the emotions in the first place if I’m going to erase it later? First, I keep the emotional feedback for myself so that I’m privately reminded of the importance of this feedback. Second, in the moment of frustration, it helps me to write out the emotions in a safe environment, especially knowing that I’ll eventually get an opportunity to try to improve things. Third, polishing and refining emotions into a coherent business impact is difficult. I don’t want to spend too much time away from my active task.
The next point discusses more about emotions and how to express them clearly.
Tie Emotions to Business Impact
We are all human. We all feel emotion, and most of us have our performance affected by our emotions. As such, it’s important to manage and maintain a positive emotional state.
Most emotions can be tied to a business impact, in which case you should provide feedback on the business impact instead of the emotion. Other times, there may be no externally-visible business impact. These emotions may be better left to yourself. While emotions are objective (no one can claim that ABC didn’t make you feel DEF), they may not be universal (someone else experiencing ABC may have felt XYZ instead). If an emotion is discussed outside the context of a business-impact, the conversation is likely to steer into personal issues, and a 1-1 with your manager is a better forum for that.
Don’t Require Solutions
There’s a saying: “Don’t bring me problems, bring me solutions.” This mentality is flawed and does not apply to retros.
While people usually appreciate being handed solutions on a silver platter, we do not always have all of the answers, nor are we aware of all of the resources we have at our disposal. Just as we are willing to help others, we should be able to rely on our team to help us solve issues that we’ve identified. As such, if you notice a pattern of issues, you should bring it up even if you don’t have a solution. Frame it as an insight. Declare upfront that you don’t have a solution and are only sharing your findings to open up the floor for others to share their insights and brainstorm solutions.
With that said, there is a subconscious limit to the number of negative insights you can bring - don’t start talking about everything that went wrong and expect others to solve your problems for you. You need to give a genuine effort to finding a solution before giving up, or you’ll fall into the venting trap (discussed below).
Don’t forget that some problems don’t have solutions. There are tradeoffs in every decision, and each decision or team has disadvantages and weaknesses naturally characterized by its advantages or strengths. It’s still worth bringing these up as insights, so that the team is aware of the tradeoff and can pivot to another strategy if a different strength-weakness pair is more suitable for the business.
Grouping Feedback
Often, multiple people in the team may run into the same issues and raise different items about it. Or, you, yourself may experience multiple issues from the same root cause.
In these cases, it’s important to identify and state the root cause, then group the different retro items as results of that root cause. This strengthens the argument to solve the core of the problem instead of trying to fix each problem individually. It also reduces the mental overload of having too many retro items to go through.
Personal Lessons
Depending on the team culture, a retro can be a place for individuals to share their own lessons learned. For example, if a developer begins developing code using Test Driven Development, they may share their experience, good or bad (hopefully good).
This requires some personal vulnerability and openness, but can pay off if it helps the rest of the team learn from your mistakes. It can also increase the teams psychological safety for others to eventually share their own lessons.
Ineffective Participation
The following points discuss some items that I find to be counter productive and should not be mentioned in a retro.
Do Not Vent
As discussed previously, it’s important to tie emotions to business impact. If there is no visible business impact to your emotions, it may be self-incriminating to mention it. While any good person strives to get along with their teammates and maintain a positive environment, it is not your job to manage your colleagues’ emotions and vice versa.
Do Not Point Fingers
As humans, we will always make mistakes. We may also be mean, vengeful, selfish, or incompetent. However, the retro is not a place for these things to be brought up. Remember: a team of high performers is not necessarily a high performing team. However, if there is a common pattern of mistakes being committed, especially by multiple team members, then this is a sign that there’s room for improvement, and it’s worth mentioning.
Tie those common mistakes or difficult procedures to potential avenues of automation or structural changes to prevent those human errors from happening. Do not point to the person(s) and blame them for making the mistake. It could have been you.
The retro is not a place for public shaming.
Examples
The following are some sample scenarios you may encounter that may be worth bringing up in a retro.
Single Person Bottleneck
Consider a situation where there’s a single person, like a tech lead, who is responsible for all code reviews, or all decisions that need to be made. The team is growing at a fast rate, and is double the size it may have been a year ago. The tech lead cannot keep up. The code review queue piles up and the quality of the reviews goes down. You submit a critical code change, but it doesn’t make it in on time because of the long queue. This is an emotional moment: write it down.
In this situation, refrain from pointing fingers at the tech lead for not keeping up with code reviews, even if you know they are slacking off. Focus on the procedural problem: there’s only one person responsible for the performance of the entire team. This is a single point of failure, and is a bottleneck for the team.
You can write a retrospective comment saying that code reviews have been piling up, and that it seems to be too much for a single person to handle. Potential action item: change the code review strategy to allow other approvers.
Miscommunication with Director
Consider a situation where you were told to work on some new minor feature as requested by someone at the director level. You were briefed on what it should look like, and got to work. Two weeks later, you deliver the feature, demo it to the director, and are told that it’s not what they expected to see and that you should trash it. You feel upset that they were unclear from the start, that all of your effort has been discarded, and possibly that you’ve been set up for failure or that you’ve been disrespected. Write down all of the emotions in a private notepad, and revisit it later.
Before bringing this up in a retro, ask yourself some of the difficult questions. Did you really have a good understanding of what the director wanted before you set out to work? Did you have opportunities to follow-up and ask questions once you began, or did you only synchronize with them at the beginning and end? Did you try to synchronize with them but didn’t have any opportunity to do so? Or did you ask questions but still got vague answers? How often does the director request changes like this?
If you tried to synchronize with the director but weren’t able to, and this type of issue happens often, then this is definitely worth bringing up. A potential action item could be to standardize new feature requests.
If you did not try to synchronize with the director at all, then this can be shared as a personal learning experience - you’ve learned the hard way that there needs to be tight feedback loops between the requestor and the designer.
If this is an issue that just happened for the first time, once again you could mention it as a personal learning experience - but it’s probably not worth spending too much time on it if it’s unlikely to happen again.
Team Size Change
Some problems are inherent in the tradeoffs we make, and don’t have easy solutions.
Consider the case where the entire team meets up for a 30 minute standup meeting each morning. You hear status updates from the entire team, including people who are working on stuff that’s completely irrelevant to you. It feels like a waste of time. Some people have been consistently bringing up the long standup meeting times in each retro, and so the team is finally split into 3 teams - each having 10 minute standups now. Two months later, one of the three teams does something that takes the other two by surprise. The one team forgot to communicate it to the other two, so everyone is upset.
You can try bringing up the lack of communication between the 3 teams. The solution to that might be to combine the three 10-minute standups into a single 30-minute standup: but this was the issue that caused the teams to split in the first place. Perhaps things were done the right way in the first place, and everyone should have accepted having long standup meetings every day. You’re not sure.
In these cases, I find it worth bringing the issue up so that it can be discussed. As a result of the discussion, at the very least, each team member will have a stronger understanding of team dynamics and of the value of communication.
Perhaps one of the team members will know of a solution that enforces communication between the teams when there is a change that impacts everyone. Or perhaps they will come up with another solution. You don’t need all the answers, but you do need to sit down and have a discussion about the problem at hand.
Closing Thoughts
Retrospective meetings are a form of feedback that helps a team self-organize and self-manage. Without that feedback, the team may not know which of their actions or processes are speeding them up and which ones are slowing them down.
At the very least, retros help us, as individuals, to learn about ourselves and about interactions in the workplace. Even if a solution to a problem is not found, sitting down to have the discussion goes a long way to helping us develop our careers.