Daily Standups Can Be Surprisingly Unproductive - Here's What Actually Works

[#1]

I’ll be honest , I used to believe daily standups were bulletproof.

They’re short, focused, and baked into Agile frameworks like Scrum. What could go wrong?

But after working on a mix of Agile and hybrid projects  from small dev teams to cross-functional programs. I’ve seen daily standups fall apart more times than I’d like to admit.
 And every time, the symptoms were the same:

• People zoning out.
• Updates that made no sense.
• Blockers ignored.
• And someone always asking, “Wait, why are we even doing this again?”

As both a Jira admin and a PMP-certified project manager, I’ve watched this pattern repeat across industries and teams. And I’ve also seen what it takes to fix it, not with fancy tools, but with small, intentional changes.

A Real Example (Because Theory Only Gets You So Far)

One of the teams I supported earlier this year had just started a new 2-week sprint. Small crew , five devs, a QA, and a product owner.

We had everything set up:

• Jira board? 
• Sprint backlog? 
• Daily 10-minute standup on the calendar? 

Week 1 was fine, polite check-ins, surface-level updates, nothing major.

By week 2, it started slipping:

• “Still working on that ticket.” (…for 3 days straight?)
• Product owner asking roadmap questions mid-standup.
• Testers mentioning bugs that never made it into Jira.
• And one dev just kept their camera off and didn’t say a word.
• Some folks just… silent.

It slowly turned into background noise. One person actually said,

“Do we even need this?”

You could feel the energy drop. People stopped looking forward to the meeting. No one said it, but we were all wondering:

Are we just doing this out of habit?

Why Daily Standups Fail (Even With Good People)

It’s not because people are lazy. It’s usually because we confuse the ritual for the purpose.

Here’s what I’ve consistently seen:

1. Status over sync

Too often, standups become a mini status meeting for the project manager. Team members start reporting instead of collaborating. It stops being a conversation.

2. Jira overload

Teams try to use Jira as the script for the meeting. “I’m working on ABC-123 today” isn’t helpful unless there’s context. Jira is powerful but if you’re just reading ticket IDs out loud, it’s a waste of everyone’s time.

3. No action on blockers

People raise blockers. Everyone nods. Nothing changes. It’s demoralizing especially for new team members who expect follow-up and don’t get it.

4. Poor facilitation

This one hurts a little, because I’ve been guilty of it. Without someone keeping the meeting focused, time-boxed, and relevant, the standup starts drifting into planning, problem-solving, or just… silence.

What Actually Worked (Small Fixes, Big Difference)

I didn’t reinvent Agile. I didn’t overhaul Jira. I just made small, practical changes, ones any team can adopt.

🔹 Use Jira as a guide, not a script

We showed our board during standup, but didn’t read tickets out loud. Each person focused on what mattered: what they’re doing, what they’re blocked by, and what’s changed since yesterday.

🔹 Rotate the facilitator

Giving every team member a chance to run the meeting changed everything. People paid more attention, and the standups became shorter and sharper.

🔹 Set a simple rule: no blockers left behind

If someone mentions a blocker, we immediately tag it in Jira, assign it, and set a follow-up. Even just writing “Investigate with QA after standup” made a difference.

🔹 Reframe the purpose

I reminded the team (regularly): This is not a status update for the PM. It’s a daily sync so the team can move forward faster  together.

Final Thoughts

Daily standups can either feel like a helpful pit stop  or a chore no one wants to attend.

In my experience, it’s rarely about the format or the time. It’s about how you run them, and who they serve.

Whether you’re working in a fully Agile team or using a PMP-flavored hybrid approach, the standup should do one thing: help the team move forward, with less confusion and more clarity.

And sometimes, all it takes is a few tweaks to bring it back to life.

Your Turn
 How have you seen standups go off the rails?
 What’s worked for your team?
 And what do you wish someone had told you when you ran your first one?

Drop a comment. Let’s share the messy parts of Agile too,  that’s where the real learning happens.

[Cash Coyne]

"We showed our board during standup, but didn’t read tickets out loud. Each person focused on what mattered: what they’re doing, what they’re blocked by, and what’s changed since yesterday."

Ummmm.... isn't that what you're supposed to do?:
What you did since last standup?
What you're working on next?
Any blockers?

When I joined the team, they would FIRST go over any issues that occurred with our regression scripts which often led into discussions when there was an issue.  Then everyone gave their updates.  I changed it to having the regression update last, so those that needed to have a discussion could then and everyone else drop.

Whenever anyone starts getting into a conversation, I give them about 15-20 seconds and say "Let's finish this discussion after everyone's update".  And by putting this at the end, those that don't need to stay can drop.

As we go thru each team member's update, I look to see if there's anything that has been in a column too long and if it is, and they don't mention it, ask for a specific update on that.

I like the idea of having rotating facilitators.  But I'm not sure that they would enforce the discussion at the end aspect or would ask about issues that have been in a column too long.

In terms of blockers, we always transition them immediately and then I have a field for a follow up date/time and automation rule to send a reminder to follow up.

The biggest problems we encounter:

1. Team members not updating their statuses
2. Team members doing work that has no Jira ticket
3. Jira tickets assigned to people on external teams - when that occurs, we create a "Monitoring" ticket (that's a status) and assign it to a team member that keeps in touch with the external team to update us in scrum as to it's status.

I would love ideas on how to help prevent my #1 and #2 above.