This post was first published on VentureBeat.

Not too long ago, I noticed a lot of teams at my company rescheduling or cancelling retrospectives. Sometimes it was because key people were going to be out of office. Sometimes it was because a major deliverable was due and everyone was wildly stressed. Sometimes it was because the project wasn’t as far along as expected, and they wanted to wait for more data. Always it was because of something completely logical and understandable.

But it bothered me a lot.

I turned to the internet to back me up — to give me some “expert’s” opinion on why you should never move or cancel retros, that I could then send out triumphantly to our teams. Instead, I found a dearth of thinking on retro cadence and scheduling. Denied the collective wisdom of the internet, I was forced to look inwards to better understand why these scheduling changes bothered me so much. Is it just that I’m a compulsive rule follower who can’t handle change? Always a possibility worth examining. Were there things I wanted to say at these retrospectives that made the delay problematic? Not exactly, since as a team lead I get to talk plenty enough already.

As a manager, one of the things I have heard over and over again is to never cancel a one-on-one meeting with a direct report. If you have to reschedule, it should be as close as possible to the original time. Rescheduling and cancelling 1:1s is a sign to your reports that spending time with them is not important to you, and doing so should be avoided if you actually respect your colleagues.

The retrospective feels the same way to me. The person who reschedules it is probably a Product Manager or a Tech Lead, dutifully reviewing the schedule for the team and realizing there might be a problem. They invariably send a message to the effect of “Hey guys, this seems like a really bad time — anyone mind if we move it to next week?”

Which of you would raise your hand and say it’s not ok? I’m a fairly forthright person, and I’m not sure I would. It’s a tall order to demand the time of the whole team.

So what’s the big deal about retrospectives anyway? Are we all beholden to the Agile Manifesto, following the pattern just because it says to? I really hope not, and I can say from my experience some of the best innovations on my team have come from retros. To me, a retrospective is like a one-on-one for the whole team, and can serve the same purpose.

These are my favorite things about the retrospective format:

  • Enforced thinking time. We all spend our days running at top speed, so taking 15 minutes at the start of a meeting just to think about a topic is incredibly valuable. Taking time before the meeting would be even more impactful, but baby steps.
  • Ideas from each individual. The format encourages every single member to contribute to the discussion. The mix of written and verbal discussion affords avenues for people with different communication styles to all have their feedback heard.
  • Venting. In the same way that sometimes a 1:1 needs to be a blowing-off-steam session, group venting in a retro can be cathartic and much healthier than silent stewing.
  • Pulse taking. As a manager, some of my best sense of how the team is doing comes from retros. Teams are most healthy when every member has things to say, positive or negative, and is willing to discuss them out loud with the group. A retro with lots of things to “stop doing” isn’t necessarily a bad thing; one where there’s no constructive discussion probably is.

So you don’t want to cancel your retros. Rescheduling may sometimes be warranted. You are not likely to get great thoughtful ideas out of people who are stressed out and thinking about an imminent release the whole time. On the other hand, if it happens a lot, it can send a message that the team doesn’t value retrospecting (and probably is also oversubscribed).

I found that just reminding teams that retrospectives are a first-class calendar system was enough to effect positive change. Rescheduling will always happen, but it’s approached with more thought and consideration. My team realized we were actually in a format rut, so we decided to try the sailboat retrospective. Pro tip: It’s more fun if you add pirates.

Director, RWE Engineering
Cat Miller is director of engineering for Flatiron’s real-world evidence teams, which creates data products to enable clinical insight. She also raises llamas in her Brooklyn apartment and enjoys injecting falsehoods into autobiographical synopses.