BearCode

consulting

One of the biggest challenges I've seen across dozens of clients is the inability to change behavior, and why would they when the status quo is so comfortable. I can name countless excuses I've been given for this over the years, but at the end of the day, excuses don't drive change and certainly won't help things get better. We all get caught in the same cycle of feeling personally responsible for our team's challenges and defending our action, or often inaction, rather than seeking solutions. How do we get past this? One method, is to take a step back from the situation and approach the opportunity to identify successes and failures as a team exercise rather than a focus on one individual's successes or failures. Conducting a team retrospective can be an effective approach to building trust, identifying opportunities for growth, fostering a culture of continuous improvement, and instilling a sense of accomplishment in teams who have been struggling and stuck in a repetitive cycle.

What is a team retrospective?

The retrospective meeting, also referred to as an agile retrospective, sprint retrospective, or simply a retro, is an opportunity for a team to reflect on their wins and loses over a designated period of time. The final output of the retrospective is an agreed upon list of the successes of the team as well as their areas of opportunity. The team reaches consensus on these by brainstorming, refining, discussing, voting, and making final changes to their list. The end result should be a team that is in agreement on how they've succeeded but also where they need to continue to focus. Bear in mind, that while the retrospective may have traditionally been intended for a scrum team, I've found this to be an effective and critical meeting for any team to adopt.

What retrospective techniques are most effective? What makes a bad retrospective?

One of my favorite topics with new teams is what makes an effective retrospective. I've seen many failed retrospectives, some of these used standard sprint retro templates, others used creative HR generated "lessons learned" methods. Why do these fail? Because the template is simply a tool, and similar to our other articles, we've learned from decades of experience that there is no one size fits all method. Sorry I can't make it easy, but like every challenge, there is always a need to tailor the solution to the team. The key is to not give up on first pass, keep tailoring your approach until you find the tool that works for your team.

Some of the most common reasons retrospectives fail:

With all that said, I've witnessed a number of crash and burn retrospectives. To help you avoid potential pitfalls, I've laid out below some of the most common reasons I've seen retrospectives fail.

• Lack of Psychological Safety: Psychological safety is a belief by an individual or team that you won't be punished for making a mistake. When you are asking a team to bare it all, laying out their failures in detail to work toward improvement, the team has to trust that this won't be used against them. Without some sense of psychological safety, the team can't be fully honest which reduces the efficacy of the retrospective. You'll find that many of the failure themes that follow tie back to psychological safety.
• Audience: The audience of your retro is critical to achieve meaningful findings. If you have a true scrum team, it's simple, but with all other teams, the retrospective audience needs to be tailored and carefully managed. My general rule of thumb for a recurring retro is to include team members who collaborate with one another on a week over week basis, no external parties should be involved in the retro and certainly no leadership or outside parties if they are not a core member of the team. Keep in mind that the goal of the retro is for the team to identify their wins and failures, not for it to be pointed out to them by a leader. We also want to encourage psychological safety, which means not including anyone who could sabotage that. I've often had HR ask to attend retros, a definite no, no, as well as well-intentioned executives who I've had to politely decline.
• Facilitation: On true agile teams, the retrospective is run by the scrum master. My definition of a "true agile team" is an article for another day, but for now, let's address who should facilitate this session for non-scrum teams. The key to good facilitation of this session is to ensure the team achieves their goal of completing the retrospective fully, with a list of action items to work towards beginning immediately. This individual may help ensure follow-through by tracking actions in a centralized location, or taking action items themselves. The facilitator may be a leader or a PM for the team, so long as they do not interfere with the team's psychological safety, this is ok. The facilitator is generally also a participant in the retro, as they should be a core member of the team with a perspective on what's worked well and what hasn't. The final element to being a good facilitator is to ensure that the session remains a productive group discussion. There shouldn't be hostility towards an individual or infighting within a retrospective, facilitators should encourage honesty and transparency while keeping the peace and guiding the team towards solution.
• Structure: Without structure and time-boxed activities, a retrospective can easily slip into a general complaints session. While sometimes valuable for teams to blow off steam, it is not an effective retrospective. An effective structure goes hand in hand with facilitation, as the team needs both the guardrails to operate within and someone to guide them back on course when necessary. Before the retrospective, the facilitator should define each topic and roughly time-box these with flexibility to adjust during the session. If team member's veer off topic, or if one member begins to dominate the conversation, it's the role of the facilitator to bring everyone back, while ensuring the team does not spiral or lose focus on the goal of the retrospective.
• Consistency: Like any habit, consistency is key. I have yet to introduce agile concepts to a team where they are thrilled to try something new, the one constant in my experience has been doubt and skepticism. But with consistency, I've not seen a single team that hasn't grown from this activity. Remember that change isn't easy, and your team will not see results overnight, this is a commitment to work in a different way which requires time and practice to build. You'll read below that the retrospective takes time, so define a cadence that will work for your team to not rush the process. That might be every week, every 2 weeks or every month. I'd recommend somewhere between the 2 and 4 week mark.
• Insufficient Time: A good retrospective takes time! It's imperative to not rush the retro as the most critical element of the activity is the final outcome. Tailor the time to your team but aim for 1-2hrs for this activity. Remember that your team will get better at this over time, don't skimp on the first retro as this is where you'll need the most time, feel free to reduce as the team gets the hang of it.
• Action Items and Follow Through: Without clear action items, ownership and a timeline to complete these, your retrospective will provide little to no results. The brainstorming work to list successes and opportunities is only the foundation of this effort. The real value in the retro is the follow-through that happens after the session ends, and the growth the team is able to measure from retro to retro. 

Can I use a retrospective as a one-off event for a leadership or program level team?

You may choose to run the occasional session for a program team, a leadership team, or even a temporary team. Everything outlined in this article would still be valid for these teams, with the understanding that you will need to tailor the audience, facilitator, and frequency of the retro depending on the situation. Below, are a few examples of how to leverage a retrospective for other groups:

• Leadership retrospective: When I ran a consulting practice, I was responsible for leading client teams, our consulting practice and my consulting leaders. Each of my leaders was also responsible for leading their client teams and a team of consultants. In this situation, I treated my leadership team as another cohort, leveraging many of the same ceremonies as a scrum team with a modified schedule which better suited our needs and schedules. Our leadership team chose to incorporate a retrospective into our quarterly leadership review. In between the quarterlies, we would meet every 2-3 weeks to discuss ongoing priorities, including progress towards our committed action items. Leadership teams are generally balancing a lot and meeting monthly for a retrospective is simply not feasible. Tailor your series to accommodate for these constraints without sacrificing on the benefits. Lightweight checkpoints are typically more effective for a leadership team to ensure continued progress without the burden of a long meeting.

• Program retrospective: I've worked on massive programs with issues that are shared broadly across the organization as well as localized to specific teams. When running a retro for a program, the key is to break the program team up into smaller team retrospectives. Teams should still be organized based on previously outlined guidelines, with a maximum recommended group size of 8-10. Action items which are identified for other parties or leadership (outside of the team) will be identified and often assigned to the facilitator to act upon. Perhaps the team will ask to run a retrospective with another team that they are struggling to partner with, the facilitator can help with this. Or the teams may identify a laundry list of actions for leadership to address - in a case like this, I'd suggest the facilitators come together to summarize actions for leadership, and run a session to prioritize and gain commitment on each of these. Facilitators or leadership can then report back to the program on their action items and steps to address.
• Temporary team retrospective: Have you heard of a tiger team? Or action committee? When a small team is pulled together for a brief period of time to drive quick results, it is imperative they gel quickly. In these situations time is of the essence, and challenges need to be addressed sooner rather than later. In a situation such as this, I'd recommend more frequent retros between 1 to 2 weeks apart that are shorter in duration. The target of each retrospective should be to identify 1-2 critical areas of opportunity to focus on for the next period.
•  

Which retrospective template should I use?

There are many templates out there for team retrospectives, my personal favorite is the sailboat retrospective which you can find on Mural, Miro or through a quick Google search! While it may be my most used template, it's not the only one I've used and I love to experiment with new templates. Remember, there isn't a one size fits all solution for all teams. The template is not as important as the outcome: a team which feels heard, and can see positive change occur as a result of their willingness to be open and vulnerable with one another.

Articles in this Category