I am preparing to conduct a retrospective for my team at my current client site. To guide me, I have been reviewing notes from previous retrospectives I have either attended or led. In doing so, I have noticed an emerging pattern of behavior that can significantly impact the success of a retrospective. Here are a few key factors that I believe are most important:
Retrospective Belongs to the Team
Possibly the most important observation I’ve made is that retrospectives are only effective if they truly belong to the team. This means that only the team should attend them, and that only the team can set goals and decide how to follow up on them. In my humble opinion, management shouldn’t attend the retrospective, as they can cause interference, step in, or require metrics to be collected. At my previous client, several retrospectives I participated in were rendered useless because the manager kept cutting people off and dismissing their proposed goals without consideration. As a result, we never accomplished anything during those retrospectives.
Don’t Let It Become a Whine-fest
Retrospection involves inspecting and adapting by examining past experiences and using root cause analysis to identify causes and ways to improve in the future. However, if there is an abundance of negativity in the past, it can be easy to dwell on the negative without finding any real solutions. This can lead to unconstructive activities and bickering that leave the team feeling discouraged. To avoid this, keep the retrospective focused on discussing facts and observations, emphasizing that the past is only useful for drawing ideas from concrete experiences. Problem-solving activities should be the main focus, rather than poring over historical data.
Activities Are Better
Having sat in on hundreds of retrospectives, both with and without activities, I initially thought that the no-nonsense approach of simply discussing “what worked, what didn’t, and what to improve” would be effective, straightforward, and focused. However, my experience has shown that these were among the least effective. For one, I believe it keeps people locked into a “this is a meeting” mindset and discourages thoughtful engagement. In one organization I was in, they even used a Word document with headings labeled “What Worked,” “What Didn’t Work,” and “Action Items,” with the latter being tasks that the manager would enter into Rally Project Management and assign to individuals.
In my experience, activities often keep people engaged. During a meeting, someone can easily just sit in front of their laptop and stare at the projector. With activities, however, they are constantly involved and not given the opportunity to disconnect. Additionally, I find the lightheartedness (or even playfulness) of activities helps break down some unspoken communication barriers and encourages people to speak their minds more freely.
Pick Only One Goal
In theory, picking multiple goals sounds great, right? We’ve identified all these impediments and roadblocks in our team, process, or environment that really need to be addressed. Why don’t we just tackle ALL of them rather than ignore them so we can work on removing all of them? This is along the same lines of the theory that maximizing Work-in-Progress maximizes efficiency, and we all know that this often fails. Likewise, by maximizing the number of goals that you have for an iteration, you run the risk of context switching too much (not to mention all the focus you’ll already have towards the work you’re doing during the iteration) that the team will lose track and quite possibly not make any headway towards any of the goals listed.
To limit your team’s work-in-progress, select one goal for the team to focus on during the next iteration. Make sure to choose only one goal. It could be completed in one day or by the end of the iteration. Alternatively, you may make progress on it and discover in the next iteration that there are deeper issues that need to be addressed.
Follow Up
One of my biggest mistakes as a facilitator was failing to help the team follow up on their goals. I had assumed that I could let the team form a goal, work out how to accomplish it, and then let them leave the room with it to schedule into their iteration and complete it. Boy, was I wrong! Working towards a goal can possibly even grow future retrospective topics or uncover more serious or deeper issues the team needs to address. Failing to follow up can leave the team with a pile of incomplete goals or superficial goals that only cover up the issue. Therefore, it’s essential to recap on the goal that was formed as part of establishing historical data near the beginning of the retrospective and let it drive new ideas or delve deeper if it wasn’t completed. Often, incomplete goals that correlate to the iteration can be found. For example, if it wasn’t reached because there wasn’t enough time to work on it, maybe there’s not enough slack in the iteration?
Out of all the activities in Scrum, I believe the most important one is the retrospective. This activity belongs to the team, and it’s essential for them to inspect and adapt their process. The retrospective should not be something enforced upon them, nor should it be led by their manager. ScrumMasters should take special care when facilitating the retrospective. Ideally, the team should facilitate it themselves, but if there’s an absence of facilitation skills, the ScrumMaster might need to step in. However, it’s crucial to remember that the ScrumMaster is not a manager and should not dictate goals to the team. Stay neutral and avoid becoming the owner of a solution. The team needs to own the solution and make decisions about what needs to happen. If the team needs to schedule a task into the iteration, let them do it rather than doing it for them.
As a facilitator, it is important to remain neutral. When I facilitate teams, I avoid involvement and refrain from driving the discussion or offering solutions. Once, during a retrospective, someone asked for my expertise with Fitnesse to solve a recurring problem. Unfortunately, I offered solutions, but looking back, I should have suggested that they set a goal and seek me out for help when I had my developer hat on.
Additionally, when a team’s facilitator participates, they may drive the entire retrospective, even if they participate last, or team participation may fall on deaf ears. I once watched a friend facilitate a retro for our team and draw out a huge value map. After two or three people shared their thoughts on the cause, he would write out his own idea in the map without considering the team’s input. When I called him out on this, he was surprised by his mistake.
Overall, keep in mind that the retrospective is for finding solutions, not problems. Keep it on track, listen, and help guide the teams to introspect within themselves and find the solutions they need. Most importantly, let them make the decisions and, above all, use the retrospective as their own activity to improve.