Is This Scrum, or Is This Just Meetings?

It was 10:04 on a Tuesday in April, and the air conditioning had gone down again. Our old Phaya Thai office had that particular smell — equal parts Coffee Mate, vinyl flooring that had seen better decades, and the warm staleness of dead airflow. Someone had already wheeled out the pedestal fans, the ones that lived in the corner for exactly this scenario, pushing thick April air around the room while we waited for the technician. Tor stood up for his turn at standup, shoulders slightly hunched, and looked directly at me. Not at Namfon. Not at Somchai. At me. “Yesterday I finished the API endpoint. Today I will start the unit tests. No blockers.” He sat down. Namfon stood up and did the same thing. Eyes on the manager. Report delivered. Next.

The standup wasn’t a standup. It was a status update to their boss, conducted standing up.

That moment broke something in me — not because the team was doing it wrong, but because I realised I was the reason it was wrong. In a Thai workplace, when your manager is standing right there and the meeting is in English — his language, not yours — of course you address him. Of course it becomes a report. The power dynamics made any other outcome nearly impossible.

So I made a decision that my colleagues thought was borderline insane: from now on, standups are in Thai. I could barely order lunch in Thai at that point — it was my second year in the country — but it didn’t matter. The standup wasn’t for me. It was never supposed to be for me.

Within two weeks, something shifted. Tor started turning to Namfon mid-sentence. Somchai interrupted with a question about a shared dependency. They started talking to each other instead of at me. My Thai got better. The standup got useful. All it took was removing the thing that was making the ceremony pointless — which, uncomfortably, was me.

As the basketball coach John Wooden once said, “Never mistake activity for achievement.” We had the activity — people standing up, taking turns, saying the right words. We had none of the achievement. And that gap between performing Scrum and practising Scrum is the disease that’s quietly eating your engineering organisation from the inside.

Let’s be honest with each other. You have standups. You have retros. You have sprint planning, refinement, sprint reviews. You have a board — maybe physical, probably Jira. You have velocity charts and burndown reports and a backlog that stretches into next year.

And nothing is getting better.

The standups happen. The retros happen. The sprint reviews happen. And nothing changes. Your team is performing Scrum like a play — hitting every mark, delivering every line — and the audience still isn’t getting a better product. You’re not doing Scrum badly. You’re doing Scrum theatre.

This isn’t a post about whether Scrum is the right framework. It’s a diagnostic. A set of questions you can take to your next retro — assuming your retro actually produces change, which we’ll get to — and score your team against. Not “are you doing Scrum right” but “is your Scrum actually producing the outcomes it’s supposed to produce?”

The Diagnostic

1. Has Velocity Become a Performance Metric?

Here’s the test: if your team’s velocity dropped 30% next sprint because you changed how you estimate, would anyone panic? Would someone from management ask what happened? Would it show up in a performance review?

If yes, velocity has stopped being a planning tool and become a target. And once that happens, the entire estimation process corrupts. Teams inflate estimates to protect their numbers. Carry-over becomes a dirty word instead of useful information. You get what the economist Charles Goodhart warned us about decades ago — when a measure becomes a target, it ceases to be a good measure.

I watched this happen with a team where one engineer — let’s call him Jack — would argue passionately about whether a story was a 5 or an 8. Not because the distinction helped with planning, but because he’d internalised velocity as his scorecard. “But my points!” became a refrain you could hear across the floor. Jack wasn’t broken. The incentive structure was broken. We’d taught him, through months of velocity-driven conversations, that points were what mattered.

Velocity should tell you whether your sprint was realistic. It should help you plan the next one. The moment it becomes something you report upwards, it becomes something you game. And gamed metrics tell you nothing.

2. Would Anyone Notice If You Cancelled a Ceremony?

Pick any ceremony — standup, retro, refinement, sprint review. If you cancelled it tomorrow, would your team’s ability to deliver actually change? Would decisions get missed? Would coordination suffer?

If the answer is “probably not,” you’re running a ritual, not using a tool. Ceremonies exist to solve specific coordination problems. Standups exist so the team can synchronise daily and unblock each other. Retros exist so the team can inspect and adapt their process. If the standup has become a manager update — or a PO update — like mine had — it’s not solving the problem it exists to solve. It’s just consuming fifteen minutes of everyone’s morning.

This doesn’t mean you should cancel everything. It means you should be honest about which ceremonies are load-bearing walls and which are decorative columns. Keep the walls. Question the columns.

3. When Did You Last Delete Something from Your Backlog?

Go look at the bottom of your backlog right now. How old are the items down there? Three months? Six? A year?

Product backlogs should be pruned ruthlessly. If an item has been sitting there for a quarter and nobody’s touched it, nobody actually wants it. It’s not a backlog item — it’s a guilt monument. Someone put it there because they felt they should, and nobody has the courage to admit it doesn’t matter.

An infinite backlog isn’t a sign of ambition. It’s a sign that you’re avoiding the hard work of prioritisation, which is saying no. If you want to see what saying no looks like when you actually commit to it structurally, look at Basecamp’s Shape Up methodology. There is no perpetual backlog. Work gets pitched for a fixed cycle — six to eight weeks — and leadership places bets on what’s worth that investment. If your idea doesn’t get picked this cycle, it doesn’t sit in a queue gathering dust. It disappears. If it still matters next cycle, you pitch it again. If nobody pitches it again, it didn’t matter. The betting table forces a question that most backlogs let you avoid indefinitely: is this actually worth doing, or are we just afraid to say it isn’t? Every item in your backlog carries cognitive weight. It sits in the back of your PO’s mind during planning. It makes the real priorities harder to see. Delete it. If it matters, it’ll come back.

4. Could a Non-Engineer Understand Your Sprint Goal?

A sprint goal should be an outcome. “Users can complete checkout in under three clicks.” “New partners can onboard without contacting support.” Something a human being who doesn’t live inside your Jira board could read and understand.

Most sprint goals I’ve seen are just ticket lists wearing a trench coat. “Complete PROJ-1234, PROJ-1235, PROJ-1236, and PROJ-1237.” That’s not a goal. That’s a to-do list. And a to-do list doesn’t give you the flexibility to make trade-offs mid-sprint, which is the entire point of having a goal in the first place.

If your sprint goal requires Jira to parse, it’s not a goal.

5. When Was the Last Time Your Team Tried Something They Weren’t Sure Would Work?

When engineers say “there’s no room in the sprint” for learning, experimentation, or technical work, the sprint has become a ceiling rather than a container. The sprint is supposed to be a timebox that protects focus — not a prison that eliminates all slack.

This is where I’ve seen Scrum do the most damage. Teams fill sprints to 100% capacity with committed work, and then treat any deviation as failure. There’s no room to explore. No room to experiment with an alternative approach. No room to try something risky that might pay off. The sprint becomes a feature factory conveyor belt, and the team becomes machine operators.

Here at Agoda, we’ve fought this by reserving 30% of engineering time for technical work. It’s not perfect — we’ve seen teams dilute that time with business-as-usual tasks — but the principle matters. If your sprint has no room for uncertainty, you’re optimising for predictability at the expense of everything else.

6. Does Your Scrum Master Spend More Time with the Team or with Management?

When the scrum master’s primary job is updating Jira, chasing status, and reporting velocity to leadership, you’ve hired a project manager and given them a scrum certification.

A scrum master’s job is to serve the team — removing impediments, facilitating difficult conversations, coaching on process improvement. If they spend their days producing status reports and attending leadership syncs, they’re serving the organisation’s desire for control, not the team’s need for support.

Ask your scrum master what they did yesterday. If the answer involves more spreadsheets than conversations with engineers, you’ve got a problem.

7. Has Your Team Ever Changed Their Sprint Length?

If you’ve been running two-week sprints since the day the team was formed — regardless of whether you’re doing discovery work, maintenance, or a major migration — you’ve confused consistency with rigidity.

Sprint length should be a conscious choice that reflects the nature of the work. Discovery-heavy teams might benefit from one-week sprints for faster feedback. Teams doing complex migrations might need three weeks to produce meaningful increments. The Scrum Guide says sprints can be up to a month. It doesn’t say they should all be two weeks.

If nobody on your team can articulate why sprints are the length they are — beyond “that’s what we’ve always done” — you’re following a convention, not making a decision.

8. Pick Your Last Three Retro Action Items. How Many Were Completed?

This is the ultimate diagnostic. You have retros every two weeks (because I’ve already guessed your sprint length, haven’t I). Action items are noted. Concerns are raised. People feel heard.

And then nothing changes by the next retro.

If the answer to “how many action items were completed” is zero, your retro isn’t an improvement mechanism. It’s a confessional booth. People come in, admit their sins, feel a brief moment of catharsis, and walk out to commit the same sins again.

Retros that don’t produce change are worse than no retros at all. They teach the team that raising problems is pointless, that the process is for show, and that the only honest response to “what should we do differently” is “nothing, because we never actually do anything differently.”

What Scrum Can Actually Look Like

Here’s what frustrates me about the “is Agile dead?” discourse. People look at their broken Scrum implementation and conclude that the framework is the problem. It’s like buying a guitar, never tuning it, and concluding that guitars sound terrible.

The Visual Studio teams at Microsoft ran Scrum for years, and what they ended up with looked nothing like what you’d see in a certification course. They ran eight teams on synchronised three-week sprints. Their sprint review wasn’t a meeting — it was a short video, around six or seven minutes, that each team recorded and emailed to every other team. People could watch asynchronously, on their own time, and actually see what other teams had built. Their backlogs had a formulaic simplicity: roughly 30% top customer requests, 30% top-voted items from user feedback channels, 30% engineer-driven ideation, and a 10% buffer. When you’re engineers building tools for engineers, you don’t really need a Product Owner playing traffic cop between the business and the team.

That is Scrum. They took the framework and completely customised it to fit their context. They designed out the parts that didn’t serve them and amplified the parts that did. They didn’t follow the recipe — they understood the ingredients and cooked their own dish.

The documentary filmmaker Ken Burns once said, “The very damaging, controlling thing about any orthodoxy is that it controls you.” Most teams let Scrum control them. The ones that thrive are the ones that control their Scrum.

The XP Escape Hatch

I’ll be direct: I use XP. I think it’s a better fit for most engineering teams than Scrum, and the transition from one to the other is smaller than you’d think.

One-week sprints. That’s the first change, and it’s the most impactful. When a sprint is one week, a lot of Scrum’s overhead dissolves naturally. You don’t need story points — look at two or three stories and ask “can we finish these by Friday?” Yes or no. That’s it. No planning poker. No arguments about whether something is a 5 or an 8. No velocity charts. The sprint is short enough that estimation by intuition works.

Quarterly commitments work the same way they always have. Be honest — you’re not estimating a quarter’s worth of stories in Scrum either. Nobody is. So don’t pretend the estimation ceremony is giving you something it isn’t.

Use a whiteboard with cards and post-it notes. Cards are stories. Post-its are your task breakdown. Sometimes we’ll scribble a rough hour estimate in the bottom-left corner of the post-it — not for tracking, but for two reasons: it stops you creating monster tasks that take days, and if something you thought was two hours is still going after two days, you know there’s a problem worth talking about. It’s physical, it’s visible, and it doesn’t require a Jira administrator to configure.

But here’s the thing about one-week sprints that nobody talks about enough: on Friday, your sprint finishes and you go home. You go home not thinking about partially done work. You don’t carry half-finished stories into the weekend like an unpacked suitcase. The cognitive load drops. You can actually switch off. And on Monday, you start fresh.

That’s not a process improvement. That’s a quality-of-life improvement. And for teams that have been grinding through two-week sprints full of carry-over and half-done work, it changes everything.

So Is Scrum Dead?

The way you’re using it now? Yes. Almost certainly.

Not because the framework is fundamentally broken, but because what most teams call “Scrum” is a set of meetings with a two-week cadence. The standups don’t synchronise the team. The retros don’t produce change. The sprint goals don’t describe outcomes. The velocity charts measure activity, not achievement. The backlog is infinite. The scrum master is a project manager. The PO is a ticket prioritiser. And everyone involved knows it, but nobody says it, because the ceremonies provide a comforting illusion that a process exists.

Fixing this doesn’t mean doing Scrum better — it sometimes means outgrowing Scrum entirely. Product engineering doesn’t require Scrum. It requires teams that own problems, measure outcomes, and iterate based on evidence. If Scrum helps you do that, keep it. If Scrum has become the thing preventing you from doing that, the framework isn’t sacred.

Agile isn’t dead — it was never alive in most organisations. What most teams practise isn’t agile. It’s agile-shaped waterfall. It’s ceremony without intent. It’s the play without the plot.

Take the diagnostic above. Score your team honestly. And then ask the only question that matters: is what we’re doing actually making our product better, or are we just going through the motions?

Now, if you’ll excuse me, I need to go prepare for our Monday standup. It’s in Thai, naturally. My grammar is still terrible, but at least the team talks to each other now.