Davide la Locomotive

We called it a “daily catch-up.”
It felt more like a group panic disguised as a status update.
Nobody knew why we were doing it—just that we had to.

Then I read the Scrum Guide.
Turns out, we were doing it wrong.

Here’s how we fixed it.

---

The first time I experienced a Daily Scrum, I thought it was a job interview.

Every day. For the same job. That I already had.

At 9:30 AM, we’d gather like polite prisoners, go around the circle, and perform what we thought was the ritual:
“Yesterday I worked on X. Today I’m working on X. No blockers.”

Translation: “Please don’t fire me.”

We called it a “daily catch-up,” but it was more like a stand-up comedy night where no one laughed and the punchline was existential dread.

Nobody knew what the point was—but we did it anyway. Like brushing your teeth with the wrong end of the toothbrush. We were technically participating, but somehow missing the point.

Worse still, the session often derailed. Someone would mention a vague ticket. Half the team would squint at it. “What does this even mean?” Cue a ten-minute side quest into misunderstood acceptance criteria and unplanned story refinement. All within a meeting that was “strictly timeboxed to 15 minutes.”

No one ever admitted being stuck. No one asked for help. And the moment you finished your update, you stopped listening—because the real goal wasn’t collaboration. It was survival.

This is not what a Daily Scrum is meant to be.

---

At one company, we even had a saying: “No problem is a problem.”

On the surface, it sounds wise—like a Zen koan with a Gantt chart. It means: if no one’s surfacing issues, then that is the issue. Which is true. But also… not.

Because what it actually created was a weird Schrödinger’s atmosphere where:

• You were supposed to admit problems (so we could solve them),
• But also supposed to have no problems (so you didn’t look like a problem),
• And if you had too few problems, that was suspicious,
• And if you had too many, you’d set off the “Do We Need To Escalate This?” alarm.

So most people just trundled along, somewhere between confused and cautious. And when things weren’t going well? You kept quiet. Because if you said, “This is going badly,” then you became the bad news.

Meanwhile, some work just went… okay. Smoothly. No drama. No breakthroughs. Just a quiet, efficient pootle through a ticket.

Which was… suspicious.

Apparently you’re only a high performer if you’ve overcome something. Preferably something dramatic. Like a collapsing CI pipeline or a metaphorical dragon guarding your pull request.

---

Then I became Scrum Master.

Naturally, I did the nerdiest thing possible: I read the Scrum Guide.

And guess what I discovered?

The purpose of the Daily Scrum isn’t to list what you did yesterday like some weird corporate confessional booth.
It’s not a verbal timesheet. It’s not a “please don’t fire me” circle.
It’s a planning meeting.

It’s meant to answer one question:
How are we going to work together today to get stuff done?

That one shift—from looking back to looking forward—changed everything.

Instead of hearing “yesterday I worked on ticket ABC-123 and today I will continue to work on ticket ABC-123,” we started hearing things like:

• “This’ll be ready for review today—can someone be on deck for that?”
• “I’m not sure how to handle the logic for this part—anyone want to pair?”
• “This test is being flaky again—I’ll dig into it unless someone has a fix already.”

I explained to the team:
You’re not here to justify your job. You’re here to collaborate. If you’re stuck, say so. I’ll help, or someone else will. No shame. No alarms. No “problem = problem” theatrics.

We made some ground rules:

• No laptops or phones—if we’re here, we’re here.
• We stopped going “round the room” and instead went through the board.
  It made us focus on the work, not the workers. Presence replaced performance.

I’d read about this concept in aviation called “Just Culture”—if someone makes an honest mistake, they aren’t punished. They’re supported, trained, and trusted. That stuck with me.

So that’s what we did.
Mistakes weren’t shameful—they were just signals.
Retros were for exploring how to prevent repeat mistakes.
Daily Scrums were for answering: how do we fix it today?

I never told people what to do. I wasn’t their manager.
But when I asked, “Could someone help with this?”—someone always did.
Not because they had to. But because they understood why.
That’s what culture does. It explains the why so you don’t need to explain the who.

As the team got into the rhythm, my role faded. I didn’t need to nudge or narrate.
They just… did it.

The Daily Scrum often didn’t even take ten minutes.
Not because we had “no problems”—but because we knew how to talk about them.
We had a plan.
We trusted each other.

And when things went wrong—because of course they sometimes did—the team didn’t freeze or flail.
They rallied.
They helped each other.
Because they knew: next time, it might be them.

It felt good to help.
It felt good to be helped.
It felt like trust.

That’s what it was like.
That’s how I wanted it to be.
That’s how it should be.

---

📘 Footnote: What the Scrum Guide Actually Says

For anyone wondering what the official definition is, here’s the full excerpt from the Scrum Guide (2020):

“The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.”

At its core:
Inspect. Adapt. Act.
Together.