↓ Skip to main content
eval ( code )
  1. Dev Handbook/

🥁 Rituals: Not Every Team Needs Every Meeting

Table of Contents

Every team has meetings. Not every team has rituals.

The difference is intent. A meeting is a block on the calendar. A ritual has a specific purpose, a consistent format, and a clear signal for when it’s working (or not).

In this section:

Only adopt a ritual if you know why you need it
#

Rituals should exist to solve a specific problem. “We do standups because that’s what agile teams do” is not a reason. “We do standups because people kept working on the wrong things and we needed a daily alignment check” is a reason.

Before adding any ritual, ask: what problem does this solve? If you can’t name it, you don’t need the ritual yet. You might never need it. A two-person team shipping a prototype doesn’t need iteration planning. A team that’s never missed a deadline doesn’t need formal estimation. That’s fine.

Rituals can be major time wastersA bad ritual is worse than no ritual. A 30-minute standup that nobody finds useful costs your team 2.5 hours per week. Multiply that by a few more ceremonies and you’ve burned an entire day of engineering time on meetings that exist out of habit, not necessity. If people are dreading a ritual, or if nothing changes as a result of holding it, that’s your signal to fix it or kill it.

If a ritual stops being useful, change it or drop it. Keeping one out of habit is worse than not having one at all, because it teaches the team that their time doesn’t matter.

The rituals in this section are the ones I’ve found essential for remote teams. You don’t need all of them, and you definitely don’t need to run them exactly the way I describe. But if your team is struggling with alignment, delivery, or morale, chances are one of these rituals is either missing or broken.

Each ritual page covers three things: what the ritual is for, how to run it, and what it looks like when it’s going wrong.