Engineers do not like Scrum Standups

[Evan Fishman - Quely for Jira]

12.5 weeks of engineering time.
Lost to daily standups. Every year. Across your team.

For a ritual most teams admit isn't working.

Here's the thing:

63% of developers genuinely dislike daily standups. That's the opinion of 2,300+ developers surveyed on Blind.

Not occasionally frustrated. Not burned out from a bad sprint. Just consistently checked out before the meeting even starts.

This is a huge coordination problem.

Standups became status reports because the underlying question  "does everyone know what's actually happening?" never got answered anywhere else.

So we meet. Every day. To reconstruct what should already be visible.

I've seen teams add more standups to fix the communication gaps from the first standup.

That's the loop: coordination failures → more meetings → less time to do actual work → more coordination failures.

The fix is making context visible before the standup needs to exist.

When people already know what's happening, what was decided, and what's blocked, the need for a standup drastically reduces.

[Danno]

@Evan Fishman - Quely for Jira I agree 100% with the survey. I am a scrummaster but I don't like the idea of a daily standup either. It should be obvious regarding what people are working on and what they will be working on. I think there is a missed opportunity, though, to share what is going well and who is having an issue that could use some constructive input. Possibly get consensus that something should perhaps go back to the backlog or be abandoned. If there is a consensus on that then you have a team building opportunity instead of a Status update.

I think the reason they hate the daily standup is that they aren't having it with a scrummaster who is supposed to insulate the team from having to update product owners and other management whose lifeblood is a status update. Again, why aren't they getting their information from whatever tool they are using? Not enough training to show them how to do it.

I also think not enough attention is paid to the planning stage.

[Evan Fishman - Quely for Jira]

I completely agree. The missed opportunity is massive. Sharing what is going well and actively swarming on blockers turns it into something the team actually wants to attend.

The planning stage is the biggest factor here, and I have a ton of thoughts around it. The little things matter, the scattered info that leads to constant context switching during delivery, the lack of actual alignment/understanding (by the team and stakeholders) on the work, etc. It is our biggest goal at Quely.

[Danno]

@Evan Fishman - Quely for Jira and you are talking about this from the perspective of a software company. Imagine trying to convert traditional engineering teams to think and do Agile of some sort.

I am a certified scrumaster and the admin here, and have not been able to get people to understand how to work in this style or to use the Atlassian tools to utilize the data that is there to their advantage.

[Luis Ortiz - Catapult Labs]

I think is the status report what should be eliminated so the actual standup can survive.

12.5 weeks lost to bad meetings is a tragedy.

But, the problem isn't Agile, and it isn't the core concept of the standup.
The problem is how teams allow a 15-minute blocker-check to mutate into a 45-minute status report, live demo, and architecture debate.

Standups are absolutely vital for a team to maintain a daily pulse on work and surface blockers.

But reading Jira tickets aloud to each other over a Zoom call is a terrible use of synchronous time.As you perfectly put it: "The fix is making context visible before the standup needs to exist."

Full Disclosure: I am the co-founder of Catapult Labs, and we built our Standbot (a native Slack + Jira bot) for this exact reason. We realized that if you automate the "status update" portion asynchronously in Slack, you completely strip away the administrative overhead.
When a bot automatically surfaces what was moved, what was completed, and what is flagged as blocked directly into the team's channel, the context is already visible.
If the team still decides to meet live, that meeting shrinks to 5 minutes because it is laser-focused on solving the blocker, rather than reporting the status.

When you separate the administrative update from the human collaboration, developers actually stop hating the ceremony and follow-through is easier.