Not too long ago, I noticed a lot of teams 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 crazy stressed. Sometimes it was because the project wasn’t as far along as they thought it would be, and they wanted to wait for more data. In each case, the retrospective was cancelled only because of something deemed completely logical and understandable.

But it bothered me a lot.

I turned to the internet to back me up—to give me some context as to why retros never should be moved or cancelled that I could then send out triumphantly to our teams—but instead I found a dearth of thinking on retro cadence and scheduling. Denied the collective wisdom of the internet, I was forced to look inward 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? That’s always a possibility worth examining. Were there things I wanted out of these retrospectives and was annoyed to have delayed? Not exactly, since I wasn’t actually participating in any of them, but that was a bit closer to the reason.

As a manager, one of the things I read over and over 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 one-on-ones is a sign to your reports that spending time with them is not important to you, and 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. He or she invariably sends 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 pretty forceful 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, and 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.
• Individual contributions. 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 one-on-one needs to be a blow-off-steam session, group venting in a retro can be cathartic—and much healthier than silent stewing.
• Pulse-taking. 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.

While it’s helpful to understand why retrospectives are so vital for the health of your team, it still doesn’t explain why it’s such a big deal to reschedule. Well, maybe it isn’t. You are not likely to get great thoughtful ideas out of people who are stressed out and are staring at their laptops the entire time. On the other hand, if it happens a lot, it can send a message that the team doesn’t value retrospecting (and probably also is oversubscribed).

I found that just reminding teams that retrospectives are a first-class calendar system was enough to effect positive change. When push came to shove, my team wasn’t deprioritizing retros, but we realized that we were actually just in a format rut, so we decided to try the sailboat retrospective. Pro tip: It’s more fun if you add pirates.

About the Author/ Cat Miller

Cat Miller is senior software engineer at Flatiron Health. She received her Bachelor of Science degree in Mathematics and Master of Engineering degree in Computer Science, both from MIT. Connect with her on LinkedIn.