Agility Requires Retrospectives

tl;dr: If you do anything as it relates to agile, make sure you're doing regular retrospectives...

My journey started in agile (as do most devs) through the lens of Scrum. Scrum includes various boilerplate meetings or "ceremonies". In my experience, they range from highly useful (e.g. retrospectives), sometimes useful (e.g. daily scrum, spring planning), to mostly useless (e.g. backlog grooming). I won't get into why I think the other meetings are or are not useful, but let's talk about why I have always found the retrospective the most useful.

To me, the core of agile is iteration. You try a thing, evaluate, then choose to keep it, modify it, or throw it away. Through this cycle, better practices can be introduced & improved, while less good practices can be dropped. This is why retrospectives are so important. It gives your team a chance to step back, look at the way the team is working, and make any necessary adjustments to your team's process. Any other agile meeting/ceremony can often be dropped.

But Bressain, how can we even attempt to call ourselves agile if we don't have a daily stand up? Sometimes you don't need a daily stand up. If your team mobs full time or you only have 2-3 members, you all know what's going on. Give me an agile meeting and I can give you a reason that you might want to cancel it.

This isn't an exhaustive guide on how to perform effective retros but here is what I've found that make retrospectives effective:

I start with weekly. If we need to skip for whatever reason, that's fine, we'll get it next week. When you go longer like bi-weekly, skipping can often mean going a full month or more between retros so you'll probably want to reschedule instead of skip.

This is easier said than done. You can encourage psychological safety by being vulnerable in front of your team or running activities that encourage vulnerability. Depending on the relationship your team might have with management, this could mean excluding them. If you're in management yourself, you may consider excusing yourself to encourage that safety (or at least work towards developing safety that includes you).

This is the time to work on the team. This is not the time to talk about product, bugs, or tickets you may be working on. If you feel the need to talk about these things, create another meeting to do so. If you run out of topics that concern team issues, or you don't have any to discuss, end the meeting early.

There are many ways to run a retro. I've had some success with switching things up with a game (there are many sites out there that can give you ideas such as my personal fav, Tasty Cupcakes). I've had pretty good success with Lean Coffee since it lets you get through many topics that people are interested in.

Really, you could say this about any meeting but your retrospective will run better if someone is facilitating it. That means making sure that topics are moving along, people are being heard (especially the quiet ones!), and action items are captured. It's helpful to start off with someone who knows how to facilitate a retro but I've found value in rotating the role so that everyone gets a chance to experience it. Maybe give the facilitator the ability to switch things up with various games or activities.

If a meeting doesn't result in any action items, was it worth your time? That's debatable but look for action items during a retrospective meeting. I like to start retrospectives with reviewing action items from the last retrospective meeting. If it didn't happen, discuss why in a non-confrontational way (otherwise you'll likely hurt team psychological safety). I think it's OK to try an action item again as long as there's a change (e.g. someone else does it, different approach, etc.), otherwise it's likely to fail in the same way again.

For items that were completed, I like to talk about how they went. Maybe it was an experiment that was time-boxed to a few weeks and the team needs to decide if they want to continue that practice? Maybe it was a task that needed to be done? Either way, discussing them, at a minimum, will make action items feel more powerful and encourage team comradery.

Like the tl;dr said, if you do any agile meetings, make sure you're doing your retrospectives. The more you do them, the better you'll get at participating in them. Through them you can change your processes so that your team is a well-oiled machine that can change as needed; y'know, being agile 😉.