Open your calendar for next week and count the recurring meeting blocks. Then ask one honest question about each one: does this produce a decision, a learning, or a next action that wouldn't happen without it? Be truthful. Don't lie. I'm going to guess that for most of those blocks, the answer is no, and you already know which ones they are.
Right now, the loudest sentiment I hear in our field is framework fatigue. Teams everywhere say their Scrum events have turned into theater. I think that diagnosis is half right and half lazy. The events aren't the problem. The problem is that we stopped treating them as what they were intended to be, working sessions, and started treating them as meetings. That one word is doing the real damage.
So this week I want to give you permission to prune, or at least to change the way you use that word. And I want to give you a method that won't blow up your calendar to apply it.
The Word "Meeting" Is Doing the Damage
A meeting, the way I define it, is where information flows in one direction. Usually nobody decides anything, and nothing really changes. Sometimes we even have meetings before meetings. Some of those are still necessary. I'm not saying every meeting is waste. But I am talking specifically about your Agile and Scrum events.
The daily Scrum was never supposed to be a meeting or a status readout. It was supposed to be a working session: a short planning huddle where the team replans the day toward the Sprint Goal. The team should be getting together and planning the day's work. The moment that block becomes a one-way status report, it stops being a working session and becomes a meeting, and that's when people start asking why they're there.
"Why Are We All Here?"
Picture a daily Scrum. Nine people on a remote call, going around one by one: what did you do yesterday, what are you doing today, anything in your way? Managers nodding. Two developers clearly answering Slack on the other screen. Then somebody finally says it out loud: why are we all here? All of this could have been an email.
And they aren't wrong. That block of time just became a meeting.
Notice where this complaint shows up loudest: remote and distributed teams. A synchronous block across three time zones is brutally expensive, so they feel the cost immediately. But this isn't only a remote problem. Co-located teams have the same disease. Proximity just hides it better. When everyone is in the same building, nobody counts the cost of pulling eight people into a room to hear something that could have been shared over email or Slack.
Collaboration Was Never a "Scrum Tax"
Here's the deeper truth. Complex product development work is computationally irreducible. You cannot shortcut the shared understanding required across all the skills it takes to build something. Whether you run Waterfall, Kanban, Extreme Programming, Crystal Clear, or DSDM, that thinking has to happen somewhere. Scrum didn't invent the need. It just named the sessions and set a cadence for them, which is a good thing.
I've watched teams delete the working session, ship faster for two sprints, and then spend an entire quarter untangling code because three people built the same thing three different ways. The huddle was cheaper. I promise.
These aren't meetings. They're working sessions, and you need them regardless of how you choose to do your work.
Meeting vs. Working Session
A meeting is for consuming information. People show up, receive an update, and leave. One direction, low collaboration. If that's all that happens, a short document or a written read often does the job better, and gives people their time back. Time is the most scarce commodity we have.
A working session is the opposite. You put a cross-functional, skilled group in a room to brainstorm, diagram on the whiteboard, argue and debate a decision, and build shared understanding. That is generative. That is the work.
Leaders push back on this constantly: why are five engineers sitting in a room when they should have their hands on the keyboard? My answer is simple. Hands on the keyboard are not the same as progress toward a deliverable. Thirty minutes spent agreeing on one approach can save 2,000 lines of the wrong code. Less code to write, less to test, less to break, less to deploy, less to maintain later.
I'm not romanticizing your calendar. I've sat in plenty of working sessions that wasted everyone's time. The answer is to fix the session, not to pretend the work disappears when you delete the invite. It's still sitting there.
Default to the Left: The Async Continuum
One concept I love comes from Sumeet Moghe in The Async-First Playbook. The underlying spectrum was mapped by James Stanier. Picture a continuum. On the far left, fully asynchronous: a document, a wiki, an email, a recorded video, a chat. Moving right, it gets more synchronous until, on the far right, you have a live call or a room full of people.
Moghe's rule is simple: treat synchronous meetings as the last resort, not the first option. Default to the left, earn your way to the right. I don't know that I agree with it 100% of the time, but it's a good principle to wrestle with. What resonates with me is that we rarely create new things inside a meeting. The only thing that truly requires sync time is the generative part: building shared understanding and making hard decisions. Everything else (status, broadcasting, recapping) is just information, and it belongs on the async side of the continuum.
A synchronous block that's filled with information has become a meeting. And that's exactly why I think the framework-fatigue story is so often misdiagnosed.
Why Framework Fatigue Is a Misdiagnosis
The team at Easy Agile recently highlighted a shift away from heavyweight frameworks toward simplicity. We all want that. But read carefully. They're not advocating abandoning structure. They're advocating for the right balance: minimal viable process, minimal viable bureaucracy.
People aren't tired of working sessions. They're tired of working sessions that quietly rotted into one-way information exchanges. In corporate life we add rituals faster than we remove them. Adding is easy. Removing is a skill, and that skill takes courage.
The Scrum Guide hands us a standard for free here. The 2020 Scrum Guide says inspection without adaptation is pointless. If your event produces no change, no decision, no adaptation, then by the Guide's own definition it stopped working. So what's the real problem: the Guide, or you? It became a meeting.
The strongest teams aren't the ones with the most ceremony. They're the ones that get better at getting better. More learning loops, not more calendar blocks.
The Meeting Audit
Here's the practical model. I call it the meeting audit.
Once a quarter, put every recurring block on the table. Every single one. Don't do this alone. Run it with the people who actually attend, because they're the ones holding the evidence. Then judge each session against one standard:
Does this session produce a decision, a learning, or a next action that would not happen if we didn't have it?
If yes, that's a working session. Protect it. Defend it. If no, it has become a meeting, and now you have a decision to make.
Should It Be Synchronous at All? The Convo-Rel Quadrants
The next layer comes from another of Moghe's tools, a matrix that weighs what the session is for against how mature the team's relationships are. The first axis: conveyance (one-way information transfer) versus convergence (high-bandwidth discussion to build shared understanding). The second axis: weak versus strong relationships. That gives you four boxes, and each one points to a different answer.
The takeaway: a fully async default is the exception, not the rule. It's earned by a strong team doing one-way conveyance. Everywhere else, some live time still pays for itself, either to reach a decision or to build the trust that lets you go async later.
Two Rules: The Bezos Pre-Read and Consent
Two rules go with that. First, never start a synchronous discussion without a written artifact people have already reviewed. Jeff Bezos is famous for this: a short pre-read sent ahead of the meeting. The least prepared person can derail the whole discussion, and a pre-read can turn a 60-minute debate into a 15-minute decision.
Second, for many reversible decisions you don't need a room at all. Write a proposal, set a deadline, and let people raise objections.
Consent isn't unanimous enthusiasm. It means no meaningful objections. Silence, in that context, is a yes. We're professionals.
The Four Decays
When a session fails the audit, it usually falls into one of four decays, and each has a fix.
Status decay: information is shared, but no decision happens. The daily Scrum readout is the classic example. Fix: redesign around the next decision and move status to a written channel.
Comfort decay: everyone feels better afterward, but nothing changes. Fix: end with a committed action and a named owner.
Compliance decay: the session exists because the framework says so, not because the team needs it. Fix: reconnect it to a purpose, or reduce the cadence.
Zombie decay: nobody remembers why the meeting exists. We just show up. Fix: cancel it, right then and there, and watch what happens. If people miss it, bring it back better. If nobody notices, it died a long time ago.
Zombie meetings are usually somebody's pet, so canceling one is a small act of political courage. Do it anyway, and do it kindly.
Pruning, Not Clear-Cutting
Look at those four responses: redesign, reduce cadence, replace, eliminate. Notice that only one of them is a deletion. This is pruning. It's tending a garden, not taking a bulldozer to it. The goal was never fewer working sessions. The goal is to make sure the working sessions you keep stay working sessions and don't quietly slide back into meetings.
Your One-Question Experiment This Week
Don't run the full audit yet. Keep it small. Open your calendar and find the recurring block you dread the most. You know which one it is. Before its next occurrence, ask one question in the room:
What decision, learning, or next action does this session actually produce, and would it happen if we didn't have it?
Then stop talking. Look at everyone. Let them answer. If the room answers clearly in under two minutes, great. You've confirmed a real working session. If they can't answer, you didn't fail. You found your first candidate.
Don't cut it immediately. Write down what you heard and bring it to your next retrospective, in the open, with the people who actually attend. One named candidate, and a group hearing the question out loud for the first time in a long time, asked without blame, will accomplish more than any top-down calendar decree.
Every meeting on your calendar was somebody's good idea once. So don't stomp on the grave. Just challenge it. Continuous improvement means continuously evaluating where we spend our time, and that work never ends.
And remember: don't let everyone call everything a meeting. Some of them are working sessions, and they'd have to happen whether you practice Scrum, Extreme Programming, Kanban, or Waterfall. People collaborating are the secret sauce to your agility.
If you want to get sharper at running events that actually produce decisions, and at coaching teams through the courage it takes to prune the rest, that's exactly what we teach. Explore our upcoming classes and workshops and bring this thinking back to your team.