First things first

I’m most productive in the mornings. Always have been. It seems counter to most people’s habits, but that’s when my brain is sharpest.

But this seems to be a problem. Why? Because all my meetings are in the mornings. And not just one big chunk - they’re scattered. Two or three meetings with short gaps in between mean those gaps are effectively lost time. You can’t sink your teeth into serious work in a 15-minute window between calls. You’re in limbo, checking emails, responding to Teams messages. Circling but never landing.

Some people think, “It’s just 15 minutes.” But it’s never just 15 minutes. Context switching has a cost. Those short gaps become mental sinkholes.

The daily standup: is it a productivity killer?

Funny thing: I treat those small gaps as rest time, not work. It’s the only way to stay sane. And that’s fine, but what I really wish is that I could spend mornings on deep, core output, and leave meetings for the afternoons.

Take the daily standup. In theory, it’s meant to be quick alignment first thing, get blockers out of the way, and then everyone disappears to build value. But too often, I see teams push it to 10:30 or 11. This is a death blow to focus.

Worse, late dailies encourage “wait for tomorrow’s standup” behaviour. If you have a question, send an email. I personally open Outlook twice a day now - once in the morning, and once after lunch. It’s a new habit that’s done wonders for my focus. If it’s truly urgent, call me. We have tools for that.

But in my view, the standup should happen first thing or not at all. If it can’t happen early, skip it. Period.

The daily isn’t a ritual to be preserved at all costs. If you get to 10:30 and no one has anything urgent, just skip it. If someone does need something, tag the relevant people, and spin up a quick call. It’s 2025, not 2005. We have tools to communicate asynchronously. We don’t need to force everyone into a meeting just because it’s on the calendar.

The meeting serves the team, not the other way around.

Scrum isn’t the problem

People love to blame Scrum for endless meetings and lost productivity. But when I hear “Scrum ruined my mornings,” I know they’re not really doing Scrum.

In actual Scrum, you have:

One daily standup, short and sharp.
Sprint planning, review, and retrospective once per sprint, scaled to the sprint length.

That’s it. No daily manager catch-ups. No status theatre. No mid-morning interruptions.

In a Scrum team, everyone is dedicated. The team is the atomic unit. You don’t have external people drifting in and out, dictating when ceremonies happen. Yet so often, someone chimes in: “I can’t do 9am, I have a conflict.”

Guess what? If you have a conflict, you’re not dedicated. And if you’re not dedicated, you shouldn’t get to dictate the schedule for those who are.

First things first: the team needs the meeting out of the way, so that they can get on with the real work (yeah, I said it). The team is the priority, not the individual. If you can’t make it, that’s your problem, not the team’s.

Makers vs managers: the tug-of-war

Paul Graham nailed it with the “maker’s schedule, manager’s schedule” essay.

Managers slice their days into 30-minute or 1-hour blocks. Makers need long, uninterrupted stretches. When managers inject meetings into a maker’s morning, or afternoon for that matter, they steal the highest-value focus hours, and it ripples through the rest of the day. Makers work in half-day blocks, not 30-minute chunks.

When managers don’t understand this, they create an environment that feels like it devalues productivity. And while productivity to them is attending meetings, for makers, it’s about creating value through deep work.

What happens? Makers push back. Managers tighten control. Makers pull further. Managers respond with more meetings and oversight. The result? People blame Scrum, Agile, or whatever framework is in place. But, with one very notable exception (which we’ll see next), the framework isn’t the problem. These issues arise from misuse of these frameworks, but more importantly, from a misalignment on what constitutes productivity, and what work creates value.

The great SAFe tragedy

Nowhere is this dysfunction clearer than in SAFe. SAFe is an unmitigated monstrosity that should be cast into the fires of Hades.

It’s a framework designed to create complexity so it needs people to manage that complexity. It exists to justify the careers of middle managers and process jockeys, who don’t actually do the work, but claim to ensure it happens.

SAFe is the very embodiment of “we don’t trust you to work without oversight.” It standardises, instead of adapting. It solves a problem that shouldn’t exist by adding a hierarchy that shouldn’t exist.

It’s the vestigial death cry of Waterfall, desperately trying to cling to relevance in an Agile world. SAFe is in fact the antithesis of Agile principles, which value individuals and interactions over processes and tools. And above all else, it’s a self-fulfilling prophecy of dysfunction.

I will not work in a SAFe organisation. Full stop.

Even great teams drift

Here’s the caveat: even the most disciplined teams can lose focus. Even the most driven developers (myself included) fall into traps.

This doesn’t mean we need meetings for everything. It means we need sensible guardrails. Scrum provides those guardrails - not by adding more layers, but by enforcing transparency and accountability in a lightweight way.

You can’t be a Scrum Master of multiple teams

I’m sorry, you just can’t.

A true Scrum Master is dedicated to one team. They aren’t a manager. They’re a facilitator, protector, and coach.

When someone tries to “manage” multiple Scrum teams, they’re no longer a Scrum Master. They become an overhead resource, floating between contexts, unable to serve any team properly.

Scrum solves this by design. But it requires maturity and discipline to uphold it.