My experience (so far) with retrospectives

There is nothing I love more than when new people join the team, and we get to learn from their experience and routines. Such a major power-up for the whole company. So when two agile experts joined our engineering team and brought with them a zeal for regular retrospectives, I was all in.

Retrospectives (retros) are time set aside for teams at intervals to reflect on the last chunk of work. They can be set up at the conclusion of a sprint, after a planned amount of time, following a release, or to address a newly discovered issue.

We had experience running post-mortems, but retros were a new for us. They aren’t easy, and we’re still getting the hang of it. Pro tip: having team members experienced with retros champion and shepherd the process has helped us climb the tough learning curve.

As pilot teams share out the benefits, retros are spreading across all groups (in and outside product development) at Wistia. Couple of my takeaways so far:

The purpose of our retros is to support continuous improvements. Regular retrospectives are a space for teams to reflect on what went well in the previous iteration, what didn’t go well, and identify actions to commit to for improvement.

Before retros, change came in two distinct flavors. First, the top-down perspective, which was focused on “high-impact”, big honkin’ changes across all teams. Second, the individual teams perspective, which was mostly local optimizations. We didn’t have a process for spreading learning across teams, having individual teams drive larger process change, or a way to address frustrations with our overall operating model. Some teams worked well, and others didn’t.

Retros give team members a structured way to discuss what they struggled with, or what they wish had gone better. Through discussion and root cause analysis, the team can identify what works, and what really needs to change, rather than limiting their scope to their sphere of direct influence. This means lots of local experiments, and also much better two-way communication about broad operating model changes.

Humans not well trained to look backward. Our brains work on a constant treadmill, where what we’ve accomplished looks small and trivial, safely ensconced in the rearview mirror. What looms large and important is what’s ahead.

Looking forward is important (look out for that lion!), but setting aside time for reflection is incredibly valuable when developing digital products. The possibilities of what we could do are nearly endless. Our shared to-do list stretches into forever. Through taking a breath and looking back at what we’ve built together frequently, we get a better sense of priority, evolution, accomplishment, and learning that comes from putting product in front of customers and iterating on it.

The facilitator plays a large and small role in retros. When done well, they should speak infrequently, but their efforts in setting up the activity and prodding conversation along (especially in tough moments) can be make-or-break.

In a shortsighted attempt to support our fledgling retros practice, I tried to run several retros in a single day. I was rushed, and the outcome showed it: activities were sloppily managed, outputs were lost in the shuffle, sessions ran over time.

Luckily, the team jumped in, and we’ve built a group of facilitators who can plan activities, run retros, and support teams in choosing action items — in addition to their regular work. This means better retros, but it has had some outsized (and unplanned) benefits as well.

Acting as a facilitator exposes them to work going on across the company at a deeper level. It shares context around our major wins faster. Facilitators bring experimental practices back to their teams. It exposes them to raw emotions and challenges across teams, which fosters stronger relationships. It knits us closer together, and the facilitators and even more invested in the success of our company.

Successful retros are completely focused on the team. All inputs comes from the team members, and they fully own the outputs as well. The simple act of asking “what went well?”, “what didn’t go so well?”, and “what do we want to do about it?” gives teams the power to amplify what’s working and solve their own problems.

Working together to build new things is hard. Friction of any kind can kill momentum — but when it feels out of your control, it’s the worst. Having a reserved venue to talk about sources of friction openly and scheme on how to take action gives the teams control back. It means we evolve our processes, both big and small, in an intentional and energy-giving way.

Trust is the most valuable commodity for a team. Retros are chock full of moments of both accountability and vulnerability, which are building blocks for increasing trust.

We trust the facilitator to put in the work to run a useful session. We trust our team members to support a safe space, where feedback and emotions are in service of improvement. We review the actions we agreed upon in the last retro, to make sure there was follow through. We talk through problems with the work, allowing ourselves to be vulnerable and trusting individuals come from a place of good intentions.

Making this process habitual creates a flywheel of trust, which improves the work environment and culture dramatically. I’m not gonna lie — the first time through a retro can be tough. Just stick with it, and in no time you’ll feel team dynamics improve (along with process, performance, and effectiveness).

Interested in adding (or improving upon) an agile retrospectives practice? Here are a few resources we refer to often:

Let's figure it out together.