Agile, Scrum, and Kanban principles for better meetings

The useful insight in Scrum's four events is not their names. It is that each has exactly one purpose and a hard time limit, which means nobody has to decide what the meeting is for — and the most common defect in a non-agile calendar is precisely the meeting that has quietly become three meetings wearing one invite.

The distinction between review and retrospective is the one non-agile teams collapse most often, and collapsing it costs both. A meeting that begins with a demo will spend its remaining time on the product and never reach the process, because the product is always more urgent. If you adopt one ceremony, adopt the retro — it is the only meeting on the list whose job is to fix your other meetings.

Every Scrum event is timeboxed, and the sprint itself is a timebox around the work. The rule is that the box does not extend: when the time is up, the event ends, finished or not. This is what makes the estimates in planning honest and the standup 15 minutes rather than 40.

Three things follow when you apply it to ordinary meetings:

• Box the agenda item, not just the meeting. "Ten minutes on this, then we decide or we defer" is the enforceable unit. A one-hour box with no internal structure is consumed by whatever comes up first.
• Let the box end unfinished work. A timebox that always extends is not a timebox. Ending on time with "this needs its own session, here is who schedules it" is the intended behaviour.
• Take the parking lot seriously. Agile teams park off-topic items rather than debating them, and then actually revisit the list. A parking lot nobody reads is just a polite way of dropping things.

The mechanics of applying timeboxes across a whole calendar are in time blocking and timeboxing.

Kanban's core rule is that work in progress is capped: a column holds at most N items, and starting something new requires finishing something first. The reasoning is that throughput does not rise with the number of things underway — past a point it falls, because switching costs and coordination overhead grow faster than the work does.

A calendar behaves the same way and is almost never governed the same way. Meetings are added until the day is full, which is a WIP limit of "whatever fits." Three caps worth setting explicitly:

• A daily cap on meeting hours. Four is a common working number. Past it, the marginal meeting is paid for out of the quality of the others, not out of free time.
• A cap on recurring commitments. Every standing meeting is a permanent draw. Adding one should require ending one, exactly as Kanban requires finishing before starting.
• A cap on simultaneous initiatives. Most meeting load is downstream of project count. Five parallel projects generate five sets of coordination meetings, and cutting to three cuts the calendar without anyone managing the calendar.

The visualization half of Kanban is worth borrowing too: put your recurring meetings on a board and you can see the load, which is much harder to do from a week view where every hour looks like every other.

The reason agile teams' meetings tend to be better is not the ceremonies themselves — it is that there is a scheduled moment for changing them, and a norm that changing them is normal. Everywhere else, meeting formats are inherited and permanent: nobody remembers who started the Tuesday sync, so nobody feels entitled to end it.

Adopting just that loop takes one recurring 45-minute meeting per month or per cycle:

• Inspect. What did our meetings actually produce since the last one? Look at the record, not at impressions.
• Adapt. Pick exactly one change — a meeting ends, a format changes, an attendee list shrinks. One, so the effect is attributable.
• Verify. At the next retro, check whether it helped. If not, revert it. Reverting is a normal outcome and saying so out loud is what keeps people proposing changes.

Run this four times and you have made four evidence-based changes to your calendar, which is more than most organizations manage in a year of complaining about meetings. The audit that gives you the starting baseline is in the meeting audit.

All of it rests on shared visible state. The standup works because the board shows what everyone is doing; planning works because the backlog is written down; the retro works because there is a record of the cycle to inspect. Take away the artifacts and the ceremonies become status theatre — which is what has happened to most standups that people complain about.

Outside software the artifacts are usually missing. There is no board, and the decisions from the last four meetings live in four people's memories, so the retro turns into a discussion of who remembers what. Passive capture supplies the missing layer: Earkeep records mic and system audio continuously while it runs and transcribes locally on your device, so each ceremony leaves a searchable record without anyone taking notes — no bot to invite, no start/stop to remember. Meetings are defined afterwards by selecting a span on a timeline, or automatically from a connected calendar; audio is processed only in memory and never written to disk. A retro then starts from what was actually said across the cycle rather than from the last three days everyone happens to recall. See meetings after the fact.

The specific formats — six ways to run a standup, five ways to run a retro — are in standup and retrospective formats that actually work. For turning any meeting into recorded outputs, see never leave a meeting empty-handed, and for the whole loop from meeting to result, meeting workflows.

Download Earkeep free for macOS and let every standup, review, and retro leave a record behind it.