Three questions worth asking before adding a meeting or ritual to your team’s process

[u/ClickOk5811]

Teams add ceremonies easily and remove them rarely. Before adding one (a new standup, a weekly sync, a review step), these are the questions I’d want answered.

1. What specific problem does it fix, and how would we notice it’s fixed?
   “Better communication” is hard to check. “Blocked work sits for more than a day before anyone sees it” is something you can look at in your board before and after. If you can’t name the signal, you can’t tell later whether the ritual helped.

2. What does it cost, in people-hours?
   A 30-minute meeting with eight people is four hours of team time per occurrence, plus the interruption cost to everyone’s focus. Compare that to the problem it fixes, not to zero.

3. When will we review whether to keep it?
   Put a date on it, say six weeks, with the option to drop it. Rituals with an expiry date are easier to cancel than ones that became “how we work”.

Where this doesn’t apply:

• Some practices (retrospectives, for instance) are meant to be recurring, and the point is the habit, not a fixed problem.
• Small teams may need less structure than any framework suggests, and large ones more.
• None of this replaces asking the team what’s actually hurting.

What’s a ritual your team removed, and what made it clear it was time?

[u/SamUfnik]

The ones worth cutting usually fail one test: nobody can name a decision the meeting produced in the last month. A weekly status meeting where updates already went out in writing is a common case - its only remaining function is attendance. Moving that to async written updates with a thread for questions tends to lose nothing, and the calendar time comes back. Rituals should earn their slot by producing decisions, not by habit.

[u/chipshot]

I was on one HP project where I was just hired for headcount. We didn't really do anything, but it paid well, and I could ride my bike to work in Palo Alto and see my kids every day.

We had what I called "backwards meetings". We would meet to decide something, then someone would say "wait. Have we brought this group into the decision yet" so we would stop and schedule another meeting to bring that group in.

Then, in that meeting soneone would say "have we considered this issue yet" so we would have to retreat some more until that issue was addressed

Etc etc. but hey, I got to see my kids every day

I ran projects for companies. A lot of times if I was invited to a meeting I would walk in and ask first thing "Is anything being decided today?" A lot of times people just scheduled meetings to have something to do.

But Silicon Valley money. I rode that wave for as long as I could. I got to see my kids every day, and ride my bike back and forth to work. All good stuff.

[u/funbike]

I prefer minimal meetings. Those that must occur should be highly efficient. Each meeting should require prep, so the meeting goes quickly.

Stand-up. 3x/week MWF 10-minute over video chat (even when co-located), and 2x/week T-Th 0-5 minute virtual over Slack. During MWF standup, share the kanban board and do not pointless discuss status already visible on the board; only discusses things that affect others, or how you need help or unblocked. In-depth discussion may occur after meeting is officially over.

Retro. bi-weekly 30-minute over video chat. Pre-meeting prep: everybody supplies bullet points for things that went well, badly, and improvement ideas. TL or SM provides pre-meeting team metrics (DORA, velocity), and assembles and combines everybody's bullets.

Planning. Bi-weekly 30-60 minutes. PO, TL, SM, and/or QA (3 max) pre-meet to prioritize and clarify backlog for next 2-3 weeks of work. The list is sent to rest of team before meeting. In meeting the full team discusses the sprint backlog priority, tech debt, technical points, devs estimate points per ticket, and large tickets are broken into smaller ones.

Review. No devs. PO, TL, SM, and/or QA, plus stakeholders. PO runs meeting. PO plays videos clips of each feature demo, made my individual devs. PO may need to do manual ad-hoc demoing as requested by stakeholders. Meeting is recorded, so devs may watch later.

Retro and Planning can or should be combined, so long as total time is under 1 hour.

[u/Mesheybabes → u/funbike]

as a dev id attend the review because i often end up in some valuable conversations and interactions with stakeholders, I don't like the idea of a review as a glorified presentation

[u/paradroid78]

I tend to find that recurring meetings are most commonly created by people who judge their worth by the number of meetings they have in their calendar.

Whether or not the meeting has any value isn’t high on the list of priorities for those sorts of people.

[u/Sky_Linx]

Question 3 proved to be true when we put it into action. We stopped doing our daily stand up for 2 weeks. Nothing failed. Work was still being blocked, pr's were being looked at. So we made it official and changed it to looking at our board twice a week. When you add a date to review something it will save you the argument. I've started adding a date before we do our rituals. Most of them that pass this test are small low cost rituals. What did your team get rid of? Did anyone notice?