Scrum Through the Eyes of an Engineer

I’ve worked in a few different organisations now, and I’ve learned that Scrum isn’t one thing.

People talk about it like it’s a universal operating system: do the ceremonies, create the tickets, run the sprint, and delivery will magically happen. But in real engineering teams, Scrum shows up in very different forms and the difference isn’t the tool. It’s the intent behind it, and whether the way work arrives matches the way work is planned.

This is my opinionated (but not anti-anything) view of Scrum from the engineer seat: what it feels like when Scrum becomes a driver, and what it feels like when it turns into a set of meetings wrapped around BAU.

The “driver” version of Scrum

The best version of Scrum I’ve experienced had one thing in common - planning was treated as real work.

Not “a planning meeting” squeezed between other meetings. Real planning time, usually a couple of dedicated days each quarter where the product owner and leads sit with the full team and do the uncomfortable part up front:

• What are we actually trying to achieve this quarter?

• What’s the order of priorities?

• What’s in, what’s out?

• What depends on what?

• What does “done” mean?

When it’s done well, those planning days aren’t leadership presenting a plan. They’re the team building the plan. 

That’s where epics and stories start to matter. The team breaks work down properly, clarifies requirements, maps dependencies, and assigns effort in a way that feels grounded and not aspirational. You leave planning with a backlog that’s not just a list, but a shared understanding.

Then the sprint cadence becomes useful:

Standups are short because they’re about execution and blockers, not discovery. Prioritization doesn’t happen live in standup because it already happened in planning. The sprint goal feels real. Retros aren’t therapy, they’re feedback loops. You can point to what changed because of the retro.

In that environment, Scrum genuinely drives delivery. It creates focus, reduces thrash, and helps engineers do deep work without being pulled in ten directions.

And yes, this often shows up in application or product teams because the work naturally fits: planned delivery, features, roadmaps, a clearer definition of value.

But it’s not exclusive to product teams. I’ve also seen platform and engineering enablement work run beautifully in Scrum when it’s treated like a product internally with clear outcomes, and protected time for delivery.

The “Scrum-ish” version that’s really just BAU

Then there’s the other version - the one a lot of engineers quietly recognize as “Scrum on paper.”

You still have stories and epics. You still have standups. You still have a sprint. You might even have retros.

But the team is operating in a BAU reality.

Standups become the place where new priorities get introduced. Work gets added mid-sprint. Someone needs “a quick fix.” Something urgent appears. Another request comes from another team. And suddenly the sprint isn’t a sprint, it’s a rolling queue with a Jira board.

This is where Scrum starts to feel…well....frustrating.

Not because people aren’t working hard. In these teams, engineers are usually working very hard. The frustration comes from the mismatch between the story the process tells and the reality engineers live:

• The sprint implies commitment, but the work intake is open-ended.

• The backlog implies priority, but the priority changes daily.

• The ceremonies imply control, but the work is driven by interrupts.

Engineers end up context switching constantly, and the board becomes less about delivery and more about tracking chaos. If you’ve ever felt like standup is basically “daily triage,” you know exactly what I mean.

Because when unplanned work dominates, planned work slips. Then engineers feel like they “didn’t deliver,” even when they spent the week doing exactly what the business needed, i.e. keeping things running, responding to incidents, fixing urgent issues, unblocking others.

The process doesn’t reflect reality, so it starts measuring the wrong thing.

The real issue isn’t product vs platform

People often say, “Scrum doesn’t work for ops” or “Scrum doesn’t work for platform teams.”

I don’t think that’s fully accurate.

I think the more honest version is this: 

Scrum struggles when teams pretend unpredictable work is predictable.

I’ve seen platform teams run Scrum well but only when they acknowledge the nature of their work and design around it. I’ve also seen product teams suffer when leadership treats the sprint as optional and injects new priorities constantly.

So it’s not the team type. It’s the work intake and the discipline around it.

From my experience, in platform/ops environments, work doesn’t politely line up behind a sprint boundary. Incidents happen. Security issues show up. Pipelines break. Access requests come in. Costs spike. A dependency fails in production. A certificate expires. A “small change” turns into an afternoon.

That’s normal.

The problem is when organisations keep that intake channel wide open, but still expect sprint predictability. You can’t run a two-week plan if you don’t protect the plan.

What I’ve learned as an engineer

Here’s the opinion part from the engineers seat.

Scrum is not “good” or “bad.” It’s an amplifier.

If your organisation already values clarity, discipline, and realistic planning, Scrum amplifies that. It becomes a driver.

If your organisation doesn’t protect priorities, doesn’t control intake, and treats every request as urgent, Scrum amplifies the chaos. It becomes theatre.

And engineers feel it immediately.

Because engineers pay the cost of context switching. Engineers pay the cost of vague stories. Engineers pay the cost of mid-sprint priority changes. Engineers pay the cost of work that arrives through standup like it’s a helpdesk.

So when I hear “we’re doing Scrum,” I don’t think about ceremonies.

I think about two questions:

1. Is planning treated as a real investment, or a ritual?

2. Is the team honest about how much unplanned work exists, and is that accounted for?

If the answers are good, Scrum can work in almost any environment.

If the answers are bad, no framework will save you.

Ending...

That’s my take from the engineer seat: Scrum can be a driver, or it can be noise. It depends on whether it matches the work.

If you’ve seen both, I’d love to hear your story.