The Daily Stand-up Became a Query

The agents could already do the work.

They could read the repository, write code, run tests, review changes, and reconstruct most of the context required for a bounded task.

The problem appeared when several of them tried to do it at the same time.

One session discovered an incompatibility. Another changed a contract. A third kept working against the previous version. Someone finished and left the result only in a final chat response.

The model wasn't missing another capability.

The project was missing an organization that could answer who was doing what, which decisions belonged to each responsibility, where discoveries had to persist, and how another session could continue without depending on a private conversation.

That was exactly what I had been trying to build: recognizable roles, bounded authority, explicit handoffs, persistent evidence, and institutional memory outside the agents themselves.

I wasn't trying to design a more efficient daily stand-up either.

I wasn't a Scrum Master looking for another way to observe the team. I was another developer sitting through half an hour of consecutive versions of “no blockers, yesterday I did this, tomorrow I'll continue with that.”

I understand why that synchronization exists.

That doesn't automatically make me enjoy participating in it.

One morning I opened the project state, read the blockers that had appeared while the agents were working, and resolved the ones that actually required a decision from me.

Resolve one, and an agent could continue.

Then another.

Then another.

There was no meeting.

I didn't ask every agent what it had done yesterday. I didn't listen to seven slightly different versions of “still working on it.”

I dealt with the things preventing the system from moving and returned to my own work.

And I caught myself thinking:

This is much closer to what I always wanted to get from a daily stand-up.

Then I asked the system for a daily

The amusing part came later.

I wanted a general view of the project, so I gave the system a very informal request:

Give me a daily-style status.

And it did.

It reconstructed what work was active, what had progressed, what was blocked, and what needed to happen next.

The interesting part wasn't that a model could write a summary. That's not particularly surprising anymore.

The interesting part was where the information came from.

It wasn't interviewing agents. It wasn't reading the private history of every conversation. It didn't depend on one session correctly remembering what another session had done.

Most of the report could be reconstructed from persistent organizational state: active responsibilities, claimed work, evidence, handoffs, and blockers.

The daily had changed from a conversation used to discover project state into a query over state that already existed.

That made me reconsider which part of the ceremony I actually disliked.

The daily was the consequence, not the problem

The official Scrum Guide defines the Daily Scrum as a 15-minute event for inspecting progress toward the Sprint Goal and adapting the Sprint Backlog when necessary. Developers can choose its structure as long as it focuses on the goal and produces an actionable plan.

Put that way, I have very little to disagree with.

Of course I want to know whether the project is moving.

Of course I want impediments to become visible.

Of course I want the plan to adapt when we discover something new.

The problem appears when the only way to obtain that information is to gather everyone and reconstruct it verbally.

In many teams, the meeting becomes a kind of manual state synchronization: each person explains their local copy, and somebody tries to reconstruct what is actually happening.

That makes sense.

Humans don't share memory.

One person may have discovered yesterday that an integration is broken. Someone else may be waiting for a change nobody told them was already finished. Another person may have made a decision that never reached the issue.

Conversation reconciles those partial copies of reality.

The problem isn't the daily itself.

The problem is that our work system often doesn't have a sufficiently useful model of its own state.

Capability without organization only accelerates the problem

Giving agents more capability does not solve this automatically.

It can actually make the problem much worse.

Imagine five sessions working in parallel.

One discovers an incompatibility.

Another changes a contract.

A third needs that contract but loaded the repository before the change.

Another finishes a task and leaves the result only in its final chat response.

The last one discovers extra work, decides it would be useful, and silently expands its scope.

Now we have five very fast executors and five different versions of reality.

Agents don't create coordination just by existing.

They can simply produce uncoordinated work faster.

That's why one of the most important decisions in my multi-session setup was moving institutional memory outside the sessions themselves.

A session can disappear. Another one should be able to replace it.

The project should still know:

• what outcome we're pursuing;
• which work is claimed;
• who has authority over it;
• what evidence exists;
• which dependencies changed;
• what was discovered outside the original scope;
• what is blocked;
• what decision would allow work to continue.

If those answers exist only inside conversations, the project doesn't have state.

It has memories.

A blocker is more useful than an activity report

This also changed what I want to see in the morning.

I don't necessarily need to know everything the agents did.

I need to know where my attention is required.

If an agent has enough context, authority within its responsibility, green tests, and no conflicts, the best thing I can probably do is leave it alone.

A message like this is different:

BLOCKED

Reason:
The accepted contract does not define what happens
when two policies have the same priority.

Impact:
Implementation cannot continue safely
without choosing semantics.

Requires:
Architecture decision.

That I want to see immediately.

There is a meaningful difference between:

Runtime agent: yesterday I implemented A and B, today I'll continue with C.

and:

C contains an ambiguity that prevents safe progress, and these are the two possible decisions.

The first is state.

The second requires attention.

When work happens in parallel, human attention becomes a coordination resource.

I don't want to spend it asking for information that can be reconstructed automatically.

I want to spend it where uncertainty still requires a decision the system cannot safely make on its own.

Human attention moved somewhere else

The workflow became simple: open the project, query its state, and look for blockers. If one requires my authority, I make the decision, persist it, and unblock the work. If there isn't one, I leave the system alone.

Then I can request the broader picture whenever I actually need it.

That doesn't mean conversations disappear.

Quite the opposite.

Some problems genuinely require discussion.

An ambiguous product decision may benefit from multiple perspectives. A cross-cutting change may require coordination between architecture and specialists. A difficult failure may need collaborative investigation.

But the conversation happens because there is something to discuss, not because the calendar reached a particular time.

That sounds like a small distinction.

For me, it's a huge one.

The meeting was an interface

This is probably the idea I find most interesting in the experiment.

Many software-development ceremonies are also interfaces.

A daily is an interface for observing work state.

Planning is an interface for turning intent into committed work.

A review is an interface for inspecting what was produced.

A retrospective is an interface for turning recent experience into process changes.

For a long time, the cheapest interface for many of those operations was a meeting.

Put the right people in the same room, exchange information, and reconstruct a shared state.

It's incredibly flexible.

It also carries an obvious cost: synchronized human time.

As work systems become better at representing their own states, relationships, and transitions, some of those interfaces can change.

Not necessarily disappear.

Change.

The question stops being:

How do we automate the daily stand-up?

and becomes:

Why did we need a meeting to obtain this information?

Those questions lead to very different systems.

I don't want a robot facilitating the same meeting

The least interesting solution would be to reproduce the exact ceremony with agents.

At 9:00, each one could explain what it did yesterday and what it plans to do today. We could even give them avatars and make them wait for their turn.

We would have built an impressively efficient simulation of something I already wanted less of with humans.

One advantage of a team partially composed of software is that we aren't forced to preserve interfaces designed around human limitations.

An agent doesn't need to wait until tomorrow morning to publish a blocker. It can persist it the instant it appears.

It doesn't need to remember which files it changed. Git already knows.

It doesn't need to announce that its tests passed. It can attach the evidence.

It doesn't need to verbally say that one responsibility finished and another can begin. It can emit a structured handoff.

Then the daily summary can be generated whenever somebody needs it.

Async doesn't mean invisible

There is an important trap here.

Removing the meeting without replacing the information it carried just creates asynchronous chaos.

For this to work, state needs to become more explicit, not less.

Work should have ownership.

A blocker should describe what prevents progress.

A handoff should say who is delivering, who is receiving, and what condition changed.

Acceptance should preserve evidence.

Important decisions should reach the appropriate normative source.

Progress should be reconstructable without interpreting twenty chat messages.

Paradoxically, removing ceremonies may require more discipline in the work model.

Meetings tolerate a surprising amount of disorder because humans are good at filling gaps through conversation.

A query can only answer correctly when the information exists.

That's why I don't think “working asynchronously” simply means replacing meetings with messages.

It means moving coordination away from implicit human memory and toward explicit state.

And no, this isn't a Daily Scrum

This distinction is worth making.

If I remove the daily event, strictly speaking I'm not doing the Daily Scrum defined by Scrum.

I'm also not particularly interested in winning a semantic argument by pretending otherwise.

This experiment isn't an attempt to prove that Scrum should work this way or that every human team should remove daily meetings.

Agents don't magically become a Scrum Team because I give them job titles either.

What interests me is something else:

separating the function from the interface we currently use to perform it.

Scrum wants transparency, inspection, and adaptation.

So do I.

It wants impediments to become visible and decisions to happen quickly.

Great.

The question introduced by this kind of organization is how much of that still needs to happen through a synchronous ceremony when the work itself continuously produces structured state.

For a traditional human team, the answer may still be “quite a lot.”

For an agent team, probably “much less.”

For hybrid teams, I suspect the interesting answer lives somewhere in between.

Agents made me appreciate Scrum more

Solving the organization did not make the agents more capable. It made the work they could already do observable and coordinatable.

There is some irony in all of this.

Building agent workflows made me appreciate several Scrum ideas precisely while making me need some of its ceremonies less.

A shared goal matters.

Transparency matters.

Frequent inspection matters.

Adapting the plan when new information appears matters.

Making impediments visible matters a lot.

What I no longer take for granted is that those properties must always be implemented through the same interfaces.

Maybe part of the future of agentic work isn't teaching agents to attend our meetings.

Maybe it's building work systems that represent enough information for some meetings to become unnecessary.

That morning, I didn't replace an hour of Scrum with an hour talking to agents.

I read blockers.

I made the decisions that actually required a person.

And I let the agents continue working.

Later, when I wanted to know how the project was doing, I asked.

The project already had the answer.

I don't want to automate the meeting.

I want to stop meeting just to reconstruct information the system should already know.