Rise of the Scrum Zombies
LiveOps teams should stop following Scrum blindly and start building systems that fit their game.
Deep Dive by NotebookLM.
Many LiveOps teams use Scrum by default, but its rigid structure often clashes with live game development's unpredictable, continuous nature.
Scrum was built for product discovery, not for maintaining and improving existing games under constant deadlines, dependencies, and external constraints.
A flow-based approach like Kanban offers a better fit by making work visible, reducing friction, and focusing on delivering real player value at the right pace.
You’ve seen them. You might even be one of them. Shuffling between meetings, dragging yourself from standup to sprint planning to retro, eyes glazed over. Jira board is open. Spirit is closed.
Sprint ends, sprint starts. Rinse, repeat.
Nobody’s asking if this is working. Everyone’s too busy pointing at the burndown chart like it’s proof of progress. The thing is, your players haven’t seen a single change for three months. But hey, at least your sprint velocity is trending nicely.
This is what happens when teams follow Scrum blindly. You end up going through the motions and checking boxes. Worshipping ceremonies instead of outcomes.
It’s a kind of agile necromancy. Scrum zombies roam the studio, reciting rituals, convinced that if they stick to the process hard enough, value will magically appear.
But let’s be honest. If you’re working in LiveOps, especially in mobile games, Scrum probably isn’t doing what you think it’s doing.
It might be slowing you down.
The problem? We’ve stopped asking whether Scrum is the right tool for the job. It’s become the default. The “professional” way to make games. Something you implement and follow to prove you’ve got your act together.
But the process isn’t the purpose.
It’s time to stop shuffling. Time to stop mumbling the Scrum liturgy like it’s gospel. Time to wake up and ask the only question that matters: is this helping us make better games, faster?
If not, maybe it’s time to try something else.
The Original Problem Scrum Was Built to Solve
To understand why Scrum often feels awkward in LiveOps, consider what it was built for.
Scrum wasn’t designed in a game studio. It came from the world of traditional software development. Teams work on complex products that nobody has ever used before. These products could take months, sometimes years, to build.
The big risk? Spending all that time and money only to launch something no one wanted.
Scrum was a response to that.
The core idea is simple: build working software in short cycles, show it to users often, and adapt based on feedback. Keep the team focused. Keep the feedback loops tight. Get something tangible in front of real people, fast.
That’s what all the ceremonies are about. The sprint, review, and retrospective are not just meetings. They exist to help you stay aligned, learn quickly, and adjust as you go.
It’s a great fit when you’re creating something from scratch and don’t know what will work.
But that’s not how LiveOps teams work.
You’re not validating early-stage ideas. You’re not looking for product-market fit. You’ve already got players, revenue, and a running game. Your job is to keep that machine running while improving it simultaneously.
You’re juggling event content, store updates, backend tweaks, monetisation tests, and occasional fire-fighting. You might still need feedback, but not every two weeks, and not from a clean slate.
In short, Scrum was built to solve a particular problem.
It’s just not your problem.
So why are you using it?
When Games Got Agile: Clinton Keith’s Big Contribution
Scrum didn’t just wander into game development on its own. It had help.
Back in 2010, Clinton Keith published Agile Game Development with Scrum. If you’ve worked in game production over the last decade, chances are you’ve seen it, skimmed it, or had it handed to you by a producer saying, “We’re going agile.”
This book mattered. It was the first serious attempt to bridge the gap between game development and Scrum. Clinton didn’t just slap the word “agile” onto games and call it a day; he brought a thoughtful, experienced view of how the process might actually work in creative teams.
And at the time, it made a lot of sense.
Studios were shipping boxed products or console updates. The most significant problems were long feedback loops, waterfall planning, and crunch. Scrum’s short cycles and team autonomy felt like a revolution. Suddenly, developers had more say. They could course-correct earlier. Planning wasn’t just a six-month Gantt chart anymore.
It was a massive upgrade from how things were being done.
But here’s the thing. That was 2010.
The game industry has moved on. How we build and operate games has changed completely, especially in mobile and LiveOps. Yet many teams still use Scrum the same way it was introduced 15 years ago.
That’s not Clinton’s fault. He’s since explored more flow-based methods, seeing the same limitations, as discussed in his latest instalment, Agile Game Development: Build, Play, Repeat (2nd Edition). The problem is that the rest of the industry hasn’t caught up.
Note: I highly recommend adding this book to your library.
So we keep running sprints like it’s 2010.
Even when the work we’re doing in 2025 has almost nothing in common with what Scrum was meant to handle.
LiveOps Is a Different Beast
LiveOps isn’t product development. It’s production, performance, and panic management; on a loop.
You’re not building a game from scratch. You’re keeping one alive. And that changes everything.
The work doesn’t arrive in tidy, sprint-sized chunks. Some features take weeks or months. A LiveOps event might involve design, art, audio, localisation, server-side config, QA passes, and a carefully timed release window.
And none of that counts if it’s not submitted to the app stores on time.
Even when you finish the work, you often can’t release it immediately. You’ve got to wrap it, test it, submit it, and wait for Apple or Google to approve it. Only then does it finally go live.
So the idea that you’re “delivering working software” every sprint? Not quite.
You might be finishing pieces of it. But players won’t see anything until months later. And when they do, it’s often part of a batch release, not a tidy sprint demo.
Scrum assumes a smooth flow of small, testable changes into the hands of users.
LiveOps gives you long chains of dependent work, external blockers, last-minute fixes, and a calendar that doesn’t care about your sprint schedule.
You’re managing content pipelines. Patch stability. Cross-team dependencies. Multiple time zones. Random exec requests.
It’s not that LiveOps can’t be agile. It has to be agile.
But maybe not the kind of agile Scrum gives you.
What Happens When You Use Scrum Anyway
You’ve probably tried it. Maybe you’re still trying.
Two-week sprints. Story points. Ceremonies. Jargon.
On the surface, it looks like you’re doing Scrum right. You’ve got a board. You’ve got a backlog. Tasks are groomed, standups are booked, and the burndown gently slows in the right direction.
But if you look a bit closer, things start to wobble.
Stories aren’t sized around value. They’re sliced around the sprint cadence calendar. You break meaningful features into fragments to make them “sprint-friendly”. Not because it’s better for the team, the players, or even the codebase, but because the sprint demands it.
And then something strange happens. Even tiny one-day tasks start taking the whole two weeks to move. Not because they’re hard, but because everything slows down to match the sprint rhythm. The work expands to fill the time you’ve given it. A simple config change that could’ve been merged before lunch sits untouched for days, waiting for the sprint to end.
Instead of improving flow, the process creates friction. The board’s full of motion, but nothing’s moving.
You’re not delivering faster. You’re just dragging out the small stuff and slicing the big things into bits no one understands.
Instead of delivering player-facing updates, you’re providing checklists.
“Set up analytics events.”
“Write config.”
“Implement UI tweak.”
“Update SDK.”
None of that is shippable on its own, but it ticks a box and gives the illusion of progress.
Come sprint review, there’s nothing to show. The actual feature is still in QA, awaiting a final asset, or tangled up in a release branch.
So what do you do?
You start shifting the definition of “done”. You say things like “done from engineering’s side” or “functionally complete”. You begin rolling stories over. Or worse, you mark them as done and quietly pretend they’re not blocked.
Meanwhile, retros drift into the same old topics: carryover, scope creep, and “We took on too much.” “We need better planning.”
The team feels it too. They’re ticking boxes, not delivering impact. The ceremonies become empty rituals. Planning feels disconnected from how the work flows.
And then someone inevitably says, “We’re just not doing Scrum properly.”
It is as if the process itself is perfect and you need fixing.
But what if the problem isn’t your execution? What if the process doesn’t suit the kind of work you’re doing?
Scrum wasn’t designed for overlapping content pipelines, external release constraints, or tightly coupled dependencies across teams. It assumes the team controls the whole delivery cycle, which is rarely the case in LiveOps.
So, you end up chasing fake metrics: velocity, sprint commitment, and burndown, which all feel like progress but don’t reflect actual outcomes.
You’re measuring throughput in a timebox that doesn't align with your real delivery cadence. You're planning around a rhythm that doesn't match how value reaches players.
It’s a perfect storm of wasted motion.
Everyone’s working hard. But not necessarily working smart.
And worst of all, because you’re “doing Scrum,” no one wants to question whether the framework is part of the problem.
But maybe it is.
Maybe it’s time to stop tweaking the ritual and start rethinking the fit.
Why Kanban (or a Flow-Based Approach) Might Fit Better
If Scrum feels awkward for your LiveOps team, it's probably because you're solving the wrong problem with the wrong tool.
So what’s the alternative?
Try treating your work like a flow problem instead of a sprint problem.
That’s where the Kanban strategy comes in. It's not a framework, not a religion, just a simple, visual way to manage how work moves through your system.
No ceremonies. No story points. No arbitrary two-week limits. Just clarity.
Kanban (and other flow-based approaches) focus on how long work actually takes to go from "started" to "done," not how many story points you can cram into a sprint.
It forces you to look at the real blockers: the messy handovers, the surprise dependencies, the stuff that slows you down but never shows up in velocity charts.
Instead of sprint planning, you manage flow.
Limit how much the team is working on at once
Pull in work when you’re ready, not because it’s Monday
Make bottlenecks visible
Focus on finishing, not just starting
It’s a better match for LiveOps, where work arrives in weird shapes and awkward times. Hotfixes, seasonal events, roadmap features, and content drops are all running in parallel.
Trying to smash all that into a sprint schedule is like playing Tetris with round blocks.
With a flow-based approach, you stop pretending work is tidy. You deal with it as it comes, in the order that makes sense, while staying in control.
And best of all, you can measure real things. Like cycle time. Throughput. Lead time. Stuff that helps you get better at delivering.
Kanban doesn’t tell you how to run your team. It shows you where the pain is and allows you to fix it.
It’s not sexy. There’s no big playbook. But it works.
Especially when your job isn’t to “ship every sprint” but to keep shipping.
Match the Rhythm, Not the Rule
Timeboxing isn’t the villain here. It can be helpful. It creates focus, helps with alignment, and gives you a natural moment to pause, reflect, and adjust.
But it only works if the timebox matches the rhythm of your actual work.
In LiveOps, that rhythm isn’t always every two weeks. Sometimes, you’re shipping weekly, sometimes fortnightly, and sometimes, your team is working on a four-week feature while running a live calendar of daily events.
So why are you all sprinting in two-week blocks, regardless of what you’re actually releasing?
It’s like dancing to a song no one’s playing.
The two-week sprint has become dogma. A default setting, a “Best practice.” But it only works when it fits the tempo of your game’s real-world delivery cadence.
If your team ships every Thursday, make Thursday your heartbeat.
If your events reset monthly, align your planning around that.
If content moves at different speeds across functions, plan around those cycles, not against them.
You don’t need Scrum’s sprint timer to be “agile”. You need feedback loops that match how and when you release value to players.
Set your tempo. Anchor your iterations to something real.
That way, the team isn’t rushing to finish fake slices of work for an invisible finish line. They’re delivering actual value, at a pace that makes sense.
Timeboxes are fine. Just don’t let them box you in.
Challenge the Process, Not the People
When Scrum isn’t working, the first instinct is to blame the team.
“We need to plan better.”
“We’re not committing properly.”
“We’re skipping retros.”
And sure, some things could be sharper. But more often than not, the real issue isn’t execution. It’s that the process doesn’t fit the work.
This is where things get uncomfortable. Scrum has become the default. It’s seen as the professional way to run a team, the mature choice, the proper method.
So when it falls flat, people rarely question the method. They question themselves.
The assumption is: “We’re doing it wrong.” The truth might be: “This isn’t the right tool.”
You wouldn’t tell a character artist to fix UVs with Excel. But we do the equivalent in production all the time. We use a framework designed for product discovery to run content delivery pipelines.
It doesn’t mean your team is broken. It means your context is different.
Scrum was designed for a particular kind of problem. The framework gets in the way when you’re not solving that problem.
That’s not failure. That’s feedback.
The smart move isn’t to double down on process theatre. It’s to pause and ask:
Is this still helping us do our best work?
If it’s not, change it.
Ditch what doesn’t serve you. Keep what does. Adapt the process to the team, not the other way round.
This isn’t about rebellion. It’s about respect for your team, time, and players.
Agile isn’t a set of rules. It’s a mindset. And sometimes, the most agile thing you can do is throw out the script.
Stop Worshipping the Sprint
Somewhere along the way, the sprint became sacred.
Has it stopped being a tool and started being the answer to everything, and not delivering? Could you add more processes? Feeling stuck? Plan harder. Still behind? Sprint harder.
But let’s be honest. Most LiveOps teams aren’t failing because they’re not sprinting well enough. They’re stuck because they’re trying to force unpredictable, messy, cross-functional work into a rigid, timeboxed format that doesn’t suit it.
The sprint is just a schedule. It doesn’t magically create value. It doesn’t make your players care. It doesn’t ship your builds.
You do that.
Your team does that.
And you don’t need to be stuck in two-week loops to be effective. You need to make your work visible, reduce friction, and ship when it’s ready.
That might mean abandoning sprints entirely. It might mean switching to a Kanban strategy. Or something else entirely. The point is to design your process around your actual work. Not the other way round.
You’re not a failed Scrum team. You’re a LiveOps team with different goals. Different constraints. Different rhythms.
So stop sprinting just because everyone else is.
Sprint if it helps. Don’t know if it doesn’t.
Either way, don’t be a zombie.