Hey there again newsletter friends! Big week this week– I got to see coworkers in person for the first time in– something like two years? I'm still pretty happy working from home, but it's nice to have the option.

This week I want to take a minute to talk about how I assess retro quality, and how I use them as a proxy for the elusive "team health."

I often need to be able to quickly assess how a team is doing: its morale, its ability to solve problems, and the obstacles in its way to being able to solve those problems. I changed teams a lot on Cloud Foundry, and often acted as a sort of informal consultant to external stakeholders on those teams – giving leaders a fast assessment of the state of the team, and often why a particular problem they were having was so persistent.

Now I'm a consultant, and this ability is even more important. My exact role varies, but typically a big part of my job is providing senior leaders with a clear picture of what teams in the organization are actually doing, how they're spending their time, and what problems they're encountering. I'm often simultaneously building team capability to solve problems, and there really is no better way to do that than a good retro.

So "how are the retros?" is a big part of my onboarding notebook. (Which I've written about before, in "Why you need a 'WTF Notebook.'") In the first weeks on a team I typically be ask myself a handful of standard questions.

1. Does the team do retros?
2. Does the team generate action items in those retros?
3. Does the team complete the action items you generate in those retros?
4. Does the team delete action items when they realize they'll never get done, or aren't important?
5. Does the team address conflicts in the retro?
6. Does the team talk about the "real" issues in the retro?

It's been my experience that on my favorite teams, teams that are solving business problems and having a good time, the answer to all of those questions is "yes." They have retros, those retros are action-oriented, and everyone's comfortable enough disagreeing with each other that they can directly address problems that they're having. They're also moving at a fast enough clip and taking enough risks that they are having problems – they're trying experiments that not everyone is quite comfortable with, and then talking about how it's going and adjusting based on real feedback.

This is also the first basic set of changes that I'll try to make when I'm on a team in my building-team-capacity role, and in roughly this order. If they're not having retros, I'll suggest starting. If they're not generating action items, I'll suggest making some. If they're generating action items but they're still having persistent problems that's a trickier, but I'll start bringing my "let's make disagreeing with each other safe and fun" toolkit to bear.

If you've ever been on a team that was productive and happy that didn't have retros, or didn't have retros that match that description, do me a favor and reply to this e-mail? (Or write me at "nat at this domain," if you're reading this on the open web.) This has been so consistent that I suspect I'm just not seeing the alternatives!