If all Retrospectives are the same, you’re doing it wrong.
Scrum-aliciousness
There is no such thing as a perfect Retrospective — a one size fits all ceremony. Even in the midst of a global pandemic, with almost every team geographically dispersed and chatting through little boxes on screens, personality and team dynamics vary. We’re all remote, but we’re all different. There is no magic formula, no perfect set of questions for every retro (virtual or not).
For a while I thought there might be. I took hard stands around processes, convinced I could set up routines and patterns that fit everyone in a valuable way. It would be ideal, I thought, if every team at the company used the same retro format, same process, same cadence, same everything. This sounded great. We’d have consistent conversations, like-minded approaches to problems, and find out if multiple teams struggled with the same areas. Following a standard format and process would help management see the output for every team and what each team is learning. But, over time, my critical nature has correctly guided me back toward a more nuanced opinion.
Don’t get me wrong, I have first edition Jeff Sutherland and Ken Schwader trading cards, and the Scrum Guide is bookmarked on my phone so I can easily (and accurately) settle any debates on the subject. I’ve read books, gotten my certificates, and updated my LinkedIn profile proudly. I’m all in on Agile, Scrum, and all Scrum-alicious things. Want me to recite the Agile Manifesto for you? (Please, please don’t ask me to do that.)
These processes are proven. You can find plenty of examples of great Retrospective guides online. Big companies use them; small companies use them. They are tried and tested, and they work. But, they work for those companies and those teams. Being a big Agile fan is great, but that’s me. That’s not my dev team or any of the other dev teams at my company, Square Root.
While company-led initiatives are important and should be accounted for, individual teams have specific goals they strive for and specific performance indicators that matter to them. They have different focuses, different technical skills, different Product Managers, and oh yeah, hugely different sets of personalities. So why would we all follow the same Retrospective process? Why would every team use the same format and questions to uncover opportunity or discuss potential issues? The answer is: they shouldn’t. At Square Root, we empower teams (or Herds, as we call them) to set their own schedules, choose their own Agile process, and hold retros that work for them. There’s no independent Agile coaching arm that swings in to tell them how to do things.
Retro Languages
Some teams love process, they thrive on it. They want everything defined precisely, documented, and followed with rigor. Each team member knows what these processes are and how to carry them out. Temporary absence of a single team member or the product manager is largely irrelevant. The rest of the team moves forward without them.
For other teams, processes are just plain ole’ fine. They’re there. They work. Usually there’s a champion of the process, a Scrum Master or just somebody that knows Agile well and wants to keep the team in check. Everyone knows what to do and why, but love would be a strong term to use.
The two teams above, and all the teams that fall in between, speak very different languages — so why should every retro be led in the same language? Retrospectives should speak the language of that team at that time. The format of the retro, the style, the vibe of the individual running it, all of this should match the team. It should match how they talk and how they work and how they best interact. After all, it’s a retro for that team.
What about your geographically dispersed teams? This is important right now more than ever. Are location and virtual meeting technologies accounted for in your Retrospectives? A post-it-note exercise highlighting things that could have gone better during the last sprint could be great in a nice-sized meeting room with comfortable chairs and your entire team present. But, if one of your devs (or all) works remotely and another is at home that day, the post-it-note routine is going to fall a bit short.
So if your company has recently switched to 100% work from home due to the COVID-19 pandemic and your retro formats have not changed, you may have a problem. If your partially remote data engineering team’s retro has always followed the same process as your on-site UX team’s retro, you may have a problem. If all your retros are led by the same person, you may have a problem. Teams are speaking different languages. Those languages are always adapting with personalities, work dynamics, and the global landscape. Your Retrospectives must adapt.
Who Should Decide Retro Format
Let’s say you’ve come to the realization that every team is unique, and that every team needs its own unique retro style. Great! Well, who decides that’s the case or what format the team ultimately uses? The team decides for themselves. Full stop. Seriously, there’s not a whole lot else to add here. Every team should define and follow a retro that works for them and their goals. Influence and ideas from outside voices are good, but ultimately it is on that specific team to choose their path forward.
Goals, Goals, and Goals
Goals are what Retrospectives should be about. We can often get caught up in how a certain ticket was done, or what went wrong on that day we lost chasing an annoying bug. These recaps help the team reflect on what happened in the sprint, but they don’t speak to the team’s goals. Everything should come back to what you and your team are trying to achieve, even when the team likes to focus on a specific part of how the team does work.
For example, story points and tracking velocity are a huge aspect of Scrum for a lot of teams. Retrospectives for these teams are often centered around how they can maintain the same velocity while improving quality or maintain the same quality while improving velocity. Velocity is fine (not my favorite measurement). But why would a team want to increase velocity anyway? The answer should be tied to goals. The team’s focus should be on hitting goals faster and setting themselves up to potentially set more aggressive goals in the future with their new velocity.
Whether your team loves tracking velocity, thinks Sprint Goals are the only things that matter (!), or strives for the highest standards of quality every sprint, they should make sure to bring the conversation back to goals. At the end of the Retrospective, the question to answer is, “Okay, we’ve discussed a few things that can be improved. What are we going to do differently next sprint to better achieve our goals?”
Getting Meta with Your Retrospectives
Should you retro on your Retrospectives? Yes! Just like all other aspects of your team and processes, you want to learn and adapt. The same retro process you have followed for years may not work any longer — team dynamics change, goals change, people change. Sometimes you just need the jolt of energy that a new style or format can provide. Your retros need to change too.
When we get into a routine, it is easy to run through a process, wrap it up, and move on. Spending five minutes at the end of every other retro to discuss the retro itself can be a great learning exercise. If two of your team members are getting little to nothing out of your retros, you’ll definitely want to know that! If the retro process has a big gap in it, something that causes important aspects of your team’s work to get overlooked, you’ll want to know that too. Take a few minutes now and then to ask some questions and listen.
Alternatively, the Scrum Master (or whoever leads Agile ceremonies) can sprinkle in small or significant changes. At Square Root, we like to call these changes experiments and treat them as such. No change is written in permanent ink, and everything can be undone or modified at any time. Don’t be afraid to try aggressive experiments like pausing on Scrum altogether and using Kanban. This framework, I’ve found, is highly effective for injection or bug-ridden teams that want to embrace frequent changes to their near-term backlog. This may sound counterintuitive, to embrace this kind of environment, but again, it’s about what works for that specific team at that time for the goals you want to hit.
Running these experiments can be a fun way to mix things up and help reveal what works and what doesn’t work for your team. Remember, the team should be learning from retros to help better execute their next set of work, and the Scrum Master should be learning what retro techniques or formats best help the team. Not convinced? Just try it out. Experiment!
Sharing of Ideas
Retrospectives themselves should be isolated to the team. You’ll want a space where team members feel comfortable to discuss topics around process, people, and relationships. An open meeting that includes people outside the team wouldn’t invite this kind of atmosphere.
But, that doesn’t mean ideas from Retrospectives can’t be shared across your organization. What you learn about your retro process should be shared company-wide. Sharing this information can help generate ideas for other teams to try or shine light on areas other teams struggle with.
At Square Root, Product Managers regularly share topics their dev teams are working through and how Retrospectives address or don’t address these struggles. Ideas like “Kudos” — a quick five minute retro activity in which team members praise one another for achievements during the last sprint to help recap what was worked on — have started with a single dev team and spread to others. None of these changes have to be permanent. If you hear something another team does, try it out once, maybe twice. See how it goes and adapt. Be prepared for some of your experiments to not work perfectly. And don’t worry, there will always be another retro.
Let’s Take a Minute and Reflect
Okay, I’ve walked you through my thoughts. What’s next? Let’s pause and look back with a mini, Retrospective-inspired summary.
Ask yourself these questions:
- What did I like about this article?
- What could have been better about this article?
- What is one thing I learned from this article that I can take back to my team or organization?
- What do I wish this article would have touched on but didn’t?
Hopefully these questions sparked something for you to take away and apply in your role at your organization. Remember, a Retrospective should be what works best to make your specific team and goals successful. With a volatile global landscape, being adaptable and fitting the needs of specific teams is more important than ever. Always adapt, learn, share ideas, and try new things. And don’t forget to have a little fun.
Square Root is a diverse team in Austin, Texas building data-curation software for the automotive + retail field. Learn more about us here + see how CoEFFICIENT can help make your field more.
