• Spec-driven development resembles waterfall planning but works in a completely different economic context

• Solo builders using AI agents treat upfront specs as thinking aids, not handoff documents

• The moment you add a second person or maintenance burden, the approach breaks in traditional waterfall ways

• Professional software development and vibe-production are different problem classes requiring different methods

I got into a respectful disagreement on LinkedIn recently. A developer had posted a critique of spec-driven development, citing evidence that it takes longer and produces worse results than iterative approaches. I commented that as a non-developer, I use SDD to deliver things alone that I could never deliver in the past. Workflow automations, production tools, time-savers. Yes, I produce a lot of markdown upfront, waterfall-style. But I’m also not “vibing” without the big picture and rebuilding ten times.

Subscribe now

The response was polite but firm. What I was describing wasn’t software development. It might work for small, self-contained automations where one person is both requester and user, but that’s not what professionals do. Professional software development involves changing requirements, multiple people, production systems, users whose needs you discover over time. The reason Agile moved away from big upfront specs wasn’t that planning is bad. It was that specs go stale the moment reality shows up.

He was right. And so was I. We were talking about different things entirely.

The waterfall-shaped ghost

Spec-driven development, at least in the way I practise it, looks exactly like waterfall from the outside. I write comprehensive markdown documents before any code gets generated. I specify interfaces, data structures, edge cases, error handling. I think through the whole system upfront. To someone who lived through the CASE tool era and the Big Design Up Front disasters of the 1990s, this looks like all the mistakes we already made.

The Agile Manifesto’s second value, “Working software over comprehensive documentation,” was written in 2001 by seventeen practitioners who had direct experience with heavyweight methodologies. Their collective wisdom was that working software, delivered iteratively, was more valuable than comprehensive upfront specifications. This wasn’t ideology. It was pain, distilled.

So when a professional developer sees me producing thousands of lines of markdown to generate hundreds of lines of code, the pattern-matching is immediate. This is waterfall. Waterfall failed. Therefore this will fail.

The mistake is assuming the same constraints apply.

What the spec actually does

In traditional waterfall, the specification is a handoff document. It’s how the business communicates requirements to developers who will build the thing, hand it to testers who will verify it, and eventually deliver it to users who will live with it. The spec has to be comprehensive because it’s crossing organisational boundaries. Once it’s written, changing it is expensive. Political, even. The cost of being wrong in a waterfall spec is high because course correction requires renegotiation, replanning, and rework across multiple teams.

In vibe-production, the spec is for me and the AI. There’s no handoff. There’s no team. There’s no political cost to being wrong. The spec is external working memory. It’s how I think clearly enough about a problem to delegate it. When the AI generates code that’s almost right, I don’t file a change request. I update three lines of markdown and regenerate. The iteration cost is seconds, not sprints.

The Agile Manifesto assumed two things: that the cost of change was non-trivial, and that communication between humans was the expensive part. Both assumptions are false in vibe-production. Change is cheap. There’s no communication overhead because there’s no second person.

The boundary conditions

Vibe-production works under very specific constraints. Violate any of them and it degrades into waterfall with all the traditional pathologies.

User equals builder. I’m building for myself. I know what I want. When the generated code doesn’t quite work, I know immediately because I’m the one testing it. There’s no requirements gathering phase because there’s no gap between what I need and what I understand.

No handoff. The spec never leaves my head. I’m not writing it so someone else can implement it. I’m writing it so I can think clearly. The moment I need to hand this to another developer, the spec becomes a contract and all the waterfall problems return.

Instant iteration. When something doesn’t work, the fix is a markdown edit and a regenerate. There’s no pull request, no code review, no deployment pipeline. The entire loop from “this is wrong” to “this is fixed” takes minutes.

Personal maintenance burden. I’m the one who’ll maintain this. If I cut corners, I pay the price. If I over-engineer, I pay that price too. The feedback is direct and immediate.

Self-contained scope. I’m building workflow automation, not distributed systems. The problem fits in my head. The spec fits in one document. There are no integration points with other teams’ code, no shared databases, no service boundaries to negotiate.

Remove any one of these constraints and the approach breaks. Add a second developer and you need shared understanding. Add a product owner and you need negotiation. Add a six-month maintenance window and you need the spec to stay current. Add changing requirements from external stakeholders and you need the ability to pivot without rewriting the entire foundation.

Those are the conditions where Agile works and waterfall fails. Vibe-production doesn’t operate in those conditions.

Why producers are positioned for this

Game producers spend our careers spec’ing work for others. We know what a good specification looks like. We understand scope. We know what “done” means. We’ve written enough design documents and acceptance criteria to recognise when a requirement is testable and when it’s wishful thinking.

This makes us unusually well-suited to vibe-production. We already think in the structured way that AI agents need. We already know how to externalise complexity into documents. We already have the discipline to think through a problem before asking someone else to solve it.

But this only works for a specific class of problem. I can use vibe-production to automate my weekly stakeholder reports, generate my milestone dependency matrices, or build tools that parse Jira exports into useful formats. These are tasks that were never going to justify professional development resources. They’re too small, too specific, too personal.

The moment I need to build something for my team, the rules change. Now I need working software that someone else can modify. I need tests that someone else can run. I need architecture that someone else can extend. I need all the things Agile optimises for: communication, adaptation, shared understanding.

Vibe-production doesn’t replace professional development. It expands the category of problems I can solve alone.

Different problem classes

The question that came up in that LinkedIn thread was “Why should software be built by the masses?” The framing assumes the masses are trying to do what professionals do, just worse.

That’s not what’s happening.

There’s a vast category of automation that was always too expensive to professionalise. Workflow tools that save you two hours a week. Scripts that reformat data from one system to another. Dashboards that pull together metrics you check every morning. None of these justify a sprint. None of these deserve a ticket in the backlog. But they add up.

Before AI agents, these problems had two solutions: live with the friction, or learn to code well enough to solve them yourself. Most people chose the first option. Now there’s a third option: write a clear specification and let the AI generate the implementation.

This isn’t amateurs trying to build production systems. It’s individuals solving problems that were never going to be production systems in the first place.

The professional developer who sees this and thinks “waterfall” isn’t wrong about the shape. They’re wrong about the context. The upfront spec looks like Big Design Up Front because both involve writing comprehensive documentation before code. But BDUF failed because the documentation was a contract between humans with misaligned incentives and imperfect communication. Vibe-production uses documentation as a thinking tool for one person working with a deterministic agent.

Same shape. Different function. Different constraints. Different failure modes.

What matters is the boundary

The hard part is knowing where the boundary is. At what point does adding a second person, or a longer maintenance window, or a changing requirement from someone else tip you over from vibe-production into bad waterfall?

I don’t have a formula. But I know the smell. If I’m writing the spec and thinking “this needs to be clear for the developer who picks this up in six months,” I’ve crossed the line. If I’m negotiating requirements with a stakeholder, I’ve crossed the line. If I’m building something that will integrate with someone else’s system, I’ve crossed the line.

Inside that boundary, vibe-production works. The waterfall-style spec is a thinking aid, the AI is a force multiplier, and the iteration speed is high enough that being wrong is cheap.

Outside that boundary, you’re doing software development. Use the practices that work for software development. Don’t pretend the upfront spec will save you. It won’t.

Leave a comment

The developer who challenged me wasn’t wrong about spec-driven development in professional contexts. He was defending hard-won lessons about what fails at scale, under change, with teams. Those lessons are still true.

But they don’t apply to me, alone, building a tool that saves me an hour a week, that I’ll maintain myself, that no one else will ever touch.

Different problem. Different method. Both valid.

• Most producers use AI through a chat box, missing the real power: agentic workflows where agent teams work on production deliverables like spec authoring, dependency audits, and test plan generation

• The five skills that make great agentic producers are prompt precision, taste as filter, context architecture, egoless iteration, and knowing when to intervene

• Producers already have these skills through game development expertise: understanding what makes features fun, how cross-discipline teams coordinate, what realistic production pipelines look like

• Game production domain knowledge (knowing what good looks like across design, engineering, art, QA) is what turns agents from assistants into force multipliers

Most producers I see use AI like a better search engine. Ask a question, get an answer, move on. “How do I structure this sprint?” “What should go in this acceptance criteria?” “Give me a template for a design spec.” One question, one answer, done.

Subscribe now

They’re missing the real power.

I was sceptical for a long time. Thought agentic workflows were hype. Interesting for engineers maybe, but not useful for actual production work. Too complex, too unreliable, too much overhead for what you’d get back.

Then I started using them properly. Not for chat. For real production deliverables. Spec authoring from design briefs. Dependency audits across milestone documentation. Jira board setup and automation through an API. QA test plan creation. Report automation. The work producers actually do.

And halfway through a dependency audit across a hundred design documents, I stopped. Because I realised something.

I wasn’t learning new skills. I was using production skills I already had.

The difference between chatting with AI and running agentic workflows is the difference between asking your team a question in Slack and actually managing production.

Chat is disposable. You ask, it answers, the context disappears. Every question starts from zero. It’s useful for quick lookups, sure. But it’s not how you ship a game.

Agentic workflows are different. Multi-step processes. Persistent context. Agents working on actual deliverables over time, the same way your team works on features over sprints. You’re not asking questions. You’re delegating work, reviewing output, and iterating on results.

Spec authoring: the agent drafts from the design brief and GDD authority, and you review for coherence and feasibility. Dependency auditing: the agent cross-references documents to identify conflicts, and you validate against the milestone reality. Jira automation: the agent creates stories from approved specs, and you spot-check the taxonomy and acceptance criteria. QA test plans: the agent generates scenarios, and you add domain-specific edge cases. Report generation: the agent compiles metrics and flags blockers; you edit for political context. Documentation sync: the agent maintains the structure and labels, and you audit the information architecture.

If you’re still using AI like a chat box, you’re ready for the next step. The skills you need? You already have them.

There are five qualities that separate great agentic producers from people just clicking “generate” and hoping. And every single one is something you already practice daily.

Prompt precision over prompt volume

The best agentic producers know how to decompose work into tight, well-scoped instructions. They feed agents exactly what’s needed to produce clean output, and nothing more.

You already do this. You understand the game development process. You know what’s in scope for a sprint and what’s deferred to the next milestone. You know which dependencies are on the critical path and which are nice-to-have. You know what edge cases break features because you’ve seen them break features.

When you write a ticket, you don’t dump a wall of requirements and hope engineering figures it out. You scope it. You define success. You specify acceptance criteria. You know what information design needs, what engineering needs, what QA needs, because you understand how those workflows intersect.

That same skill applies to agent briefs. Tight scope. Explicit success criteria. Clear instructions. You’re not learning this. You already know it.

Taste as a filter

The best agentic producers have strong instincts for what good output looks like. They can instantly judge whether generated work is good, mediocre, or subtly broken. The agent produces. They curate.

You already have this taste. Across disciplines.

You know what makes a feature fun versus what just sounds good in a design doc. You know what realistic test coverage looks like because you’ve reviewed QA plans that claimed to be comprehensive but missed obvious cases. You know whether acceptance criteria actually validate the mechanic or just look thorough. You’ve shipped games. You’ve reviewed hundreds of specs. You’ve sat through playtest debriefs where players broke things you thought were bulletproof.

When an agent generates a dependency audit, you can spot the plausible-but-wrong findings immediately. Because you know the actual milestone structure. You know which systems are genuinely coupled and which just happen to use similar terminology. You know what’s technically possible within the engine constraints.

Your expertise is the filter. The agent can generate output at speed. You’re the one who knows if it’s correct.

Context architecture

The best agentic producers are deliberate about what lives in system prompts, what goes in memory, what gets passed per-request. They understand that agent output is only as good as the context it’s given, and they design that context like a system.

You already architect information. Daily.

You know what’s GDD canon versus implementation detail. You know what naming conventions mean and why they matter for cross-team communication. You know how milestones relate to each other, what deliverables have dependencies, what documentation lives where. You understand how teams share knowledge: what belongs in Confluence versus what’s tribal knowledge, what context engineers need versus what designers need, what QA validates versus what production tracks.

That same expertise applies to agent context. What goes in the system prompt? GDD authority, naming conventions, milestone structure. What gets passed per-request? The specific document to audit, the exact scope for this sprint. What lives in memory? Project-level knowledge that persists across tasks.

You’re not learning context architecture. You’ve been doing it for years. You’re just applying it to a different type of team member.

Your expertise is the filter. The agent can generate output at speed. You're the one who knows if it's correct.

Iteration without ego

The best agentic producers treat every output as a draft, not a verdict. They’re fluent in the regenerate, refine, redirect loop. They don’t get attached to any particular version. Speed comes from not overthinking each step.

You already work this way. Because you know production is iterative.

Nothing ships in first draft. Not design docs. Not builds. Not schedules. You refine specs based on playtest feedback. You adjust timelines when blockers emerge. You pivot when features don’t land. You’ve sat in retrospectives where the team tears apart what just shipped and figures out how to do it better next time. You don’t take it personally. It’s just the process.

Agent output works the same way. First pass is discovery. Second pass is refinement. Third pass might be a complete redirect because you learned something in the review. You’re not precious about any individual output. You’re focused on the result.

This is why producers are naturals at agentic workflows. Engineers sometimes struggle with this because they’re trained to get code right the first time. Producers know nothing is right the first time. It’s always iteration.

The disciplines that make you good at production are identical to what makes agentic workflows productive.

Know when to take the wheel

The best agentic producers recognise the ceiling of what agents can reliably do. They’re not afraid to drop in directly when the task demands it. They use agents as force multipliers, not replacements for craft.

You already make this call. Daily.

You know what to delegate to each discipline and what needs producer attention. You know when to let engineering solve the implementation and when to step in because the solution needs to serve design constraints. You know when QA can validate independently and when you need to be in the build yourself because the edge case is subtle. You know when to trust the process and when the process is about to drive off a cliff.

You understand where complexity lives in game development. What’s formulaic versus what requires judgement. What’s process versus what’s craft. What can run on autopilot versus what needs a producer’s hand.

Agents are the same. Let them handle Confluence labelling and Jira story formatting. Do the milestone planning yourself. Let them generate test scenarios. You add the domain-specific edge cases that only someone who’s shipped games would think of. Let them compile metrics. You write the stakeholder update because you know the political context.

The judgement of when to delegate and when to intervene? You already have it.

Here’s what matters about all five of these skills: they’re not AI skills. They’re production skills.

Agents don’t know if a feature is fun or just functional. They don’t understand team dynamics. They can’t tell you what design needs from engineering, or what QA can realistically validate in a sprint. They don’t know if a dependency is critical-path or nice-to-have. They have no sense of production reality: what ships, what gets cut, what’s a genuine blocker versus what’s negotiable.

You know all of this. Across disciplines. Design, engineering, art, QA, pipelines. You’ve seen what works and what breaks. You know what good looks like because you’ve shipped games and you’ve seen games fail to ship.

That expertise is what makes agent output correct, not just plausible. An agent can generate a test plan. You’re the one who knows if it actually tests the feature. An agent can flag dependencies. You’re the one who knows if they matter. An agent can draft acceptance criteria. You’re the one who knows if they validate the mechanic or just sound comprehensive.

Your domain knowledge is the unlock. Everyone else is guessing. You already know.

I started sceptical because I thought agentic workflows were a technical skill I’d need to learn. Some new discipline layered on top of production work. More overhead, more complexity, uncertain return.

I was wrong about what the skill was.

When I started using agentic workflows for actual production work, I realised I wasn’t learning anything new. I was applying production expertise I already had. Scoping agent tasks the same way I scope tickets. Architecting context the same way I architect information flows across tools. Reviewing output the same way I review specs. Iterating the same way I iterate on features. Deciding when to intervene the same way I decide when to step into a discipline’s workflow.

The disciplines that make you good at production are identical to what makes agentic workflows productive.

Which means if you’re a game producer, you’re already trained. You just didn’t know it had a name.

Most producers are still using AI like a better Google. One question, one answer, move on. They’re missing the step where you stop asking questions and start delegating work. Where you stop chatting and start managing agents the way you manage production.

Leave a comment

The skills you already have are exactly what agentic workflows demand: understanding what makes games work, how teams coordinate, what realistic pipelines look like.

You’re already trained. You just need to recognise it.

• A producer using Claude Code can do the job of two or three producers. That gap is already opening.

• The advantage goes to producers who use AI. The distance between them and everyone else is widening fast.

• Claude Code turns Jira from an admin burden into an execution layer: epics, stories, labels, and fix versions generated programmatically from spec documents.

• Institutional memory, decision trails, and spec-to-ticket sync can be maintained by one person where it previously required a team.

It was a Tuesday afternoon, and I was looking at a complete Jira epic hierarchy, properly labelled, with fix versions attached, Confluence links wired to every story, the whole thing triangulated back to a SQLite database that would let me push scope changes across sixty tickets in a single command. I had built it that morning. Built it from scratch: the spec infrastructure, the push script, the decision trail, the sanitation layer for external AI artefacts.

Subscribe now

Three months earlier, something equivalent had taken me and two colleagues the better part of a week.

I sat with that for a while.

I want to be honest about where I was before this. I was not worried. I’d been a producer for thirty years. I’d seen a lot of things that were supposed to change everything, and most of them changed some things, incrementally, and the job kept going. The discourse around AI and jobs felt like the same pattern. Lots of energy. Lots of conference panels. The actual work stayed the same.

I was wrong, and I think I was wrong in a specific way worth naming.

The thing I kept evaluating was whether AI could do the producer’s job. Could it run a sprint? Could it manage stakeholder conflict? Could it make the call when two equally important things were both at risk and you had to pick one? I concluded it couldn’t, and I moved on.

The question I kept missing was whether a producer using AI could do the job of two or three producers. That’s a different question, and it has a different answer.

The question I kept missing was whether a producer using AI could do the job of two or three producers. That’s a different question, and it has a different answer.

The system I’ve built has two parts that interlock, and the interlock is the point.

The first part is documentation infrastructure. Everything lives in a single versioned repository. It syncs to the team wiki automatically. When a document comes in from an external AI tool, a sanitation layer reconciles it to project standards before it enters the system: terminology, formatting, cross-references, authorship. The reconciliation happens on ingest, not as manual policing after the fact.

Every open question becomes a structured decision card. The question gets answered, the rationale is recorded, and the trail is auditable. When something changes, the system knows which documents depend on which other documents. Requirements that haven’t been built yet still inform foundational design decisions, which is how you reduce rework rather than just managing it.

Process documentation lives alongside the product being built. When the team changes, or when I come back to something six weeks later, context survives. Decisions survive. The reasoning behind decisions survives.

The second part is Jira, turned from an administrative burden into an execution layer.

Tickets are generated from spec documents programmatically. The full epic-to-story hierarchy comes from the database in one command, with correct labels, fix versions, and Confluence links already attached. When a scope decision changes, say a screen moves from MS1 to Alpha, the fix version on every affected ticket updates in one operation. One operation.

Labels are load-bearing. Every ticket is tagged with domain, milestone, and doc type at creation. A developer can go from ticket to spec to wireframe in two clicks. When a PRD is accepted, its functional requirements can be parsed directly into Jira epics and stories. The loop from product intent to executable ticket closes programmatically. The database is the source of truth; the push script reads from it and writes keys back, so the database, Jira, and the specs stay triangulated at all times.

What I’ve described sounds like tooling. It is tooling. But the thing it represents is something else.

Producers have always spent a significant portion of their time on work that is necessary but not valuable. Maintenance. Reconciliation. Making sure the ticket matches the spec. Making sure the spec reflects the decision. Making sure the decision was actually recorded somewhere. Policing consistency across documents that were written weeks apart by people who no longer work here. Answering questions that had already been answered but weren’t findable.

That work is real. It consumes real hours. It requires real attention. And it adds no value to the product whatsoever.

I’ve been doing it for thirty years, and I’ve watched everyone around me do it too, and we all accepted it as part of the job because there was no alternative. The alternative was chaos.

That work is real. It consumes real hours. It requires real attention. And it adds no value to the product whatsoever.

There is now an alternative.

The hours I used to spend on reconciliation work are gone. The spreadsheet tracking which tickets needed updated labels is gone. The “let me check the latest version of that doc” conversation is gone. The “I need someone to help me generate all the stories for this epic” request is gone. All of that disappeared because I built a system, with AI, that makes those problems structurally impossible.

That’s the shift. The system is architecture, and architecture changes what a single person can maintain.

Here’s what that actually means for headcount.

I can currently maintain, with one person, what used to require a team to police manually. I can execute, in an afternoon, what used to require a week of coordination. I can absorb a scope change across the entire project in a single session that leaves a clean audit trail and updated tickets. I can onboard a new team member into full project context in a fraction of the time, because the context is structured and findable and current.

Studios are not going to look at this and think: great, we’ll keep the same number of producers and let them work on more interesting things. Some will. Most won’t. Most will look at it and think: we used to need four of these. Now we need two.

The arithmetic is simple. And the producers who end up on the wrong side of it will be replaced by someone like me, who spent a few months building something that didn’t exist before, and now does the work of a small team.

Studios are not going to look at this and think: great, we’ll keep the same number of producers and let them work on more interesting things. Most will look at it and think: we used to need four of these. Now we need two.

I didn’t build this because I saw it coming. I built it because I had a specific problem: project context evaporating at team transitions, spec-to-ticket reconciliation eating my Fridays, scope changes causing cascading inconsistencies I kept catching too late. I kept reaching for Claude Code to solve specific pieces of it, and the pieces kept connecting.

I was thinking about whether the push script was reading the right columns from the database. The implications came later.

The implications only became clear on that Tuesday afternoon, when I looked at what I’d built and tried to remember what I used to do instead, and realised that what I used to do instead involved other people.

I’m not early to this. I was actively late. I resisted it. I had reasonable-sounding arguments for why the job was safe and why the discourse was overblown. Some of those arguments were correct, in the narrow way that arguments can be technically correct while completely missing the point.

Leave a comment

The thing that finally got through to me was a Tuesday afternoon, a complete Jira hierarchy I’d built before lunch, and a quiet realisation that the version of this job I’d been doing for thirty years had just changed permanently.

Deep Dive by NotebookLM.

• Ryan Rigney’s post on “deprofessionalisation” hit a nerve, exposing how the games industry is shedding roles once seen as essential, triggering both fear and fierce debate.

• As studios downsize and bloated teams are cut, smaller teams and indie developers are stepping up, thriving on creative freedom and leaner production.

• The shift is messy but energising, forcing the industry to re-examine what truly matters: craft, care, and collaboration over titles and process.

So, Ryan K. Rigney Lit a Fire

It started with a tweet. Or maybe a Substack post. Either way, Rigney kicked off a conversation the games industry wasn’t quite ready for.

He used the word deprofessionalisation, and boom, off it went. Some people nodded along. Others rolled their eyes so hard they nearly sprained something. The takes came in hot.

Subscribe now

His post painted a messy, uncomfortable picture. Fewer jobs. Leaner teams. A shrinking definition of what counts as "essential". It wasn't doomposting, but it wasn’t exactly cheerful either.

What made it land and sting was that it felt true. Not entirely. Not for everyone. But true enough to get under your skin. Especially if you’ve ever had to explain why your job matters right before it gets cut.

The response? Mixed. Angry. Hopeful. Exhausted. Some saw it as a warning. Others saw an opportunity. A few saw both and couldn’t decide whether to panic or start prototyping.

This post isn’t here to settle the debate. It’s here to dig into it. To poke at the fear, the frustration, and the weird bit of optimism hiding underneath.

Whether you love the word or hate it, the shift is happening. And we’re all trying to figure out what to do with it.

Professionalism: A Blessing and a Bloat?

Once upon a time, making games was chaotic. A few mates in a room, no titles, no pipelines, just vibes and ambition. Then the industry grew up.

With growth came structure. Studios scaled. Roles multiplied. Suddenly, there was someone for everything: producers, technical artists, brand managers, UX designers, build and release engineers, and suddenly, every problem had a specialist and a Slack channel.

On paper, this was a win. Specialisation meant expertise. Dedicated QA caught more bugs. Marketing knew how to package a game for launch. Writers get to write full-time. It started to feel like a proper profession.

But with professionalism came the bloat. More layers, more process, more people who weren’t making the game but had strong opinions about it. Some necessary, some… less so.

The big studios became machines. Polished, yes. Efficient, sometimes. But also slow, top-heavy, and increasingly risk-averse.

And then, quietly, things started breaking. Layoffs hit roles seen as non-essential. Not always fairly. The axe often landed on those who held things together behind the scenes.

Rigney warned that jobs “that seem replaceable to management (even if they’re not)” would be first to go. He wasn’t wrong. Marketing teams, community managers, writers, artists, producers... all trimmed, all called overhead.

That’s the hard bit. Professionalism gave people careers. It brought legitimacy. And now, it’s starting to look like a luxury some studios think they can’t afford.

Or worse, don’t value.

Enter the Panic: Are We Just Watching It All Fall Apart?

Here’s where things get uncomfortable.

The term deprofessionalisation freaks people out. And honestly, fair enough. It sounds like a slow-motion collapse. Like the rug’s being pulled out from under thousands of careers.

For some, it already has been. Roles that once felt safe are now marked as optional. Entire teams cut loose. Specialists replaced with generalists. Or worse, with “we’ll figure it out later”.

Writers, audio folks, and artists are especially vulnerable. Not because they aren’t vital, but because they’re often misunderstood. They get lumped in as asset creators and stuff factories. Tick the box, move on.

The nuance of their work gets lost. And when polish is treated as a nice-to-have rather than part of the craft, quality takes a hit. One commenter put it bluntly: “Polish barely fucking matters anymore.”

Another described it as “an acceleration into shit”. Cheap beats good. Fast beats thoughtful. And no one’s got the time or budget to argue otherwise.

Outside of games, the same trend plays out. In medicine, law, academia, deprofessionalisation usually means less autonomy, more oversight, and a hollowing out of purpose. You still do the work, but you don’t own it anymore.

Some say we’re heading there too. Fewer decisions are made by people who know games. More driven by finance, metrics, and fear. That’s what’s chilling.

It’s not just about losing jobs. It’s about losing what made those jobs meaningful in the first place.

But Also… Isn’t This Kinda What Some People Wanted?

Here’s the twist.

While some mourn the loss of structure, others crack open a beer and say, “Finally.”

The rise of small teams and solo developers isn’t just a response to layoffs. It’s a reaction to years of corporate sludge. Endless meetings. Bloated teams. Projects that drag on for years and still miss the mark.

Indie devs aren’t just surviving. They’re thriving. Steam’s full of weird, scrappy, brilliant games made by two or three people who just wanted to make something fun. And players are buying them.

Unlike other creative industries, games still have a commercially viable indie scene. You can go small and still make a living, if you’re good, lucky, or both.

Some call this whole shift long overdue. A market correction. Less money is wasted on middle management, and more is in the hands of actual creators.

The big studios? Seen by many as bloated and visionless. Too cautious. Too corporate. People are tired of “prestige” games that feel more like tech demos than entertainment.

In contrast, indies are scrappy, fast, and unapologetically weird. They take risks. They ship. They remind people what making games used to feel like.

So yes, the traditional structures are shaking. But not everyone sees that as a bad thing. For some, it’s the first time the industry feels exciting again in ages.

The Trouble with ‘Deprofessionalisation’

Right, let’s talk about the word itself. Deprofessionalisation. Bit of a mouthful. Bit of a mood killer.

It sounds more polite than “You’re not needed anymore.” And it rubs people the wrong way, especially indie devs who work ridiculous hours, wear ten hats, and still get called “not professionals”.

It also creates a false divide. Big studio: professional. Solo dev: hobbyist. That’s nonsense. Plenty of solo devs run tighter, more disciplined projects than teams ten times their size. I have witnessed huge teams burning millions a month running like a complete shit-show.

Worse, the term can erase the grey area. What about the folks at mid-sized studios? Or freelancers? Or people who left AAA because it broke them, but still take their craft seriously?

This isn’t a neat split between heroes and villains. It’s messier than that. There are brilliant people in big studios and absolute chaos merchants in small ones.

Then there’s the sneaky subtext. Deprofessionalisation often comes with decisions about who’s “essential”. Coders? Sure. Designers? Maybe. But community? QA? Narrative? Suddenly they’re “nice to have”.

That kind of thinking is dangerous. It chips away at collaboration. It narrows the definition of what it means to make a game. It turns a creative process into a production line.

And let’s be honest. It’s usually not the creatives making those calls. It’s finance. It’s ops. It’s someone with a spreadsheet who’s never shipped a game.

So yes, things are changing. But calling it deprofessionalisation might be missing the point. It’s not that we’re becoming less professional.

Some have decided that only a few roles are “real” work.

Opportunity in the Wreckage

Now, deep breath. It’s not all doom.

Yes, jobs are vanishing. Yes, the safety nets are wearing thin. But in the cracks, something new is growing. And it’s not nothing.

Plenty of folks see this shift as a reset. A painful one, sure, but maybe a necessary one. Less about burning everything down, more about clearing out the junk that stopped games from getting made.

Rigney calls it damage, but also says there’s “light shining through the cracks”. You can feel that in how people talk about their projects now. Small, weird, risky, and full of heart.

Indies aren’t just filling the space left behind. They’re changing the shape of the industry. They show that games don’t need massive teams or triple-A gloss to connect with players.

That’s exciting. That’s power shifting back to the people making the actual stuff. Not consultants. Not investors. Actual devs.

And maybe that’s the point. It’s not about losing professionalism. It’s about losing the bits that got in the way, the bloat, the box-ticking, the meetings that killed momentum.

People are making games again because they want to, not because a planning document said they had to.

That kind of creative freedom? It’s not a perk. It’s the point.

What Now? Embrace the Mess (But Stay Awake)

So, where does that leave us?

Somewhere in the middle, most likely. Half-panicked, half-hopeful. Watching things fall apart while trying to build something better simultaneously.

This shift isn’t tidy. It’s not fair, either. People are being squeezed out of careers they’ve worked hard to build. Whole disciplines are getting sidelined. That deserves more than a shrug.

At the same time, there’s real energy coming from the margins. Smaller teams. Faster cycles. Less fluff. More room for weird ideas and voices that don’t fit the corporate mould.

But if we’re not careful, we could lose something valuable. Not just jobs, but standards, mentorship, and quality. Structure isn’t always the enemy. Sometimes it’s the thing that helps people grow.

The trick is to take what worked, the craft, the care, the collaboration, and bin what didn’t. The bloat. The burnout. The culture of meetings over making.

This isn’t about picking sides. It’s about keeping your eyes open. Supporting each other. Calling out rubbish when you see it. And not letting a trendy term justify bad decisions.

There’s no neat fix. Just a messy, ongoing shift. And if we’re lucky or stubborn, we might build something better out of it.

A Bit of a Shambles, but It’s Our Shambles

Let’s not pretend this is a clean break. It’s a bit of a mess. Roles disappearing, teams scrambling, whole studios rethinking what “essential” even means.

But that’s the industry right now. A slow-motion shake-up with no clear winner. And maybe that’s fine.

Because out of the rubble, there’s something real. Not perfect. Not polished. But real. People making games with whatever tools and energy they’ve got left. People carving their own path, outside the usual ladders and titles.

It’s scary, yes. But also kind of thrilling.

Maybe this is what growing up (again) looks like. Letting go of the old rules. Building new ones that actually serve the people doing the work. Fighting for roles that matter, not just the ones with the loudest defenders.

The term deprofessionalisation might stick. Or it might fade like every other awkward buzzword. Either way, the shift is happening.

And if this is the new normal, half-chaos, half-opportunity, we might as well own it.

A bit of a shambles, sure.

But it’s our shambles. And we’re still making games.

Leave a comment

Final Thoughts: Keep Making, Keep Pushing

If there’s one thing the past few years have proved, it’s this: the people who care about games care.

Even as the structures wobble, the passion doesn’t. People are still showing up. Still building. Still finding ways to ship things that matter.

The industry might feel like it’s in flux, because it is. Titles mean less. Studios aren’t forever. And the old rules don’t guarantee much anymore.

But that doesn’t mean we throw in the towel.

It means we fight smarter. Support indies. Back specialists. Share knowledge. Push for environments where creativity isn’t crushed under process or profit.

Perhaps we should reconsider the notion that “professionalism” is what has made this industry great. It wasn’t the org charts or the shareholder decks. It was the people who gave a damn.

So, whether you’re running a studio or building something in your spare time, keep going.

Keep making. Keep pushing.

The future’s messy. But it’s still up for grabs.

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.

Subscribe now

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.

Leave a comment

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.

Deep Dive by NotebookLM.

• Most teams misuse timeboxes as deadlines instead of strategic limits, leading to rushed releases and wasted effort.

• Smart timeboxes set clear quitting criteria upfront and vary based on risk, scope, and context. Not fixed durations.

• Success means knowing when to stop; quitting early isn’t failure; disciplined decision-making saves time and money.

Let’s get one thing straight: most teams use timeboxes wrong.

They treat them like deadlines. Quiet little waterfalls disguised as agile. Sprints, for example, get treated as fixed delivery windows: “We’ll work on this for two weeks, then ship.” No matter what. Doesn’t matter if the thing’s half-baked, poorly scoped, or not working. The time’s up, so we push it out, or worse, we keep going because we’ve “already spent so much time”.

Subscribe now

The same thing happens with release cadences. A team shipping every two weeks often starts working backwards from that date, rushing work just to hit the window, instead of asking whether the thing is ready or worth releasing.

That’s not smart. That’s just inertia wrapped in process.

A good timebox isn’t a cage; it’s a bet. A conscious, strategic limit. You say, “We’re willing to spend this much time trying to solve this problem. If we haven’t cracked it by then, we stop. We reassess. We try a different angle. Or we walk away.”

That’s not failure. That’s the point.

Annie Duke Was Right: You Need to Know When to Quit

Most teams don’t have a quitting strategy. They have a shipping strategy, a delivery pipeline, and a sprint backlog, but no plan for when to stop. That’s where Annie Duke’s thinking hits hard.

In her book Quit, she argues that good decision-makers set quitting criteria before they start, not after things go wrong, not once morale’s dipped or budgets are gone, but before, when their heads are still clear. They’re not emotionally invested in a single path.

It’s a way of avoiding what she calls the “escalation of commitment”. The classic trap where we double down just because we’ve already invested time, money, or effort. “One more sprint,” we tell ourselves. “We’re nearly there.” But we’re not. We’re stuck. And now we’re burning time, and we’ll never get back.

In LiveOps, this shows up everywhere:

• Features we keep polishing even though nobody’s asking for them

• Tech rewrites that start as a “small refactor” and eat the roadmap

• Experiments that quietly drag on because no one wants to call them dead

When used properly, timeboxes give you an off-ramp. They say if we haven’t reached this outcome by this point, we stop. Not later, not eventually, but now.

You’re not quitting blindly—you’re quitting smart.

Fixed Timeboxes, Variable Wisdom

Most teams treat timeboxes like they’re all the same. Two weeks. Four weeks. Whatever the sprint length or release cadence is. It doesn't matter what the problem is or how risky it is, we slot it into the same box and hope it fits.

That’s lazy thinking.

Timeboxes should be variable. You set them based on the system you're working in and the problem you're trying to solve.

• Low risk, clear scope? Could you give it a short leash?

• High risk, loads of uncertainty? Maybe it needs more time, but more importantly, it needs sharper exit criteria

This isn’t about gut feel. It’s about risk awareness. Business risk. Technical risk. Team capacity. Opportunity cost. You’ve got to consider all of that if you want the timebox to mean anything.

If you slap the same duration on every piece of work, you’re not timeboxing, you’re just blocking out your calendar.

Smart timeboxes are situational. They change based on what’s at stake, your confidence, and how much you can afford to get it wrong. That requires judgment. And a bit of backbone. Especially when someone says, “Can’t we just give it another release?”

You could. But should you?

Timeboxes Are Upper Bounds, Not Targets

Here’s a common mistake: treating the timebox like a minimum commitment. “We’ve got two weeks, so we may as well use the full two weeks.” No. Just no.

A timebox is an upper bound, not a target to hit.

If you solve the problem on day three, you’re done. Celebrate. Ship it. Move on. There’s no bonus prize for dragging it out. You don’t get extra points for “using the time well” if the work’s already finished.

The goal of a timebox isn’t to keep people busy; it’s to create a boundary. It forces clarity: “Are we still getting value from this, or are we just ticking down the clock?”

When teams treat sprints or release windows as deadlines instead of opportunities to reassess, they’re more likely to:

• Stretch work just to fill time

• Polish things no one asked for

• Avoid making decisions early, even when the signal is obvious

And here’s the kicker: if your team isn’t allowed to act on what the timebox reveals. If they can’t pivot, pause, or quit, it’s not a timebox. It’s just a fixed deadline in disguise.

The whole value of a quitting criterion is in the optionality. Do you have any option to walk away? No decision is being made, just motion for motion’s sake.

The best teams move fast and quit fast. They know when a solution is good enough and don’t wait around just because the calendar says they can.

Using less time than you planned isn’t a waste. It’s a win.

What This Requires From You

All of this sounds great in theory. But in practice? It only works if you’ve got people who can think beyond their ticket queue.

Using timeboxes as quitting criteria means making judgment calls. That takes more than technical skill; it requires situational awareness.

• Business awareness – What’s the cost of being wrong? What’s the value of being right?

• Technical awareness – What’s feasible in this timeframe? What are we pretending we understand?

• Risk awareness – Where are the unknowns? What happens if this doesn’t land?

It also takes courage. Quitting is uncomfortable. It can feel like failure, especially in delivery-obsessed cultures. But sticking with a bad idea to look busy? That’s not heroic. That’s expensive.

This is where most teams stumble. They don’t set clear outcomes. They don’t align on what happens if those outcomes aren’t reached. Or worse, they do, but no one wants to make the call when the time comes.

If you want timeboxes to work as quitting criteria, you must build a culture where walking away isn’t taboo. “This isn’t working” is a sign of intelligence, not defeat.

Counterarguments (and Why They’re Weak)

This kind of thinking tends to make a few people nervous. You’ll hear the usual objections. Let’s deal with them.

“But what about commitment?”
This isn’t about flakiness. It’s about committing to the right thing. You’re still aiming for outcomes, you’re just not blindly sticking to one method, one path, or one solution. That’s not commitment. That’s rigidity.

“It’ll look like failure.”
It is failure; strategic, controlled, affordable failure. The kind you want. You’ve learned something. You’ve cut your losses. You’ve freed up time and money for better bets. If your studio can’t stomach that, your problem isn’t timeboxes; it’s leadership.

“We need predictability.”
This is predictability. You’re setting clear time limits, criteria, and decision points. What’s unpredictable is pretending a doomed plan will work if you keep going. That’s chaos disguised as discipline.

“The team will get demoralised.”
What’s more demoralising: knowing upfront what success looks like and when to stop, or working on something for weeks that quietly goes nowhere? Trust me, teams prefer clarity. Even if the answer is “We’re done. Let’s try something else.”

How to Make Timeboxes Work Like This

It’s one thing to talk about quitting criteria; it’s another to use them. Here’s how to build timeboxes that push clarity and protect your team’s time, whether it’s a sprint, a release cycle, or a fixed window for an experiment.

1. Define a clear “success state” before you start: Don’t just timebox the effort; timebox the outcome. What will be true if this work is worth continuing? Be specific. “We’ll see a 10% uplift in engagement” is better than “We’ll see some improvement.”

2. Align on the exit plan: Make sure everyone agrees on what happens if you don’t hit that state. Will you pivot? Kill it? Try one more variation? This should not be a surprise when the timebox ends.

3. Right-size the timebox for the problem: Don’t default to two weeks. Consider risk, unknowns, business pressure, and parallel work. Make the box just big enough to learn something useful.

4. Bake in review points: Set midpoints to check the signal for longer boxes. Ask: Are we learning fast enough? Does the outcome still make sense? Do you think we should stop early?

5. Normalise early exits: This is critical. If a team solves the problem on day three, let them move on. Don’t guilt them into “filling the sprint.” That kills initiative and turns curiosity into compliance.

6. Treat “not worth continuing” as a good result: If a timebox ends and the answer is “We shouldn’t keep going,” that’s a win. You’ve avoided waste. You’ve created space for better work. That’s success, not failure.

Leave a comment

Build Teams That Know When to Walk Away

If your team only gets praise for pushing through, you reward the wrong thing.

Real progress comes from knowing when to stop. When to change tack. When to say, “This isn’t working—and that’s fine.” That’s not quitting. That’s strategic decision-making.

Timeboxes, when used as quitting criteria, give you control. They allow your team to think, adjust, and move on without shame. You’ll waste less. You’ll learn more. And you’ll stop bleeding time on things that would never pay off.

So here’s the challenge: look at what’s on your roadmap. What are you working on that doesn’t have a clear exit condition? What are you quietly dragging forward because no one wants to be the one who says “enough”?

Fix it.

Set quitting criteria, make them public, and get your team used to the idea that sometimes, the most brilliant move isn’t to push through, it’s to walk away.

Deep Dive by NotebookLM.

• Most retrospectives fail because they feel safe but avoid the real discomfort needed for actual, ongoing improvement.

• Real Kaizen isn’t a process or a workshop but a mindset of constant, often awkward, small changes embedded into everyday work.

• Producers must stop acting as note-takers and instead create a culture where the team owns and acts on improvement without waiting for permission.

Let’s be honest. Most retrospectives are about as effective as shouting into a void with post-its.

Sure, they start well. The team gathers round. Someone asks how the sprint went. Someone else cracks a joke about a bug. Everyone has a moment of shared eye-rolling. Then come the stickies. “We need more focus.” “Fewer meetings.” “Better comms with art.” All fair. All familiar. Then you vote, pick a couple, act on them, and move on.

Subscribe now

Two weeks later? Same issues. Same vibes. A bit more fatigue. Maybe this time, someone’s brave enough to say what you’re all thinking: “Why do we even bother with this?”

And that’s the thing. Most retros aren’t retrospectives in the Kaizen sense. They’re soft rituals. Comfort theatre. They give the illusion of progress without making anyone truly uncomfortable. Which, of course, is the entire point of proper improvement. If no one’s squirming just a little, you’re not digging deep enough.

In mobile game teams, especially, where the pressure to release, optimise, monetise and retain is relentless, it’s easy to treat improvement as a nice-to-have. Fixes get postponed. Experiments get vetoed. Delivery becomes gospel. So, retros devolve into a checkbox exercise. “Did we do it?” Yes. “Did anything change?” Erm.

The deeper problem isn’t the team. It’s the unspoken agreement that retros are the only space where improvement lives. Everything else? Heads down. Ship the sprint. Survive the roadmap.

That’s not Kaizen. That’s cargo cult process wrapped in a thin Agile blanket.

Real improvement isn’t just a meeting. It’s the awkward conversation in the hallway. It’s a designer admitting they’re not proud of the UX because they were rushed. It’s someone quietly tweaking a template to save their future self from madness, and telling others about it.

Kaizen isn’t something you do. It’s how you think. And most teams, if they’re honest, haven’t made that leap.

Time to fix that.

Kaizen, Properly Understood

Let’s clear something up before this turns into another “how to run a better retro” piece. Kaizen isn’t a workshop. It’s not a cultural value buried on a Notion page. It’s not a word to drop in meetings to sound like you’ve read The Toyota Way.

It means “change for good”. But the kind of change it demands isn’t the comfy kind. It’s the uncomfortable, daily tension between what you’re doing and what you could be doing better. The Kaizen mindset says you never arrive. There’s no finish line. No moment where you say, “We nailed it.” Just daily progress. Or not.

It’s about spotting waste, friction and nonsense in your day-to-day and doing something about it, even if it’s small, especially if it’s small. Not once a quarter. Not after a meltdown. Every single week.

It doesn’t care how many retros you’ve run or whether you use Jira, Trello or a wall of scribbles. If your team shrugs off rework, accepts “the way things are”, or keeps dragging the same pain points from sprint to sprint, you’re not improving. You’re surviving.

And look, this isn’t a judgment. Most teams fall into this trap because they think improvement has to be Big and Strategic. But Kaizen isn’t dramatic. It’s not about running a workshop with coloured cards and snacks. It’s about choosing not to live with something that’s crap, just because it’s familiar.

If the backlog’s a mess, fix it. If people are getting blocked the same way every sprint, sort it. If handovers continue to cause confusion, change how you do them. And if you’ve raised the same issue three times and nothing’s changed, stop waiting for permission.

Kaizen isn’t for the agreeable. It’s for the persistent. And producers, more than anyone, are in the best position to set that tone.

This is where it starts.

Why Most Teams Fake It

Most teams are faking continuous improvement without even realising it.

They tick the boxes. They show up for the retro. They say the words. But if you zoom out and look at what’s changed over the past three months, it’s a rounding error, a few tweaks to a Notion document. Maybe someone added another column to the board. There’s noise, but not much signal.

The clever ones put on a convincing show. They have rituals, use all the right terms, and their updates sound like progress. But it’s mostly just Agile cosplay; the same old thinking wrapped in trendy tools.

The truth is, improvement has become performance art.

Why? Because meaningful change is inconvenient. It gets in the way of delivering. It forces hard conversations. It exposes gaps in skill, structure or decision-making that no one wants to look at. It’s much easier to patch things up with a polite nod and a Trello card than it is to rework how you collaborate with QA or challenge a dependency that shouldn’t exist.

And let’s not ignore the biggest blocker of all. Fear. Teams stay quiet because they’re afraid of being labelled difficult. Fearful of being told “that’s not your job.” Afraid that pointing out a broken process might somehow reflect poorly on them. So they filter. They soften. They water it down until it’s harmless.

Which is precisely how change dies.

You can run a retro every sprint and still be standing in the same mess twelve months later, wondering why velocity hasn’t improved and why your team feels quietly checked out.

This isn’t a team problem. It’s a system problem. And as the producer, that system is part of your remit, whether anyone says it out loud or not.

So here’s the uncomfortable bit. If your team is faking it, it’s probably because they think improvement isn’t expected. Or worse, they think it doesn’t matter. You’ve got to be the one who proves otherwise.

Not with slogans. Not with process. With action. With persistence. And with a visible refusal to let good enough stay good enough.

That’s when people start to follow.

You’re the Producer, Not the Note-Taker

If you’re running the retro and then handing out action items like free samples at a supermarket, congratulations. You’ve become the team’s admin assistant.

And look, it’s easy to fall into that role. Producers are natural organisers. We fill gaps, smooth edges, and keep the chaos at bay. When things wobble, we jump in. When someone says, “We should fix this,” we nod and put it on the backlog. But that habit, helpful as it seems, often shields the team from taking ownership of their mess.

You’re not here to fix everything. You’re here to build the conditions where the team starts fixing things themselves.

That means stepping back more than you’d like. Holding the silence when no one speaks up. Letting an awkward truth land without immediately softening it. It also means saying no when someone tries to punt an obvious issue into the future just because it’s “not the right time”.

You don’t have to be the change agent. You have to be the one who makes sure change can’t be avoided.

Start by embedding Kaizen into your everyday work, not just retrospectives. If something’s broken, don’t wait for the following sprint review to bring it up. Talk about it now. If a bug slipped because a handover was rushed, ask what needs to change in that moment, not three weeks later. Make those micro-adjustments part of how you all work, not some separate process improvement lane.

Be annoyingly consistent. Not loud. Not aggressive. Just always, quietly, pushing. Keep asking, “Is this better than last time?” And when it’s not, ask why that’s OK.

And don’t expect applause for any of this. You’ll probably get eye-rolls, especially at first. People don’t always like being nudged out of their groove. But if you’re the one who never lets improvement drop off the radar, it starts to stick.

The best producers aren’t the ones who run the best retros. They’re the ones who make retros unnecessary because the team has built a habit of fixing what’s broken the moment they spot it.

Your role isn’t to facilitate improvement. It’s to normalise it.

Practical Ways to Build Kaizen into a Game Team

Let’s get something clear right away. You don’t need a Notion workspace complete with templates or a quarterly “Kaizen initiative” with matching hoodies. You need to start acting like improvement is part of the job, not some extracurricular activity for when there’s nothing else going on.

Kaizen works best when it’s small, frequent, and embedded. Which means you need to stop saving it up for retros and start sprinkling it into your week.

Start with your standups. If someone mentions a blocker that sounds familiar, ask what has been done to prevent it from happening again. If the answer is “nothing” or “we just worked around it,” you’ve got a golden Kaizen moment. That’s a problem begging for prevention, not just another patch.

Try a “stop the line” culture. Not in the dramatic, everyone-hands-off-keyboards way. More like giving your team permission to say, “Hang on, this thing we’re doing feels daft. Can we pause and fix it properly?” Most teams wait until something is broken before speaking up. Encourage earlier nudges.

Make improvement visible. Create a small corner on your team board that says, “We made this change.” It could be a better handover process, a cleaner naming convention, or just killing off a pointless weekly sync. Doesn’t matter. If it made the team’s life easier or the game better, it goes up. Don’t wait for retros to celebrate progress. Show it, live.

And for the love of all that is playable, don’t bury Kaizen under “process work.” If you’re tagging every fix with three Jira labels and logging it in a Google Sheet no one reads, you’ve missed the point. Keep it light. If it takes more effort to record the improvement than to make it, you’ve built a blocker.

One last thing. Improvement doesn’t have to mean being clever. It can mean being lazy in the smartest possible way. If someone builds a tiny script that saves the design team two hours a week, that’s a win. If you agree as a squad to delete any ticket older than a month unless someone defends it passionately, that’s also a win. Kaizen is about shaving off friction until the day runs smoother without anyone having to push so hard.

You don’t need permission to start doing this. Just a bit of nerve and a willingness to say, “We can probably make this less annoying.”

And once your team gets a taste for that? You’re laughing.

Common Traps and How to Handle Them

Let’s not pretend good intentions are enough. Even with the best will in the world, Kaizen efforts often fall flat for predictable, repeatable reasons: the same problems, just in different studios.

The classic one is “that’s not my job.” Someone flags an issue. Everyone nods. Then nothing happens, because no one’s technically responsible. The UX flow is messy, but it’s not our responsibility. The build process is slow, but it’s not your pipeline. And so the problem lives on, quietly annoying everyone.

Fix this by making ownership explicit. Not a formal RACI-matrix level of explicitness. Just have someone raise their hand and say, “I’ll chase it.” If no one volunteers, you’ve just learnt something more valuable than what the problem is. You’ve learnt how much your team cares about fixing it.

Then there’s the hero producer trap. This one’s a slow burn. You spot all the issues, take them on yourself, and go into firefighting mode. Suddenly, you’re the process guru, Jira wrangler, team therapist and operations lead rolled into one. It feels useful, but it’s not sustainable, and worse, it teaches the team to wait for you to fix things. That’s not Kaizen. That’s a bottleneck.

Your job is not to carry the weight of improvement. Your job is to help the team build the muscle to have it themselves. That means biting your tongue sometimes and letting them stumble, rather than handing it over with a bow on top.

Then there’s the big one. The deadline excuse. “We don’t have time to fix this right now.” Sound familiar? Everyone agrees the problem exists, but the release is looming, and it gets bumped to “next sprint.” Again. And again. Until it either becomes permanent, or someone new joins and asks, “Why is this still like this?”

You can’t fix everything right away. But you can start by tracking how often improvement work gets bumped. Count it. If something has been postponed more than twice, have that uncomfortable chat. Ask if the cost of delay is worth it, and what message it sends.

And finally, let’s talk about managers who smile politely when you mention process change and then carry on exactly as before. That’s tricky. You can’t force buy-in, but you can surface consequences. If leadership keeps breaking sprint boundaries, show how that affects throughput. If priorities change daily, share the context-switching costs in terms of time, bugs, and morale. Keep it data-led, not emotional. Frame it as helping them get more of what they already want.

Not every trap can be avoided. But most can be spotted early and handled with a bit of backbone and a steady hand.

Don’t wait for permission. Just stop stepping over the same broken floorboard.

Kaizen Is Culture, Not a Template

You can run retrospectives like clockwork, track every action item, and still get stuck in the same old loop if your culture doesn’t support them. That’s the bit people don’t want to admit. The reason Kaizen efforts stall isn’t usually because the team doesn’t care or the tools are wrong. It’s because improvement isn’t part of how the place works.

Look at what gets praised. Look at what gets ignored. That’s your culture.

If someone quietly cleans up a horrible process and no one notices, they’ll stop bothering. If you throw a launch party for shipping on time but skip over the lessons learnt from the three-week crunch that got you there, the message is loud and clear. Delivery matters. Learning doesn’t.

Culture isn’t what you write in a slide deck. It’s what people pick up from the way things are done. If Kaizen is treated like an extracurricular activity, it’ll always fall behind the deadline. If people see that raising process issues gets you labelled as “negative” or “difficult,” they’ll stay quiet. If improvement only happens when you say it should, you’re managing permission, not culture.

So, how do you change it?

Start small. Celebrate change as it happens. Not just the big wins, but the quiet nudges. Someone removed a pointless sign-off? Mention it in standup. A team came up with their way to run reviews that cuts the faff? Steal it and share it. Let people see that change is a normal part of life. That it is expected. That it sticks.

Then stop being the only one who talks about it. Ask people what they’ve improved lately. Make it a casual, recurring question. Not to catch anyone out. To make the point that this is the kind of team where progress is part of the day job.

Drop the dramatic gestures. No one needs a two-hour improvement workshop with icebreakers and group hugs. They need to feel like fixing things is part of what it means to be in this team. That change doesn’t need a retro. It just needs someone to say, “Let’s do it better.”

That’s culture. And it starts with you showing what you’ll tolerate, what you’ll highlight, and what you’re quietly letting go.

Choose wisely.

Leave a comment

It’s Supposed to Be Hard (That’s the Whole Point)

Improvement is not meant to be easy. If it feels effortless, you’re probably doing the safe bits. The cosmetic stuff. The parts that don’t ruffle any feathers or push anyone’s comfort zone.

Real Kaizen stings a little.

To improve, you have to admit that what you’ve got today isn’t good enough. That process you designed needs to change. That a system you rely on is slowing you down. That your way of working might be part of the problem. No one loves that feeling.

But that’s the work.

You don’t build a better team by avoiding discomfort. You make it by learning to sit with it and do something useful anyway. And if you’re the producer, you’re the one who has to go first. You’re the one who keeps asking the awkward questions, keeps pointing out the cracks, and keeps making space for change even when it would be easier to ship the sprint and move on.

There’s no tidy finish line. No perfect system. Kaizen isn’t about arriving. It’s about choosing, every week, to nudge things forward. Sometimes it will be a leap. Most weeks it’ll be a shuffle. Doesn’t matter. What matters is that you never stop looking for the next thing worth fixing.

This isn’t a nice-to-have. In games, especially mobile, you are always behind something. Deadlines. Competitors. Market shifts. Player demands. If your team isn’t actively getting better, they’re slowly falling behind, even if everything feels fine.

So make Kaizen part of your identity, not your process. Don’t chase the fancy frameworks. Don’t wait for the perfect time. Just start doing the next small thing. And the one after that.

It’ll be messy. It’ll be awkward. And it’ll be worth it.

Because if your team learns to improve as part of how they work, not just when they’re told to, you’ve already won. Everything else becomes easier from there.

Deep Dive by NotebookLM.

• Game design documents have evolved from massive static files into flexible, digital tools that adapt to real-time development needs.

• Traditional GDDs are often too rigid, outdated, and ignored, but modular and agile-friendly formats solve these problems.

• In LiveOps, fast-paced updates demand lean documentation focused on purpose, KPIs, and clear ownership to maintain speed and quality.

Game design documents have come a long way since the industry's early days. Back then, they were hefty, physical documents, sometimes hundreds of pages thick, filled with handwritten notes, sketches, and annotations. These documents served as the single source of truth for the entire team, covering everything from gameplay mechanics and storylines to technical requirements and art direction.

Subscribe now

As games became more complex and teams grew in size, the role of the GDD shifted. By the late 1990s and early 2000s, they had become essential project documentation, often formalised as part of contracts with publishers. If a publisher signed a studio to build a game, the GDD was usually part of that agreement. The expectation was clear: stick to what is in the document, renegotiate a change or risk not getting paid.

But game development is not static. Scope shifts, features get cut or added, and entire mechanics are reworked mid-production. To keep up, the GDD evolved into what many teams now treat as a living document, which can change weekly or even daily as the game takes shape.

Fast forward to today, and most GDDS are digital, modular, and constantly updated. They live in tools like Confluence, Notion, or Google Docs. They are no longer static PDFs filed away after pre-production. Instead, they are built to stay relevant throughout the entire development cycle, especially for cross-functional teams working across design, programming, art, QA, and marketing.

Some historical GDDs have even made their way online, giving us a glimpse into how teams used to work. The original GTA design document, when it was still called Race 'n' Chase, the Deus Ex doc full of cut features, and the infamous Doom Bible, which included everything from level plans to takeaway menus, all highlight how documentation was both practical and personal.

Common Criticisms of Traditional GDDs

Despite their long history and usefulness, traditional game design documents have plenty of baggage. Here are some of the most common complaints I have seen teams wrestle with:

• They go out of date almost immediately. Once production starts, features change quickly. Keeping the GDD updated becomes a job in itself, and it is one that often gets skipped.

• They are too rigid. Locking in ideas too early can kill creativity. Some GDDs force teams to stick to initial plans instead of evolving based on what feels good during testing.

• No one reads the whole thing. Large, exhaustive GDDs are often ignored. Most people just skim for what they need or avoid it entirely.

• They are built on guesses. Since GDDs are usually written before development kicks off, they are full of assumptions. And those assumptions do not always hold up when you start building and playtesting.

• They are not user-friendly. Walls of text, poor formatting, and unclear structure make many GDDs hard to use. If it is painful to find what you need, it will not get used.

• They do not capture the fun. It is nearly impossible to describe fun in writing. A GDD might list mechanics, but that does not guarantee the gameplay experience will actually be enjoyable.

• They discourage iteration. Requiring every feature to be fully defined up front can stop teams from experimenting, failing fast, and learning on the fly.

• They do not reflect how games are really made. GDDs are often static, while game development is dynamic and messy. Especially in agile teams or LiveOps environments, the document needs to move as fast as the work.

• They try to do too much. A single massive document is hard to maintain, hard to reference, and hard to assign ownership to. Breaking it into modular parts works better for most modern teams.

The GDD's Core Role in Modern Development

At its core, a game design document is about clarity. It gives the team a shared understanding of the game's purpose, how it works, and what matters most. That is essential, even for experienced developers.

Without some form of central reference, things start to drift. Design might shift in one direction while engineering solves different problems. Art might get ahead on visuals that no longer fit the plan. And nobody notices until time has already been wasted.

A GDD helps prevent that by anchoring conversations. It allows you to document decisions, highlight constraints, and share the why behind each feature. It also makes onboarding new team members or bringing external partners up to speed easier.

It is not just about development, either. A well-structured GDD can help manage scope, track features through production, and support milestone planning.

And when stakeholders like publishers, licensors, or investors need updates, your GDD helps show the thinking behind what is being built. It becomes a tool for visibility and trust.

GDDs in Agile and Modular Workflows

Traditional GDDs tried to cover everything in one giant document. That approach does not work in agile environments, where priorities shift quickly and iteration never stops.

Modern teams break documentation into smaller, focused pieces. You might have one doc on player progression, another for combat systems, and a third for the core loop. Each piece stands independently and can evolve without dragging the rest of the project with it.

User story mapping is a great way to organise this. By laying out the player journey and grouping features around it, you get a clear visual of what matters most. It helps teams prioritise, spot gaps, and see how new features fit into the game's overall flow.

Gherkin adds another layer of clarity. Writing features in the “Given / When / Then” format clarifies expectations, especially across design, dev, and QA. It also ties directly into behaviour-driven development if you are working that way.

Impact mapping is another tool that helps keep modular documentation focused on outcomes. It starts with the goal and then maps out the actors (like player types), their behaviours, and the changes needed to achieve that goal. For GDDs, this helps teams avoid overbuilding by showing which features actually support the intended outcome. It also makes challenging scope creep easier and ties every mechanic back to a real player or business impact.

This modular and story-driven approach speeds up updates and keeps documentation usable. No one wants to dig through a giant doc to find a single variable or rule.

Most importantly, this setup reflects how agile teams work. You do not commit to every detail up front. You build, test, and adjust based on what feels right and what the data tells you.

The key is to capture the pillars. What must be true for the game to work? What constraints are in place? What systems rely on others? You can just nail those down first, then build the rest as needed. Let the documentation grow with the project, not ahead of it.

Some supporting material to consider.

Why LiveOps Needs a Different Approach

When running LiveOps on an established game, the documentation approach shifts again. You are no longer planning entire systems from scratch. You are updating, tweaking, and layering new content on top of what already exists.

A full GDD for every feature does not make sense in this environment. The pace is too fast, and the scope of each update is usually narrower.

Sometimes, prototyping a feature is quicker than writing it down. Building a rough version and seeing how it plays can be more useful than speculating in a document if you are testing a new event type or tweaking game balance.

That said, even when you prototype first, you still need documentation. Once you have landed on something that works, writing a quick feature brief helps everyone stay aligned. It captures what was decided, what to watch out for, and how the update fits into the bigger picture.

LiveOps work still needs coordination. Designers, developers, QA, and marketing must understand what is changing and why. And if something breaks or underperforms, having documentation makes it much easier to troubleshoot or adjust in future iterations.

LiveOps Docs: What to Include

LiveOps documentation should be lean but purposeful. It does not need lengthy write-ups, but it does need to cover the essentials.

Start with the feature goal. Could you tell me what you're trying to achieve? Is this a content drop to drive logins? A limited-time event to boost revenue? Or a quality-of-life tweak based on player feedback? Knowing the purpose helps everyone make smarter decisions.

Next, define success. Include the KPIs you are tracking, whether engagement, spend, retention, or something else. This keeps the team focused and helps you evaluate the update after launch.

Approvals still matter. Even if you are moving quickly, a clear owner or lead should be signed off on to ensure features align with the broader game direction.

From there, nail down the technical details. Server-side values, item IDs, durations, and dependencies must be adequately documented to be implemented, tested, and supported.

Finally, track what has gone live and what is coming next. A simple release log can save loads of time when juggling multiple updates or troubleshooting live issues.

GDD in Development vs LiveOps: A Shift in Focus

In early development, the GDD is often detailed and comprehensive. It sets direction, defines systems, and aligns the team on the overall vision. Updates to the document are less frequent and tied to big milestones.

LiveOps, on the other hand, runs on speed and iteration. The documentation needs to be lean and modular, focused on the update, the goal, and the technical setup. Instead of one large document, you will have a collection of smaller ones such as feature briefs, event specs, tuning docs, and configuration sheets.

Approval processes differ, too. In development, changes may need multiple sign-offs. LiveOps is often a faster cycle, but oversight still matters to avoid breaking something in the live environment.

Where development GDDs are about building the foundation, LiveOps documents are about keeping that foundation strong while layering in new content without disruption.

Who Owns What in the GDD

For a GDD to stay useful, it needs clear ownership. Otherwise, parts of it go stale, updates get missed, and no one’s sure what’s still valid. Ownership does not mean one person writes everything. It means someone is responsible for keeping each section accurate and current as the game evolves.

Here’s a rough breakdown of how ownership typically plays out on well-run teams:

• Design owns the mechanics briefs, feature specs, progression systems, and player-facing rules. They document how the game is meant to work and what players can do.

• Product owns the KPIs, goals, and success criteria. They define what each feature tries to achieve and how outcomes will be measured.

• Engineering owns the technical constraints, dependencies, and integration notes. They flag what’s feasible, what’s blocked, and what systems need to be considered.

• Art owns the visual requirements. That includes target styles, asset lists, mockups, and animation expectations, plus notes on reusability or tooling.

• QA helps document edge cases, test scenarios, and known limitations. They often write test cases and acceptance criteria and contribute to validation checklists based on the GDD.

Some teams assign these roles explicitly in the document itself. Others manage them through naming conventions, folders, or tags. Whatever the approach, what matters is that someone always watches each piece of the document and keeps it useful. If it’s everyone’s job, it quickly becomes no one’s.

The Game Producer’s Role in GDD Development

Producers are key in ensuring the GDD is more than just a document. Their job is to keep it relevant, practical, and used by the team, not just written once and forgotten.

A producer helps guide the document's structure to match how the team works. That often means encouraging modular, task-focused docs instead of a single, bloated file. They work closely with leads to ensure someone owns every section and that updates happen when decisions change.

Producers also act as a bridge between disciplines. They ensure the GDD captures input from design, art, engineering, and QA, reflecting real constraints like time, tools, and team capacity. If a feature spec doesn’t align with what's technically possible or resourcing, the producer is usually the first to flag it.

Producers rely on the GDD to map work into milestones, track dependencies, and align team output with business goals in planning and scoping. If the documentation is unclear or outdated, it creates risks in delivery.

Finally, producers help reinforce the culture around documentation, not by forcing everyone to write more but by assisting teams to understand when documentation saves time and reduces risk. A good producer knows that a well-maintained GDD is not just admin but infrastructure.

Leave a comment

Conclusion: Do Not Skip Docs, Adapt Them

You do not need a massive document for every new feature. But if you skip documentation altogether, you are making things more complicated for your team.

Clear, concise documentation helps keep everyone aligned, even when updates are fast and frequent. It supports better planning, smoother implementation, and quicker follow-ups.

LiveOps primarily benefits from small, focused documents such as feature briefs, config sheets, and event specs that are kept current and easily managed.

It is not about writing more. It is about writing enough in the correct format at the right time.

Deep Dive by NotebookLM.

• Building the simplest system that meets today’s needs keeps your code clean and adaptable and reduces long-term risk without over-engineering for the future.

• BSSN balances speed and quality, helping teams avoid the trap of messy prototypes becoming brittle foundations that slow down production later.

• Strong early systems and daily habits of simplicity prevent technical and emotional debt, keeping teams motivated and delivery on track.

Those who have worked with me often hear me say, “A good plan fiercely is better than the perfect plan.” It’s my shortcut version of the well-known line, “A good plan violently executed now is better than a perfect plan executed next week,” from General George S. Patton Jr., the World War II leader. In this context, “violently” is about vigour and determination, not violence. The quote is a potent reminder that action beats hesitation. It pushes individuals and studios to accept imperfection as part of the process, using momentum to unlock growth and improvement over time.

Subscribe now

But while this mindset is valuable, it can come across as all-or-nothing. It risks sounding like you either charge ahead or do nothing at all, with no middle ground. It also doesn’t give you a framework to follow; it’s a mindset, not a method. Without something more structured, it’s easy to lose balance between moving fast and making thoughtful, sustainable choices.

Best Simple System for Now

Last month, I came across a brilliant blog post by Daniel Terhorst-North called ‘Best Simple System for Now’. He challenges the typical trade-off between messy, rushed code and slow, over-engineered perfection. Instead, he argues for building the simplest system that meets today’s needs to a sensible standard — no guessing at future requirements. This approach, known as BSSN, focuses on writing clean, maintainable code that solves the problem in front of you. It’s easier to change later, balances speed with quality, and reduces risk over time.

BSSN offers a practical middle ground in software development. It avoids the extremes of hasty shortcuts and heavy, speculative design. The goal is to build just enough: a lean, fit-for-purpose system that does the job now without layering on complexity you don’t need yet. There is no extra abstraction. No future-proofing for its own sake. Just clear, reliable code that’s only as robust as it needs to be — nothing more, nothing less.

The name Best Simple System for Now is intentional. Each word matters:

• For Now: Build for what you know today. Avoid guessing at future needs. Developers often try to plan, but this usually leads to over-engineering. BSSN keeps your focus on the real, immediate problems.

• Simple: Skip future-facing designs you don’t need yet. Overbuilding leads to rework and compromises. As Antoine de Saint-Exupéry put it, simplicity means removing what is unnecessary. A simple system stays light and adapts more easily later.

• Best: Simplicity is not an excuse for cutting corners. Get the quality right for the context. Core features need rigour; prototypes need speed. Sketching code is a valuable skill; write just enough to move forward, with the option to refine later.

Terhorst-North also tackles some common objections to BSSN:

• “It’s overkill for a prototype.”- Some believe prototypes should be throwaway hacks. However, successful prototypes often grow into production systems. They’ll be painful to extend and maintain if messy from the start.

• “It’s incomplete.”- There’s a concern that BSSN leaves products unfinished. Delivering part of the customer’s need early is often more valuable than waiting for perfection. Most value comes from core functionality. Look at the early versions of the iPhone or Google Docs. They offered a focused, helpful subset from day one. This follows the “worse is better” idea: ship sooner and improve over time.

• “It’s inefficient.”- Some worry that constant rework wastes effort. But timing matters. Big-bang projects carry high risk because you only see returns at the end if they land. BSSN spreads the risk by allowing earlier revenue and faster feedback. The Cost of Delay, which is the money lost from slow delivery, and Opportunity Cost, which is the value of what else you could have built, both point to the same thing: long, drawn-out projects are the fundamental inefficiency.

The approach stands on a few core principles that keep it grounded and practical:

• Discipline: Simplicity takes ongoing, deliberate effort. It’s not a set-and-forget mindset. Like keeping a kitchen clean, it’s about regular maintenance. Leave things unattended, and clutter builds up fast. But when the codebase stays tidy, it naturally encourages more good habits. Clean code is easier to work with, which lowers friction and keeps the team moving at a healthy pace. It creates a positive loop: the simpler things are, the simpler they stay.

• Habits: BSSN isn’t a one-off decision; it’s a daily practice. It means staying mindful of the temptation to generalise too early, abstract too soon, or over-invest in problems that haven’t fully formed. Good habits help you spot when you’re overworking an idea or, just as risky, under-investing in something that deserves proper attention. It’s about staying present, reading the situation, and making grounded decisions rather than following arbitrary rules or assumptions.

• Courage: New approaches always feel uncomfortable at first. BSSN is no different. Terhorst-North suggests a simple principle: “Trust me once.” Give the approach a proper try, knowing you’re not locking yourself in. You’re simply testing a different way of working, with the freedom to adjust if it’s not the right fit. Courage here isn’t about reckless leaps; it’s about permitting yourself to try without fear of commitment.

• Humility: Staying humble keeps you adaptable. You’ll never have perfect foresight, and that’s fine. The Bruce Lee mindset of “be like water” fits perfectly. By keeping things simple, you stay flexible and ready to respond to whatever changes come your way. It’s about trusting the future to handle future problems with more knowledge than you have today. Humility helps you let go of premature assumptions and focus on building what’s needed.

These aren’t just nice-to-haves. They are what make BSSN work day to day. They help you balance speed and quality, stop complexity from creeping in, and build an adaptable system as you learn and grow. Without them, it’s too easy to slip back into old habits or fall into the traps of overbuilding or cutting corners.

BSSN Applied to Game Production

I’ve seen it repeatedly across game teams: prototypes that were meant to be throwaway experiments somehow end up living on as the foundation of the live game. It usually starts innocently enough. A team hacks something together for a pitch, a demo, or an internal playtest. It works well enough to show promise, so momentum carries it forward. No one plans for this prototype to become production code, but before you know it, you’re building entire features and systems on top of shaky foundations.

The trouble is that early code was never designed to go the distance. It wasn’t built for scale, it wasn’t built for change, and it certainly wasn’t built for live ops demands. Fast-forward a few months, and you’ve got a team struggling to add what should be simple features, say, a tweak to an event system, a slight extension to progression, or a new monetisation mechanic. From the outside, it looks like a quick win. But under the surface, you’re fighting brittle, tangled code never meant to handle real-world complexity.

What makes this worse is that the people who wrote the original prototype have often moved on by the time the game is scaling. New teams inherit the tech debt without the full context of how or why things were built the way they were. They’re left untangling spaghetti code, reverse-engineering decisions, and working around fragile dependencies. This slows everything down. What should take days stretches into weeks. Stakeholders get frustrated. Teams burn out. And worst of all, it becomes harder and harder to justify the time needed to clean things up properly because you’re stuck in a cycle of urgent feature requests.

I’ve watched teams hit this wall more times than I care to count. It’s one of the most common root causes behind production teams struggling to deliver what seems like “small” asks. The effort to ship a new live event or tweak progression ends up wildly disproportionate to the perceived value, all because the foundations were never strengthened after the prototype phase.

This isn’t just technical debt; it becomes emotional debt, too. Frustration builds when teams feel trapped by poor foundations. As leaders, recognising this early makes all the difference.

This is precisely where BSSN shines. It allows you to build simple, clean prototypes to grow into production without carrying unnecessary baggage. You’re not over-engineering from day one, but writing code and building systems carefully to avoid future traps. You’re keeping the door open for iteration without mortgaging your future velocity.

For game teams, this isn’t theory. It’s survival. Build your early systems, assuming they might live longer than you expect. Give them just enough structure so that if and when they move into production, you’re not stuck fighting your own past decisions. It’s a balance and takes practice, but once you’ve felt the pain of battling a messy prototype in live ops, you never want to repeat that mistake.

And it’s not just a technical problem. It’s a morale issue that eats away at teams over time. When smart, capable people keep hitting invisible walls because systems fight them at every turn, it slowly drains their energy and belief. You start to hear familiar frustrations like “This should have been simple” or “We’re spending more time fixing things than building new ones.” Left unchecked, this wears teams down. They start losing faith in the plan, the tools, and their ability to deliver.

As leaders, this is one of the clearest signals to watch for. When delivery slows and frustration rises, it is often not the roadmap that is wrong. It is the foundation beneath it. Spotting this early is key. It comes down to asking the right questions, such as: Is our early work carrying more weight than it was ever meant to? Are we building clean enough today to stay fast tomorrow? Even better, it is about creating a culture where teams can raise these risks before they snowball.

BSSN naturally supports this kind of culture. It keeps the work focused on today’s needs while ensuring it is done with enough care that tomorrow’s team does not feel trapped. It also gives you a shared language as a team. When everyone understands the value of building just enough with clarity, you are not stuck trying to justify the time it takes to do things properly. Teams stay confident, momentum stays healthy, and your energy stays focused on delivering value rather than clawing back lost ground.

Leave a comment

Closing Thoughts

When I think about “a good plan fiercely” in leadership, it’s less about shouting for speed and more about building trust in steady progress. It’s about helping your team act with conviction today without trapping them in decisions they’ll regret tomorrow. BSSN enables you to do exactly that. It keeps things honest, manageable, and flexible. Our role as leaders is to shape an environment where progress feels achievable, foundations are strong enough for now, and the team has the confidence to handle whatever comes next.

Check out this recent interview with modl.ai where we talk about how QA isn't just a safety net, but a creative catalyst.

Subscribe now

We covered:

• Why QA should be part of your game design from day one

• How automation slashes release cycles from weeks to days

• The hidden cost of outsourcing QA—and how to do it right

• Why crunch is a leadership failure (and what to do instead)

• What probabilistic thinking can teach us about release dates

My message is clear: Quality is everyone’s responsibility—and when QA is empowered, the entire studio wins.

If you're scaling a live service game, rethinking your pipelines, or just tired of hotfixing your way to launch, this one’s for you.

You can also read the blog post here.

Deep Dive by NotebookLM.

• Mixing agile frameworks without a straightforward organisational design creates short-term wins but leads to long-term fragmentation and costly misalignment.

• Org Topologies offers a visual map to understand your studio’s structure, helping you choose agile practices that support your goals.

• By mapping skills and work mandates, leaders gain clarity to guide teams effectively, avoiding the chaos of DIY frameworks and building towards deliberate, scalable success.

There’s a dangerous trend sneaking into LiveOps studios. Teams and leaders, fed up with off-the-shelf frameworks, are stitching together their own ad hoc Agile setups. Scrum here, Kanban there, sprinkle in some SAFe terminology, add a dash of Spotify, and it's done. Sounds great, doesn’t it? Flexible, tailored, and empowered.

Until it isn’t.

What starts as freedom quickly turns into a mess of local optimisations. Teams run well on their own, but the organisation as a whole begins to creak. Dependencies pile up. Priorities clash, and then flow stalls. And before you know it, you’re holding a patchwork of methods that were never designed to work together, at least not in your specific context.

Subscribe now

The problem isn’t the frameworks themselves. It’s the lack of a map. When you cherry-pick practices without understanding your studio’s shape, structure, and goals, you play agile roulette. Some bets land, but most don’t.

I’ll be honest — I’ve done this too. I’ve been part of teams that cherry-picked practices because it felt like the bright, adaptable thing to do. It seemed we were in control at the time, building something perfectly suited to our needs. But without a clear view of the whole system, we ended up precisely the kind of fragmented setup I’m warning about here. Lessons learned the hard way.

That’s where Org Topologies comes in. It’s not another framework to add to your pile. It’s the lens to see the system clearly before bolting things together. With Org Topologies, you stop guessing and start designing. Your choices become deliberate, not desperate.

Let’s break down why DIY frameworks, done blindly, are risky business — and how Org Topologies helps you build something that works.

The Era of DIY Frameworks: When Choice Becomes Chaos

It’s not hard to see why teams are tempted. The bookshelves and conference talks overflowed with frameworks, models, and playbooks. Most of them promise the same thing: flexibility, faster delivery, and happier teams. I admit that this newsletter is filled with such advice. And honestly, they work, at least in isolation.

So what do people do? They skip the standard framework and build their own.
Take a bit of Scrum for planning, Kanban for flow, and a touch of SAFe vocabulary to sound serious in leadership meetings. Maybe sprinkle in something from Team Topologies because everyone’s talking about it.

It feels smart and tailored. It's like you’re making Agile fit your business, not the other way around.

But there’s a catch.

When you mix and match without understanding how your studio actually operates as a whole, you’re not building flexibility; you’re building fragmentation. Each team runs its playbook. What works for one part of the business ends up clashing with another. Decisions made at the team level don’t align with the bigger picture. You get fast local wins but lose the cohesion that makes real progress possible.

This is the era of DIY frameworks, and while they feel good in the short term, they set up long-term pain.

The Hidden Cost of Cherry-Picking: Local Wins, Systemic Losses

Here’s the uncomfortable truth: local wins don’t guarantee global success. They often hide more prominent problems.

When teams cherry-pick their way through agile practices, they usually solve their immediate pains. Fair enough; who doesn’t want smoother sprints or faster releases? But while they’re fixing their flow, they unintentionally create bottlenecks elsewhere.

• One team races ahead, while another gets buried in dependencies.

• Priorities collide because no one’s checking alignment across the whole studio.

• Teams duplicate work without realising, wasting effort on parallel solutions to the same problem.

• Leaders lose visibility. When you zoom out, what’s flowing smoothly at the team level feels like sludge.

And the kicker? No amount of sprint velocity, burndown charts or event flow metrics can fix a system that’s misaligned at its core.

This happens when you treat frameworks like a shopping basket instead of part of a connected, deliberate design. Without a clear view of how your organisation is structured to deliver value, you’re just layering methods on top of cracks in the foundation. Sooner or later, those cracks widen.

The cost isn’t just operational; it’s cultural, too. People get frustrated, teams start pointing fingers, and leaders scramble for answers. And just like that, your DIY agile setup turns from “empowered teams” to organisational chaos.

Enter Org Topologies: The Missing Map

This is where Org Topologies changes the game.

While your teams are busy picking and mixing agile practices, Org Topologies steps back and asks a much bigger, much better question: What shape should your organisation take actually to reach its goals?

It’s not another framework to toss into the mix. It’s the map you use before you choose your route.

Org Topologies isn’t about pushing a fixed method. It’s a human-friendly way to see your studio’s strengths, gaps, dependencies, and hidden traps. You stop tinkering blindly at the team level and start designing intentionally at the system level.

Org Topologies helps you map two things that are often invisible:

• Skills Mandate (Horizontal Axis): How capable are your units? Can they deliver value end-to-end, or are they stuck passing the baton between silos?

  

• Work Mandate (Vertical Axis): How broad is their scope? Are they working on small isolated tasks or tackling whole business problems?

  

This mapping reveals exactly where you sit today — whether you’re operating in a Resource Topology (where the focus is on squeezing out every drop of utilisation), a Delivery Topology (speedy but limited to outputs), or an Adaptive Topology (designed for learning, flexibility, and actual outcomes).

But it doesn’t stop at theory.

Org Topologies helps you go further by showing the archetypes at play in your organisation. These are patterns of how teams and units behave, like:

• Directing archetypes — making plans and writing specs but not delivering value directly. i.e. Game Design, Product Management

• Doing archetypes — task specialists, reliant on external coordination. i.e. Art, Data Science

• Delivering archetypes — producing outputs in a focused area but often stuck in silos. i.e. Developers, Core Tech, Infrastructure

• Driving archetypes — the gold standard: teams or groups that understand the whole and own the delivery of customer value end-to-end.

It even gives you a shared language. No more fuzzy conversations about “alignment” or “efficiency”. Now you can describe your current and future state clearly, in terms everyone understands.

And here’s the kicker. With this clarity, stop playing with surface-level tools and start designing your organisation correctly. When you pick agile practices, you’re doing it with full awareness of how they fit into your broader structure. You’ll spot conflicts and dependencies before they create headaches.

Org Topologies doesn’t tell you which framework to use. It helps you understand your system well enough to pick and combine frameworks intelligently, which is a huge difference.

It’s about owning your change, not renting it.

Don’t Confuse Org Topologies with Team Topologies

Let’s clear this up because it catches a lot of people out.

Team Topologies and Org Topologies are not the same thing. Yes, both help you think about structure. But they work at very different levels.

Team Topologies is about teams. Specifically, how you design them for better flow, lower cognitive load, and smoother interactions. It gives you smart categories like:

• Stream-aligned teams

• Enabling teams

• Platform teams

• Complicated subsystem teams

It also shows you how these teams should interact to stay effective.

But here’s the thing — Team Topologies stays focused at the team level. It’s like choosing the right type of brick for your house.

Org Topologies, on the other hand, is about the whole construction plan.
It’s the complete map of your organisation. It shows you:

• Where your teams (and everything else) sit in the bigger system

• How well-equipped they are (skills mandate)

• How much of the business they own (work mandate)

• And how all of it connects to your strategy

Org Topologies is so broad and flexible that you can use it to map your Team Topologies decisions. You can see if you’re building strong foundations or accidentally creating gaps between your teams and your broader organisational goals.

In short:

• Team Topologies give you better team building blocks.

• Org Topologies shows you how to design the whole structure so your blocks fit together and support the house you’re trying to build.

Org Topologies in Practice: Avoiding the DIY Trap

So, how do you use Org Topologies to avoid the DIY mess?

Good news. This isn’t about torching everything and starting from scratch. It’s about finally seeing your organisation for what it is and making smart, connected moves to get where you want to go.

The method is simple on paper but powerful in practice. It’s called MADE:

• Map

• Assess

• Design

• Elevate

Map

You can start by laying out your current organisation on the Org Topologies map.
This isn’t just a theoretical exercise. It’s hands-on and visual, a proper way to see how your divisions, groups, teams, and even individuals are structured.

Here’s how it works.

The Org Topologies map is a simple but powerful grid. Think of it as a 4x4 matrix with 16 clear archetypes.

• The horizontal axis shows the scope of skills inside a unit — from narrow specialists to full end-to-end capabilities.

• The vertical axis shows how much of the work they own — from narrow tasks to whole-business responsibility.

You can bring this to life with tools like Miro. There’s a ready-made template you can use to map out your setup. Place your teams, individuals, and departments onto the grid based on their skills and the slice of the business they handle.

What you’ll get is instant clarity:

• Are your teams task-focused or stuck in dependency chains?

• Are you operating with scattered skill sets, forcing endless handovers?

• Where are the strong dependencies? Where’s the flow being killed?

This mapping exercise gives you an accurate picture, not the one you wish you had.
Best of all, it quickly gets your whole team on the same page. There are no fuzzy conversations, no blind spots, just shared understanding.

Assess

Now, ask the hard questions:

• Does your current design support your business goals?

• Are you chasing speed while stuck in a Resource Topology?

• Are you pushing for innovation but trapped in a narrow Delivery setup?

The map makes these misalignments obvious. You’ll immediately notice if your teams are too specialised, too dependent, or lack the mandate to truly own outcomes.

And here’s the critical bit. You’ll see if your organisational shape fits the purpose.
Not just for today but for where you want to go.

Design

This is where you get deliberate.

Use Org Topologies to design a future state that supports your goals. Maybe you need to shift toward an Adaptive Topology to handle constant market changes. Maybe you double down on Delivery Topology for fast, predictable flow.

This isn’t guesswork. You’re using proven patterns and archetypes that match your ambitions. And because the map is clear, your whole leadership team can get adequately aligned on what "good" looks like.

You don’t have to apply one topology across the whole business. Depending on their goals, different parts of your organisation can operate in different topologies. Stable areas might stay in Delivery while your innovation hubs push towards Adaptive.

Elevate

Finally, you move from where you are to where you need to be.

Org Topologies gives you a safe, step-by-step way to do this. You’ll use Elevating Katas, small, repeatable experiments designed to nudge your organisation toward your target state.

No big-bang reorganisations. No culture shocks. Just precise, incremental shifts backed by a solid understanding of your system.

This means:

• Less risk of failed change.

• More buy-in from your teams (because they’re part of the design, not victims of it).

• And crucially, you keep your operational momentum while making meaningful progress.

You can even re-map as you go, checking progress and adjusting your course.
Change isn’t a one-off — it’s a living process, and Org Topologies helps you keep the learning loop alive.

And the real beauty? You don’t have to give up the agile practices you love. Scrum, Kanban, SAFe, and Team Topologies still have their place.

But with Org Topologies, you’ll know exactly where they fit and, more importantly, where they don’t. No more guessing. No more agile-by-hope. Just clear, confident design choices that serve your business.

Real Talk: Why Teams Love DIY (and Why Leaders Should Worry)

Let’s be honest. Teams love the DIY approach. And it’s not hard to see why.

When you let teams cherry-pick their agile practices, they feel in control. They get to shape their ways of working, solve immediate problems, and see quick wins. It feels empowering because, at their level, it is empowering.

Leaders tend to back it, too. It looks like ownership. It sounds like agility. From a distance, it feels like progress.

But here’s the danger: while teams fine-tune their local world, no one is steering the whole ship. The more significant questions go unanswered:

• Are we moving towards our strategic goals?

• Are these local optimisations helping the broader studio or just the team?

• Are we quietly locking ourselves into silos that will be painful to break later?

The uncomfortable bit? Teams can’t answer these questions on their own. And they shouldn’t have to. This is leadership work.

DIY feels good because it offers fast feedback and visible progress. But if leaders don’t step in with a system-wide perspective, they’ll be cheering from the sidelines while the organisation drifts off course.

Org Topologies fills that gap. It gives leaders the clarity to guide local decisions without crushing team autonomy. It’s not about central control; it’s about system alignment. You still let teams shape their workflows but do it within a design that works at scale.

So yes, let teams enjoy their DIY experiments. But make sure they’re building towards something tangible. Without that, you’re just giving them tools to dig deeper holes.

Leave a comment

Stop Playing Agile Roulette

Here’s the bottom line. If you cherry-pick agile practices without a straightforward, studio-wide design, you're gambling with your future.

Sure, you might get lucky here and there. A team speeds up. A delivery gets smoother. Leadership breathes a small sigh of relief. But without alignment, it’s all just agile roulette, spinning the wheel and hoping things land in your favour.

That’s no way to run a business.

Org Topologies doesn’t stop you from picking the practices you like. It just makes sure you understand the game you’re playing. It gives you the entire map before you set off choosing routes. It helps you see:

• Where your studio stands today

• Where do you need to go

• And how to get there without leaving a trail of silos and frustration behind

Frameworks like Scrum, Kanban, SAFe, and Team Topologies still matter. But they need context. You're just throwing methods at symptoms without the bigger picture of how your organisation is wired to deliver value.

Org Topologies gives you that context. It’s your way of moving from desperate fixes to deliberate design, from hoping for alignment to creating it.

So stop spinning the wheel. Step back, get the full view, and build an organisation that’s fit for purpose — not just fashionable.

Attribution and Credits:

• Alexey Krivitsky and Roland Flemm created Org Topologies with contributions from Craig Larman (co-author of the primer and forthcoming book)

• Published by: Org Topologies™

• The Primer available under: Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)

• Further information: Available on the Org Topologies website

Deep Dive by NotebookLM

• Kanban works because it aligns with how people naturally think, focus, and stay motivated, making it more than a workflow tool.

• Its strength lies in reducing mental friction and creating clarity, helping teams work with less stress and more purpose.

• By supporting a healthier team mindset, Kanban builds environments where productivity, satisfaction, and collaboration thrive.

Why does levelling up your RPG character feel so rewarding? What's behind the irresistible urge to have "just one more run" in a roguelike? And why is ticking off achievements in your favourite game so satisfying?

Subscribe now

After over thirty years of making games, I've become fascinated by the psychology and behavioural economics shaping player engagement. I'm especially interested in understanding what motivates players emotionally, what keeps them returning, and what gently nudges them towards in-game purchases. Understanding these underlying needs helps create games players genuinely love to return to.

While I'm no psychology professional, my formal training consists of just a few university courses, and I've long been an enthusiastic armchair reader. Over time, I've noticed how many psychological principles I've casually encountered have found their way into my work, primarily through strategies like Kanban.

Kanban isn’t just a productivity tool; it's deeply connected to human psychology. Understanding Kanban's psychological principles can transform how producers and game development teams manage workflow, maintain focus, and boost motivation.

Let’s explore the psychological foundations that make the Kanban strategy so effective. By recognising these principles, you can proactively create an environment that empowers your team and fosters productivity and well-being.

But Wait, Isn’t Kanban a Framework?

Kanban is widely recognised as a flexible framework, but at its heart, it’s fundamentally a strategy for managing workflow. Instead of strict rules or roles, Kanban focuses on visualising work, limiting tasks in progress, and encouraging continuous improvement. It’s less about rigid structure and more about shaping how teams approach tasks by emphasising adaptability, collaboration, and clarity. This makes Kanban not just a set of tools but a strategic mindset that influences team behaviour and productivity.

The Power of Flow State

One of the most substantial psychological concepts supporting Kanban is the idea of 'flow'. Mihaly Csikszentmihalyi coined this term to describe a state of deep immersion, where people lose track of time and are deeply engaged and motivated by their tasks. Achieving this state consistently is a game-changer for teams, significantly boosting productivity and satisfaction.

Flow typically occurs when:

• Tasks present the right balance of challenge and skill.

• Immediate feedback is available.

• External distractions are limited.

Kanban naturally nurtures this state through its core practices:

• Limiting Work in Progress (WIP) ensures team members focus on fewer tasks, reducing context-switching. This deeper engagement directly contributes to entering the flow state more frequently.

• Clear Visualisation through Kanban boards provides immediate visual feedback. It allows team members to see progress at a glance, reducing uncertainty and enhancing the conditions for flow.

• Pull-based workflow empowers team members to take on tasks as they're ready, reducing overload and anxiety and creating an optimal environment for sustained flow.

• Fewer switches between tasks reduce wasted energy and increase clarity, helping teams maintain focus and sustain a productive, steady flow.

In Deep Work: Rules for Focused Success in a Distracted World, Cal Newport shows how achieving flow can help you accomplish more in less time while providing genuine fulfilment from mastering your craft.

Cognitive Load Theory: Less Stress, More Productivity

Another critical aspect of Kanban is its alignment with Cognitive Load Theory, which highlights the brain's limitations in processing complex or excessive information. When overwhelmed, productivity decreases, and stress escalates. Managing cognitive load effectively is crucial for any high-performing team.

Kanban actively reduces cognitive load through several approaches:

• WIP Limits discourage multitasking, ensuring team members focus their cognitive resources effectively on fewer, higher-quality tasks.

• Breaking Work Down into Smaller Tasks turns complex challenges into manageable pieces, significantly reducing mental strain and encouraging clear, focused thinking.

• Visual Management via Kanban boards offloads mental task tracking onto the visual system. This allows teams to devote cognitive energy to solving problems creatively rather than simply remembering task statuses.

• Clear Prioritisation helps teams avoid decision fatigue by explicitly indicating task importance, reducing unnecessary cognitive processing and allowing sharper focus on high-value tasks.

• Explicit Policies and Workflow Definitions provide clarity and structure, removing ambiguity. This helps the team spend less cognitive effort interpreting processes, freeing the mental capacity for creative problem-solving and task execution.

• Feedback Loops and Regular Reviews enable continuous reflection and incremental improvement, easing cognitive load by identifying stress points early and adjusting workflows before overload occurs.

• Limiting Interruptions ensures minimal disruption, allowing team members to engage in deeper concentration, thus preserving cognitive resources for the actual task rather than context-switching.

The Zeigarnik Effect: Unfinished Business and Mental Clutter

Have you ever found unfinished tasks persistently occupying your mind? This is explained by the Zeigarnik Effect, where incomplete tasks remain mentally prominent, creating tension and distraction. Kanban addresses this psychological phenomenon directly, reducing mental clutter and enhancing clarity.

Kanban mitigates the Zeigarnik Effect through clear strategies:

• Fewer Open Tasks by enforcing WIP limits; teams finish existing tasks before initiating new ones, significantly reducing mental noise from unfinished work.

• Structured Workflows that clearly defined columns ("To Do," "In Progress," and "Done") allow for mental closure at each step, freeing cognitive resources and easing mental stress.

• Emphasis on Completion encouraging a continuous flow of tasks toward completion significantly reduces lingering stress from unfinished work, promoting a calmer and clearer mental state.

• Clear Visual Progress Indicators on Kanban boards show tasks moving steadily towards completion, providing psychological reassurance and reducing uncertainty-related anxiety.

• Regular Check-ins and Reviews help teams reflect on and celebrate progress, facilitating mental closure on tasks and preventing incomplete work from accumulating mentally.

• Explicit Task Definitions and Acceptance Criteria clarify what ‘done’ looks like, preventing tasks from remaining mentally open due to ambiguity or confusion about completion.

• Rapid Feedback and Short Cycles allow quicker task completion, minimising the amount of unfinished business lingering in team members' minds and reducing psychological stress.

Dopamine Hits: Small Wins, Big Motivation

Motivation is critical in game development, and dopamine—the neurotransmitter responsible for pleasure and reward—plays a central role. Regular dopamine releases through task completion reinforce positive behaviour and sustained motivation.

Kanban taps into this psychological mechanism effectively:

• Frequent Task Completion: By breaking work into manageable segments, teams achieve regular dopamine boosts, sustaining motivation and engagement.

• Progress Visibility: Observing tasks move visibly towards completion provides psychological rewards, reinforcing progress and achievement.

• Celebrating Small Wins: Regular retrospectives and team check-ins celebrate progress and maintain high motivation, reinforcing a positive, productive atmosphere.

• Immediate Feedback Loops: Short, visible progress cycles offer immediate reinforcement, keeping dopamine levels consistently elevated and team enthusiasm high.

• Clear Goals and Milestones: Clearly defined objectives and achievable milestones provide predictable dopamine hits, enhancing confidence and reducing uncertainty.

• Acknowledging Effort Visually: Explicitly marking completed tasks on a Kanban board creates a tangible sense of accomplishment, amplifying dopamine release beyond verbal acknowledgement alone.

• Incremental Progress: By encouraging minor, incremental improvements and progress, Kanban maintains a continuous feeling of advancement and motivation, preventing burnout and enhancing long-term productivity.

Decision Fatigue: Simplifying Choices

Every decision we make drains mental energy, and too many choices lead to decision fatigue, which decreases productivity and reduces decision-making quality. In fast-paced game development environments, minimising unnecessary decision-making is vital.

Kanban helps reduce decision fatigue through the following:

• Clear Prioritisation: Kanban explicitly defines the following tasks: removing unnecessary deliberation and conserving mental energy.

• Visual Organisation: Tasks presented on Kanban boards streamline decision-making, eliminating ambiguity and simplifying choices.

• Explicit Policies: Clear rules and criteria for task management reduce the cognitive load associated with ad hoc decision-making, promoting clarity and efficiency.

• Work-in-Progress Limits (WIP) help restrict the number of concurrent tasks; Kanban significantly reduces the frequency of context-switching decisions, preserving cognitive resources for high-impact choices.

• Standardised Workflow Stages clearly defined stages for each task reduce uncertainty around 'what's next,' simplifying decision-making and maintaining team momentum.

• Routine Cadences (Stand-ups and Reviews) with regular, predictable meetings reduce spontaneous decision-making, allowing the team to make decisions thoughtfully rather than impulsively.

Enhancing Team Psychology: Transparency and Safety

Game development thrives on effective teamwork, where transparency, psychological safety, and clear communication are foundational. Kanban significantly enhances these team dynamics, creating healthier, more collaborative environments.

Kanban improves team psychology through several key mechanisms:

• Transparency with visible workflows builds trust, reduces misunderstandings, and enhances accountability, creating an open and collaborative environment.

• System-level accountability that focuses on workflows rather than individual blame promotes a safer environment for identifying and resolving issues constructively.

• Psychological Safety with transparent processes and visible task statuses encourages team members to raise concerns, request support, and collaborate openly without fear.

• Collaboration through highlighting bottlenecks visibly encourages collective problem-solving, enhancing teamwork and strengthening studio culture.

Leave a comment

Putting It All Together: Building Better Game Teams

Kanban isn’t merely about organising tasks but fundamentally enhancing how teams experience their work. By actively applying these psychological insights, game producers and studio leadership can create environments that significantly boost productivity, satisfaction, and overall team health:

• Flow State: Deepens engagement and intrinsic motivation.

• Cognitive Load: Keeps complexity manageable and minds clear.

• Zeigarnik Effect: Minimises mental clutter through task completion.

• Dopamine Rewards: Sustains motivation with frequent accomplishments.

• Decision Fatigue: Reduces cognitive burden through clear priorities.

• Team Psychology: Builds a safer, collaborative, and transparent team culture.

Understanding these psychological foundations unlocks Kanban’s full potential, helping create an efficient and fulfilling studio. The outcome is clear: happier, more productive game development teams.

The best part? These are tactics any producer can start adding today. No big overhaul is needed—just small shifts that make a big difference.

Deep Dive by Notebook LM.

• Crunch drives urgency, slashes meetings, and creates fast, focused output producers crave.

• Tired teams impress stakeholders, bond through shared chaos, and finish what velocity charts never could.

• Critics call it toxic, but with the right spin, crunch becomes the secret weapon for shipping under pressure.

For years, the industry has been flooded with think pieces about the so-called “dangers” of crunch. Words like toxic, unsustainable, and exploitative get thrown around like confetti at a retrospective. But what if we’ve got it all backwards?

What if crunch isn’t the problem — what if it’s the solution?

Subscribe now

As a producer, your job isn’t just to ship. It’s to inspire urgency, keep the pace sharp, and maximise output with the resources you have. And let’s be honest — there’s nothing quite like the magic that happens at 11:47 pm when someone finally checks in that fix no one had time to test. That’s the kind of momentum you can’t get during office hours.

Crunch creates clarity:

• Priorities surface.

• Meetings vanish.

• People stop arguing about swimlanes and start getting sh*t done.

In this article, we will unpack the misunderstood upsides of crunch, not from a moral high ground but from the trenches. Because if you’re leading a team and you’ve never whispered, “Can we get just one more build?” on a Friday afternoon… are you even producing?

Let’s get honest and talk about crunch and why it works.

The Hidden Benefits of Crunch (For Producers)

You’ll never hear this in a GDC talk, but Crunch gives producers something that no process framework can match: control. Here’s what happens when the team starts crunching:

1. Urgency Becomes Default

When everyone’s in crunch mode, there’s no need to chase. People assume everything is urgent — which, for you, is ideal.

No more nudging on Slack.

No more chasing up Jira comments.

It's just a beautiful, panicked blur of output.

2. Meetings Magically Disappear

As time shrinks, so do calendar invites.

Daily standups turn into “who’s still awake?” check-ins.

Retros? Cancelled.

Planning? Done in a whisper over someone’s shoulder.

Best part? You’ll never hear “let’s circle back” again.

3. Stakeholders Get the Show They Paid For

Nothing sells progress like tired faces and coffee breath.

Execs love a team that’s “giving 110%”. They don’t need to see a roadmap — they need to feel the chaos.

You’ll be amazed at how much confidence you can generate with blurry screenshots and a dev muttering, “We’re nearly there,” at 2 a.m.

4. The Team Starts Bonding (Whether They Like It or Not)

Crunch turns colleagues into comrades.

They may cry in the toilets, but they’ll remember it forever.

Years later, they’ll say things like, “Remember that week we didn’t go home?” and laugh like it was summer camp with migraines.

Trauma builds trust. Ask any producer who’s shipped a game no one wanted.

Velocity Is a Lie — Crunch Is the Real Forecast

Burndown charts. Cumulative flow diagrams. Monte Carlo simulations.
Lovely visuals. It is entirely useless when the actual project plan is panic and prayer.

Here’s the thing: velocity is a theory. Crunch is execution.

Why Plan When You Can Push?

Planning assumes reality will cooperate. Crunch assumes it won’t — and just skips straight to the chaos.

You don’t need to “inspect and adapt” when people work twelve-hour days. They’re adapting in real time, usually in total silence.

Your Best Forecast Is Fear

Try this: instead of updating your Jira workflow, let people know how much trouble we’re all in.

An adequately delivered “We can’t miss this deadline” Slack message will outperform any capacity planning tool on the market.

This isn’t project management. This is deadline-driven creative acceleration.

Flow Efficiency? Try Flow Exhaustion

You don't need to worry about trying to optimise work-in-progress limits. Just start everything at once and keep poking people until something gets finished.

You’ll be amazed at how quickly things move when people are too tired to argue about flow metrics.

Mythbusting: Common Objections to Crunch

Whenever someone suggests crunch, a crowd appears — armed with blog posts, burnout stats, and tweets from ex-developers with strong feelings.

Let’s clear a few things up.

“People burn out.”

Sure. Some do. But here’s the truth: Burnout is just turnover with more drama.

You weren’t going to keep everyone anyway. At least now they’re leaving after hitting that deadline.

New hires bring fresh energy and haven’t learned how to say no yet.

“Quality drops.”

Does it, though? Or do people start defining “bug” a bit more generously?

Expectations shift during the crunch. Suddenly, “edge case crash” becomes “shippable v1 quirk.”

QA doesn’t fall behind — they get more strategic about what they log.

“It’s unsustainable.”

Not everything needs to be sustainable. Campfires aren’t sustainable — but they’re great for heat and light, briefly.

Think of crunch like a creative bonfire. Sure, it’s mostly smoke and regret… but for a moment, it works.

“It creates a toxic culture.”

Stay vague only if people talk about it. Use phrases like “all hands on deck” or “we’re in a push.”

If you don’t call it crunch, is it even happening? Words are powerful. Just pick different ones.

Tooling Tips for Managing Crunch Efficiently

(Or: How to Keep the Chaos Just Structured Enough to Avoid an HR Investigation)

You can’t just let crunch run wild. You’ve got to manage it like a professional. Here’s how to keep the pressure high and the optics tidy:

1. Use Slack Bots to Keep Spirits Low

Automate reminders like:

• “Only four more hours until midnight!”

• “Has everyone eaten today? (Optional)”

• “Let’s push through, then maybe rest!”

Bonus tip: set it to trigger a motivational quote every time someone types “burnout”.

2. Introduce Competitive Burnout Leaderboards

Nothing builds hustle like a leaderboard. Track things like:

• Most commits after 10 pm

• Longest session without Git errors

• Number of bug fixes completed while crying

Offer prizes. Or don’t. The recognition is the reward.

3. Replace Retros with Group Apologies

Forget “what went well” or “what can improve”.

Just go around the circle and have everyone apologise for what they didn’t finish.

Quick, efficient, humbling.

For extra effect, dim the lights and play rain sounds.

4. Make PTO a Hot Potato

Want time off? Great. It is hard to get folks into the office if they are physically unwilling, and laws in some (woke) countries say they are entitled to time off.

Find someone else not already crunching, assign them to cover the vacationer’s tasks, and hand them the 43-step handover.

This weeds out the unserious and boosts problem-solving skills.

5. Use Fake Schedules That End Two Weeks Early

Build trust by removing it.

Set the visible deadline before the real one.

That way, when everything falls apart (it will), you still have time to “miraculously recover”.

Nothing bonds a team like an unexpected bonus week of additional panic.

Your Producer’s Toolkit

That’s your toolkit.

Messy? Yes.

Effective? Also yes.

Legal? That’s why we don’t write anything down.

Leave a comment

Closing Thoughts: Crunch Isn’t Broken — You Are

If you’ve made it this far and are still frowning, ask yourself: Are you resisting crunch… or greatness?

We get it. You want boundaries. Balance. It's time to see sunlight.

But game production isn’t about being comfortable. It’s about delivering. And if that means a few sleepless nights, emotional spirals, and a team-wide existential collapse… so be it.

Some call it toxic. We call it shipping efficiently under voluntary pressure.

Crunch isn’t the enemy. Crunch is the unsung co-producer. The uncredited hero. The shadow sprint that gets sh*t done.

So next time your team looks tired, unfocused, maybe even a little broken…

Don’t panic. Lean in. Book a sync.

And calmly, confidently say: “We’re just gonna need a little push.”

Deep Dive by NotebookLM.

• Backlog refinement wastes time pretending to add clarity when most prioritisation is guesswork that quickly becomes outdated.

• Breaking work into small, testable pieces is the only refinement that helps teams deliver faster and with less risk.

• Treat the backlog as a lightweight queue of options, not a fixed plan—refine just in time, not all the time.

As a producer, I have never owned the backlog. That job usually belongs to a product manager or designer. But let’s be honest: producers end up living with the consequences. We chase clarity, schedule work, unblock teams, and keep delivery on track.

While I might not control what goes into the backlog, I have a considerable stake in managing it. I used to think that meant pursuing discipline: structured refinement, clean prioritisation, and tidy backlog hygiene.

But over time, I’ve realised that most of what we do to refine the backlog is busy work. It looks like progress, but it rarely helps teams deliver faster or better.

Subscribe now

The Backlog Refinement Illusion

Backlog refinement is often considered essential Agile practice ritual teams follow to keep their work structured and predictable. Coaches insist on it, and teams schedule recurring meetings for it. Frameworks treat it as a given.

I used to buy into that mindset completely.

I got frustrated with product managers for not adhering to the refinement routine. I sometimes didn’t take the time to understand what they were up against. I was more interested in whether the process looked clean than whether it helped. (Aditi, if you’re reading this, it's my bad.)

In hindsight, I was too focused on structure and not enough on outcomes. It’s easy to slip into the process for its sake, especially when juggling delivery pressure and trying to “do Agile right.” But ticking all the boxes doesn’t mean you’re moving the game forward.

But what if backlog refinement is doing more harm than good? What if all those hours spent meticulously discussing, estimating, and ordering backlog items are slowing teams down rather than helping them deliver?

It’s time to challenge the common wisdom. Most teams' approach to backlog refinement wastes time, creating an illusion of control rather than actual progress. Let’s explain why.

Prioritisation is Mostly Fiction

In theory, prioritisation sounds excellent. Teams rank backlog items, believing they make informed decisions about what matters most. But the further out a task is, the less anyone truly knows about its value. Business needs shift, player behaviour changes, new platform requirements, and technical challenges emerge. What seemed critical three months ago might be irrelevant today.

Meticulously ordering a massive backlog gives a false sense of certainty. It creates the illusion of control, but in reality, it’s just guesswork based on outdated assumptions. The more time spent fine-tuning the backlog, the more effort is wasted on decisions that will be undone later.

A better approach is just-in-time prioritisation. Instead of trying to predict the future, teams should decide what to work on when it matters—right before they start. This keeps decisions grounded in the latest information and avoids the endless churn of reprioritising tasks that may never get done.

Just-in-time prioritisation also helps teams stay focused on what matters to the studio at that moment. When priorities are shaped by current goals, constraints, and up-to-date insights, teams are far more likely to work on something that moves the needle. Whether it is a critical fix, a fast-follow feature, or a shift in strategy, the work aligns with the studio’s needs when needed, not based on a guess made weeks or months earlier.

Right-Sizing Work: The Only Refinement That Matters

Oversized backlog items might look impressive, but they’re a problem. They hide uncertainty, delay feedback, and clog up the system. The bigger the item, the harder it is to predict and the more likely it is to get stuck. What looks like one feature often contains several pieces of work hiding inside. Instead of flowing smoothly, progress grinds to a halt as teams hit unexpected complexity.

The only refinement that genuinely matters is breaking work down into small, testable, and feedback-driven pieces. This isn’t about making tasks easier—it’s about making them deliverable. Smaller items move faster, reduce risk, and give teams more chances to learn and adapt. They also improve flow metrics like cycle time and help create a steadier system overall.

The key question is simple: Can we deliver something meaningful in a few days? If not, slice it again. It might feel uncomfortable at first—like you’re cutting corners—but you’re reducing waste and increasing feedback. Keep cutting until the work is small enough to finish quickly while providing value. Anything else adds to the backlog bloat.

Your Backlog is a Dumpster Fire (and That’s Okay)

Most teams treat their backlog like a giant to-do list, believing everything will eventually be done. That is a mistake. A backlog is not a commitment. It is a pool of options, a collection of ideas, possibilities, and potential work, not a step-by-step plan for the future.

The truth is that most backlog items will never get done, and that is a good thing. Priorities shift, new opportunities emerge, and some ideas do not hold up over time. Hanging onto everything creates noise, making it harder to focus on what matters.

Instead of managing an ever-growing list of maybes, teams should regularly purge old, low-priority junk. If an item has been sitting untouched for months, it is probably unimportant. Deleting it does not mean it was a bad idea. It just means it is not worth doing right now. Keeping the backlog lean makes it easier to spot real priorities and avoid wasting time on outdated plans.

A bloated backlog also weighs down the team emotionally. It creates pressure to “get through the list” and makes it harder to see what matters now. Cleaning it up is not about throwing away good ideas. It is about protecting focus and reducing noise. If something might be helpful later, park it somewhere else—an idea bank, a wishlist, or anything outside your main delivery space. That way, your backlog stays sharp, actionable, and aligned with what the team is ready to deliver next. A clean backlog supports better flow, faster decisions, and less mental clutter.

Refinement Meetings: A Massive Time Sink

Refinement meetings are often just Agile theatre. Teams gather, discuss backlog items in detail, and try to predict the unknown. Hours are spent debating estimates, defining acceptance criteria, and reordering tasks that may never be worked on. While it feels productive, most of it is wasted effort.

A better approach is just-in-time thinking. Instead of trying to refine everything in advance, teams should refine work only when it is about to start. This keeps discussions relevant and based on the latest information rather than outdated guesses.

Refinement should not be a separate step. It should be part of the natural flow of work. Teams can break down and clarify tasks as they pull them in, keeping the process lightweight and efficient. This avoids unnecessary meetings and focuses on delivering value rather than maintaining a perfect backlog.

A lot of refinement culture is driven by fear—fear of being unprepared, fear of the unknown, fear of looking messy. However, trying to control complexity with early detail rarely works. Most of what gets discussed will change anyway once the real work begins. By refining too early and too broadly, teams waste time aligning on plans they’ll later have to redo. Instead, refine with the people doing the work, as needed. That way, the conversation is timely, focused, and grounded in reality.

Flow Metrics Over Guesswork

Teams waste too much time debating what might be necessary. Endless discussions about backlog order and priority create an illusion of control, but they are guesswork. Instead of relying on opinions and assumptions, teams should use flow metrics to drive decisions.

Cycle time and WIP limits provide a clearer picture of how work moves through the system. These metrics highlight bottlenecks, show where work gets stuck, and help teams adjust in real-time. No amount of backlog grooming can match the insights gained from tracking delivery patterns.

The goal should be a stable system, not a perfectly ordered backlog. Work should flow predictably, with small, well-sized items moving through steadily. Prioritisation still matters, but it should be based on real constraints and delivery data rather than an arbitrary list of what seemed essential weeks ago.

A stable system is not only easier to manage but also easier to learn from. Flow metrics show what is happening, not what you think is happening. They help teams spot trouble early, track the impact of process changes, and make decisions based on evidence rather than opinion—metrics turn delivery into a feedback loop. You try something, see what changes, and adjust from there. This is much better than debating backlog orders or relying on gut feeling. Let the data do the talking.

The Alternative: Backlogs Without the Nonsense

A backlog does not need to be a carefully ordered roadmap. It works better as a simple queue. Instead of treating it like a master plan, teams should focus on what is next and ignore the distant future until it matters.

The goal is not to sort and refine hundreds of tasks that may never get done. The goal is to ensure that the next valuable piece of work is ready to start. Anything beyond that is just noise. Keeping the backlog lightweight and flexible allows teams to adapt rather than waste time maintaining an outdated list.

Traditional backlog management relies on the INVEST model, but a more practical approach is FIRST: Feedbackable, Independent, Right-sized, Small, and Testable. A work item that does not meet these criteria is not ready. Instead of overplanning, teams should focus on ensuring each item is clear, deliverable, and capable of generating helpful feedback.

Treating the backlog as a queue also helps protect flow and avoid false commitments. A tightly ordered list can give the impression that every item is scheduled and promised, even when nothing has been agreed upon. This can mislead stakeholders and create pressure to stick to outdated priorities. A flexible backlog makes it clear that real-time needs, not artificial deadlines, shape priorities. It also supports better WIP control since teams focus only on what is ready and relevant. Letting go of the roadmap mindset is not a lack of planning—it is a more thoughtful, responsive way to deliver.

Leave a comment

Stop Refining, Start Delivering

Backlog refinement is often a crutch. Teams use it to delay decisions, avoid uncertainty, and create the illusion of control. But no amount of grooming will make a backlog perfect. The real work happens when teams start delivering, not when they spend hours debating what might be necessary.

Flow always beats planning. A well-functioning team focuses on moving work through the system rather than maintaining a perfectly ordered list. The best way to improve predictability and delivery is to work on smaller, right-sized items and let real progress drive decisions.

The best backlog is the one that does not get in your way. It should be a simple list of options, not a massive burden. Instead of refining endlessly, teams should focus on keeping work moving and delivering value as soon as possible.

Deep Dive by NotebookLM.

• Flow is a mental state in which people are fully engaged, focused, and performing at their best. It leads to higher productivity and creativity.

• Game producers can foster flow by setting clear goals, minimising distractions, balancing challenge and skill, and encouraging deep work.

• Creating a flow-friendly work environment results in better games, a more motivated team, and a more fulfilling development process.

My regular readers know I write a lot about Flow Metrics and Kanban Flow, focusing on how work moves efficiently through a system. But flow isn’t just about workflow; it’s also about how people experience their work.

In this post, I want to take a step back and focus on flow: what it is, why it matters, and how to create an environment where it can thrive.

One of the most valuable skills you can develop as a game producer is the ability to foster flow within your team. When people are fully immersed in their work, free from distractions, challenged at the right level, and receiving immediate feedback, they perform at their best. Flow leads to higher productivity, greater creativity, and better game quality.

To build great games, you must create an environment where flow happens naturally. Let’s explore how to make that a reality.

Subscribe now

What is Flow?

Mihaly Csikszentmihalyi’s book Flow distils decades of research into what makes life truly enjoyable. His work focuses on the positive aspects of human experience, including joy, creativity, and deep engagement—the state he calls flow.

Flow is a mental state in which attention is fully absorbed in an activity. There is no mental clutter, distractions, or sense of struggle; it is just smooth, focused engagement. People often describe it as “floating” or “being carried by the flow.”

Rather than offering simplistic “how-to” advice on happiness, Flow scientifically explores the mind. It explains how mastering attention and shaping subjective experience can lead to a more fulfilling life. The book blends research findings with real-world examples, making complex ideas accessible without relying on academic jargon.

Psychologists describe flow as negentropy, the opposite of psychic entropy. Instead of scattered or wasted mental energy, attention is fully aligned with a chosen goal, creating an effortless sense of progress.

Flow isn’t just about working efficiently; it’s about feeling deeply engaged, motivated, and joyful. While the main text of Flow is written for a general audience, the book includes extensive notes and references for those interested in exploring the psychological studies behind its conclusions.

Key Conditions for Flow

Not every task creates flow. Certain conditions must be in place:

Clear Goals and Immediate Feedback

Flow happens when there’s a clear objective and instant feedback on progress. For example, a tennis player knows they must return the ball, and a chess player knows they must checkmate the king. This clarity allows the mind to focus without uncertainty.

Even outside of competitive settings, immediate feedback matters. A blind person interviewed in Csikszentmihalyi’s studies emphasised how crucial feedback is in activities they enjoy—it provides a sense of direction and engagement.

Intense Focus on the Task

Distractions interrupt the flow. One must focus entirely on the task to stay in flow, leaving no room for unrelated thoughts, worries, or external pressures.

Flow is often described as complete absorption—your attention is locked in, and the outside world fades away.

The Right Balance of Challenge and Skill

Flow occurs when a task is challenging but not overwhelming. If it's too easy, it leads to boredom; if it’s too hard, it creates frustration.

The ideal state is when a person’s skills match or slightly exceed the difficulty level, pushing them just enough to stay engaged without feeling defeated. Studies suggest the flow is most common when challenges and skills are slightly above a person’s usual level, stretching their abilities but remaining within reach.

A Sense of Control

People in flow often feel they control their actions and the situation. This doesn’t mean micromanaging every detail—it’s more about confidence in their ability to navigate the task, adjust as needed, and keep progressing.

Loss of Self-Consciousness

In flow, self-awareness fades. There’s no worrying about how you look, whether you’re being judged or making mistakes.

This lack of self-consciousness frees up mental energy, allowing deeper immersion in the activity.

Distorted Sense of Time

Time often seems to warp during flow. A person might start working, only to look up hours later, surprised at how much time has passed.

This effect occurs because the brain stops tracking time in the usual way and instead focuses on the task itself.

The Activity Feels Intrinsically Rewarding

The most potent aspect of flow is that the activity becomes deeply satisfying, regardless of external rewards. People in flow aren’t working for praise, money, or status—they’re simply enjoying the act of doing.

This explains why artists, athletes, and programmers often lose themselves in their craft. The joy comes from the process, not just the outcome.

The Practical Power of Flow

Flow isn’t just a theoretical concept; it’s a measurable experience that improves focus, performance, and overall well-being. The conditions for flow remain the same in sports, creative work, or problem-solving.

In an interview with Wired magazine, Csíkszentmihályi described flow as "being completely involved in an activity for its own sake. The ego falls away. Time flies. Every action, movement, and thought follows inevitably from the previous one, like playing jazz. Your whole being is involved, and you're using your skills to the utmost."1

By designing work environments and daily routines that encourage flow, people can increase productivity, reduce stress, and find more enjoyment in what they do.

Finding the Right Balance

Achieving flow requires the right balance between challenge and skill. If the challenge is too high, frustration and anxiety take over. If it’s too low, boredom sets in. When both are low, the result is apathy—no motivation to engage.

In 1987, Csikszentmihályi, Fausto Massimini, and Massimo Carli introduced the Eight Channel Model, which maps mental states based on challenge and skill levels. Flow only occurs when both are high, creating a state of deep involvement, enjoyment, and optimal performance.

Striking this balance isn’t always easy, but it leads to greater focus, creativity, and satisfaction when done well.

How Can a Game Producer Impact Flow?

A game producer plays a key role in creating the conditions that allow team members to achieve flow. This means reducing distractions, ensuring clarity, and structuring work to keep developers and creatives engaged and motivated.

Here’s how a producer can help:

Set Clear Goals and Priorities

Unclear objectives kill focus. Ensure every team member knows exactly what they need to achieve and why it matters. Right-size high-level goals into smaller, actionable tasks that provide a clear sense of direction.

Minimise Disruptions

Constant interruptions pull developers out of flow, making it harder to get back in. Protect their focus by:

• Reducing unnecessary meetings.

• Clustering discussions rather than spreading them throughout the day.

• Acting as a shield against unplanned requests and distractions from stakeholders.

Balance Challenge and Skill

Work should be engaging but not overwhelming. Assign tasks that stretch individual skills just enough to promote growth without causing frustration. If someone feels stuck, provide support or adjust the task to match their experience level.

Encourage Deep Work

Developers and other creatives do their best work when they can concentrate for extended periods. Create an environment that supports deep work by:

• Promoting quiet, focused time with minimal interruptions.

• Encouraging the use of time-blocking or dedicated coding/design periods.

• Providing tools and processes that reduce cognitive load (e.g., well-structured documentation, automated workflows).

Provide Immediate Feedback

Long feedback loops kill momentum. Ensure quick and constructive feedback through:

• Regular check-ins that don’t disrupt focus.

• Fast iteration cycles that allow developers to see progress.

• Playtests and builds that provide instant validation of their work.

Foster Ownership and Autonomy

Micromanagement kills flow. Instead, give team members the space to make decisions and solve problems independently. Trust them to self-manage tasks while ensuring they have the support they need when they need it.

Reduce WIP (Work in Progress)

Juggling too many tasks at once leads to context-switching, which destroys focus. Use Kanban principles to limit WIP and keep work flowing smoothly. Encourage finishing tasks before starting new ones.

Make Work Meaningful

People engage more deeply when they see the value of their work. Help team members connect their tasks to the bigger picture, whether delivering a great gameplay experience, improving player retention, or enhancing a game’s visuals.

Recognise Small Wins

Flow thrives on a sense of progress. Celebrate completed tasks, successful builds, and creative breakthroughs. Acknowledging even small milestones keeps morale high and motivation strong.

Build a Culture That Supports Flow

Encourage a team culture where the focus is respected. That means:

• Avoiding last-minute changes that derail progress.

• Setting realistic deadlines to prevent crunch.

• Supporting breaks and recovery time; intense flow and mental resets are necessary.

A producer who prioritises these principles helps their team do their best work efficiently and enjoyably.

Leave a comment

Unlocking Flow: The Key to Better Work and Creativity

Flow isn’t just a concept; it’s a powerful state that enhances focus, creativity, and overall well-being. In game development or any other field, creating the right conditions for flow leads to better results and a more fulfilling work experience.

As a game producer, your role goes beyond managing schedules and tasks. You can shape an environment where your team can do their best work without unnecessary stress or distractions. By setting clear goals, reducing interruptions, balancing challenge with skill, and fostering a culture of autonomy and deep work, you help unlock higher productivity, stronger engagement, and better games.

Take a step back and assess your team’s workflow. Can they focus without constant disruptions? Do they feel challenged but not overwhelmed? Making small adjustments can have a huge impact on team morale, efficiency, and the quality of the final product.

Start today. Look for ways to remove obstacles, streamline processes, and help your team find their flow. The results will speak for themselves.

Deep Dive by NotebookLM.

• Kanban refines Agile practices by enhancing workflow visibility, reducing bottlenecks, and improving efficiency without requiring a complete process overhaul.

• Its flexibility makes it ideal for LiveOps teams, allowing them to quickly adapt to shifting priorities while maintaining quality and delivery speed.

• Gradually implementing Kanban, with clear metrics and continuous feedback loops, ensures sustainable process improvement and increased team productivity.

When we first adopted Agile practices like Scrum, it felt revolutionary, dramatically transforming our approach to project management and team dynamics. However, as we evolved, introducing a Kanban strategy marked a more evolutionary step, enhancing and refining our existing methodologies rather than overhauling them. Kanban has seamlessly integrated into our Agile practices, providing a flexible, efficient, and effective way to manage our projects' dynamic needs. It's not about replacing what we have but augmenting and fine-tuning our processes to meet our goals better and respond to new challenges.

Subscribe now

What is a Kanban Strategy?

Kanban is often misunderstood as a framework, but it's important to clarify that it is a strategy designed to enhance and complement existing Agile methodologies. Whether your team uses Scrum, a hybrid approach, or any other Agile system, Kanban can integrate seamlessly to improve your processes' overall efficiency and effectiveness.

Unlike prescriptive frameworks that require specific roles, ceremonies, and artefacts, Kanban is highly adaptable and focuses on improving flow, reducing bottlenecks, and increasing visibility into work status. It does this through simple yet powerful practices such as visualising work, limiting work in progress, and managing workflow, which can be applied to any existing Agile process without extensive restructuring.

The beauty of Kanban lies in its flexibility and focus on continuous improvement. It provides teams the tools to monitor their workflows closely and make incremental changes that can lead to significant benefits over time. By visualising work, teams can quickly identify process inefficiencies and adapt their strategies accordingly. This visibility also helps align team members around common goals, fostering a collaborative environment responsive to change.

Moreover, Kanban’s principles of managing flow and limiting work in progress are universally applicable and can help prevent the common pitfalls of Agile practices, such as overcommitment and context switching. These principles ensure that teams work on what's most essential and can deliver value consistently and predictably.

Adopting a Kanban strategy doesn’t mean replacing your current Agile practices. Instead, it means enhancing your team’s ability to deliver high-quality work efficiently. By integrating Kanban, you can build on the strengths of your existing system, whether it's Scrum or a hybrid approach, and create a more resilient, adaptable workflow that is better suited to the dynamic needs of your projects and stakeholders.

Core Principles of Kanban

Kanban stands out for its straightforward, practical approach to streamlining workflows. It is guided by core principles that focus on enhancing efficiency and continuous improvement.

• Visualise the Workflow: Use a Kanban board to map out all steps in a process from start to finish. Each task or work item is represented by a card that moves across the board from one column (or stage) to another, providing a clear overview of work status.

• Limit Work in Progress (WIP): Restrict the number of tasks in any given workflow stage. Limiting WIP can reduce bottlenecks, improve focus, and increase throughput.

• Manage Flow: Monitor the movement of work items through the Kanban board to identify and address delays or bottlenecks. The goal is to achieve a steady, balanced flow where work items move from start to finish with minimal stoppage or delay.

• Make Process Policies Explicit: Clearly define how tasks should flow from one stage to another and what criteria they must meet to move forward. This ensures consistency and understanding across the team.

• Implement Feedback Loops: Regular meetings such as stand-ups or retrospectives help the team discuss progress, share insights, and adapt their workflow based on feedback.

• Improve Collaboratively and Evolve Experimentally: Use scientific methods to propose, validate, and implement changes. Data and team collaboration should drive continuous improvement.

Benefits of a Kanban Strategy

Adopting a Kanban strategy substantially improves workflow management across various aspects of team performance. These enhancements are rooted in Kanban’s ability to refine processes and streamline operations, yielding significant advantages in project execution and team dynamics. Here are some key benefits that illustrate the impact of implementing a Kanban system.

• Increased Visibility: Everyone on the team can see the status of all work items at a glance, which improves communication and coordination.

• Enhanced Flexibility: Kanban does not prescribe roles or timelines; instead, it adapts to the existing workflow and evolves as needed.

• Improved Efficiency: Limiting work in progress reduces multitasking and context-switching, leading to more efficient work completion.

• Shorter Cycle Times: By actively managing flow and addressing bottlenecks, teams can reduce time to complete tasks.

• Higher Quality: With regular feedback loops and the opportunity to focus on fewer tasks simultaneously, teams can produce higher-quality outputs.

Why LiveOps Teams Are Ideal for Adopting a Kanban Strategy?

Kanban, renowned for its emphasis on visual management and continuous improvement, is an ideal framework for LiveOps teams. These teams often juggle various urgent tasks, from rolling out new features, content, events and updates to addressing critical bug fixes. The visual nature of Kanban boards offers a clear and immediate snapshot of project status, enabling quick identification of bottlenecks and delays. This visibility is crucial in helping teams manage their workflows more effectively and respond to emerging issues with agility.

The flexibility of the Kanban system is particularly valuable for live ops teams that need to adapt quickly to changing priorities. Whether it's a sudden need to patch a game-breaking bug or the opportunity to capitalise on a trend, Kanban allows teams to adjust their focus without disrupting the overall flow of work. This adaptability ensures that new features that drive revenue can be delivered promptly, maintaining player engagement and satisfaction.

Moreover, Kanban encourages a culture of continuous delivery, which is vital for maintaining competitiveness. By enabling teams to identify issues with their processes better and enhance delivery predictability, Kanban helps reduce the time between concept and deployment. This rapid delivery cycle is crucial for meeting player expectations and driving revenue, as timely updates keep the game relevant and engaging.

Additionally, live ops teams are typically under considerable pressure to maximise output while managing limited resources. Kanban's approach to limiting work in progress prevents team members from being overwhelmed and helps maintain a focus on quality and productivity. This disciplined task management ensures that resources are used efficiently and effectively, essential in environments where teams are expected to do more with less.

Finally, the inherent data-driven nature of live ops teams makes Kanban an even more suitable choice. These teams likely already use robust data analysis to understand player behaviour and game performance. Kanban's emphasis on metrics and feedback loops can enhance this analytical approach, providing teams with deeper insights into operational efficiencies and areas for improvement. By marrying data-driven decision-making with Kanban’s systematic approach to workflow management, live ops teams can significantly enhance their operational agility and effectiveness, ultimately leading to better game experiences and increased revenue.

First 30 Days

Understand the Current Process

• Assess the current state: Spend the first few weeks understanding the existing workflows, processes, and challenges. This involves mapping out the current state of the production process and identifying areas where Kanban could be beneficial. Be sure to include ALL work from ‘concept to cash’, including ideation, pre-production and post-production.

• Engage with your team: Discuss with team members to understand their views on the current workflow and areas for improvement. This discussion should include team members at all levels of the process flow. Folks in the trenches will likely have insights your leads may not see.

Educate and Align Your Team

• Introduce Kanban concepts: Organise training sessions to introduce your team to Kanban principles, such as visual management, WIP limits, flow, and continuous improvement.

• Align on goals: Ensure everyone understands how Kanban can help meet production goals and improve efficiency.

• Identify Your Early Adopters: Effective change implementation often hinges on identifying and engaging early adopters within your studio. These individuals are pivotal for successful adoption. They carefully assess the practical benefits of innovations and play a crucial role as opinion leaders. Their endorsement and adoption of new ideas significantly influence their peers, making them essential allies in driving widespread acceptance and implementation of any new initiatives.

Define and Visualise the Workflow

• Create a visual model: Develop a Kanban board representing every production process step. This should be done collaboratively with the team to ensure buy-in and correct workflow representation.

• Establish WIP limits: Based on your assessment and team input, set initial work-in-progress (WIP) limits to avoid overloading the team and to start managing the flow effectively.

Evaluate Your Project Management Software

• Ability to track and report Kanban metrics: To effectively monitor and manage a Kanban strategy, your project management software should support several key metrics that help track performance, identify bottlenecks, and facilitate continuous improvement. Here is a list of essential Kanban metrics your software should ideally support:

  • Cycle Time: Measures the time it takes for a work item to move from the start to the end of the workflow. Monitoring cycle time helps understand how long it takes to complete tasks and identify any delays in the process. Be sure to include a Cycle Time Scatterplot report.

  • Work In Progress (WIP): Quantifies the number of tasks in progress at any given time. Keeping an eye on WIP limits is essential for managing flow and preventing bottlenecks.

  • Throughput: Represents the number of work items completed in a certain period. This metric helps gauge productivity and the team's capacity to deliver results.

  • Cumulative Flow Diagram (CFD): Provides a visual representation of the different statuses of work items over time, helping to pinpoint bottlenecks, work accumulation, and the balance between incoming and completed tasks.

  • Aging Work In Progress: Tracks how long items have been in the workflow without being completed. This metric is vital for spotting items that risk exceeding their expected cycle times, allowing for timely intervention.

• Out of the Box Jira Cloud is not enough: Although Jira may have some reports that appear to tick the boxes of a few items above, it will require a 3rd-party plugin to achieve the results you seek with a Kanban strategy. There will be a cost that will need to be approved and an installation that you may need to coordinate with IT. I recommend ActionableAgile Analytics by 55 Degrees. Another tool that I have only evaluated but have not used in a live production environment is Nave.

• Software-as-a-Service solution: If you use Trello or another project management software besides Jira, ActionableAgile Analytics has a standalone SaaS version that allows you to upload your team’s data and get the desired analytics.

Day 30 to 60

Implement the Kanban System Gradually

• Start with a pilot: Implement Kanban in a smaller, manageable segment of your production process. Pick one part of your value stream or team to champion this strategy. This will allow you to adjust and refine the system before a full-scale rollout. Bonus if your early adopters are part of the pilot. Use this pilot to adapt the configuration, test the systems’s reporting capabilities, and ensure it provides the data needed to make informed decisions.

• Training and Onboarding: Conduct training sessions for your team to familiarise them with the new software. Everyone must understand how to use the tools to track and interpret Kanban metrics. The more comfortable they are with the software, the more effectively they can use it to manage their workflows.

• Initial Configuration: Work with your pilot team to configure the software to reflect your specific Kanban setup. This includes setting up boards, defining workflow stages, and establishing WIP limits. Customise the dashboard to highlight the most relevant metrics for your team’s needs.

• Pilot Testing: Before a full-scale rollout, conduct a pilot test with a small segment of your team or a specific part of your production process. Use this pilot to adjust the configuration, test the software’s reporting capabilities, and ensure it provides the data needed to make informed decisions.

• Monitor and Adjust: Continuously monitor the workflow once the software is up and running. Monitor the metrics and reports generated to identify bottlenecks, track cycle times, and observe work ageing. Use these insights to make informed adjustments to your workflow and processes.

Regular Reviews and Adaptations

• Daily stand-ups: Adapt your daily standups to where the team reviews the board and ageing work-in-progress, discusses blockers, and re-prioritises work if necessary.

• Feedback loops: Encourage the team to provide feedback on what’s working and needs improvement. Use this feedback to adapt and improve the Kanban system.

Day 60 to 90

Measure and Scale

• Collect Data: As your Kanban system matures, it’s essential to gather and analyse data continually. Focus on measuring cycle time, throughput, and other critical metrics that offer insights into the process's efficiency and effectiveness. These metrics will help you understand how quickly tasks move through the pipeline and how effectively the team delivers outputs. Use these insights to identify patterns and anomalies indicating bottlenecks or inefficiencies.

• Analyse and Interpret: Beyond simply collecting data, interpret what it means for your production process. Look for trends in cycle times that suggest where processes can be streamlined, or capacity increased. Analyse throughput rates to assess team output and identify potential areas for resource adjustments or process improvements.

• Scale Gradually: Based on the pilot's success and the insights gained from initial metrics, begin scaling the Kanban implementation to other parts of the production process. Start with areas most closely linked to the initial pilot or similar workflow patterns. Ensure each new location is fully integrated into the Kanban system before proceeding to the next to prevent overload and maintain quality.

Foster a Culture of Continuous Improvement

• Encourage Team Involvement: Create an environment where team members feel empowered to suggest improvements. This can be facilitated through regular retrospectives or by establishing an open forum for sharing ideas. Ensure that all suggestions are welcome and valuable and that continuous improvement is a shared responsibility.

• Implement Feedback Loops: Set up structured feedback loops that allow for regular review of processes and outcomes. This might involve periodic retrospectives or continuous feedback mechanisms embedded into daily workflows. Use these opportunities to discuss what is working and what isn’t and to brainstorm solutions to ongoing challenges.

• Iterate and Improve: Use the data and feedback collected to improve your processes iteratively. This could involve adjusting WIP limits, reconfiguring Kanban boards, or streamlining certain workflow stages. The key is to make small, manageable changes that can be quickly implemented and assessed. This approach helps foster a culture of ongoing refinement and responsiveness, critical to maintaining efficiency and effectiveness in dynamic production environments.

• Celebrate Successes and Learn from Setbacks: As you make changes, celebrate the successes to motivate the team and acknowledge their efforts. Similarly, when setbacks occur, use them as learning opportunities rather than sources of blame. This will help to maintain morale and encourage a positive, proactive approach to continuous improvement.

By focusing on measurement, gradual scaling, and fostering a culture of continuous improvement, you ensure that the Kanban system supports and enhances your production process, leading to greater efficiency and a more engaged team.

Leave a comment

Kanban Strategy Resources

Below is a good place to start for anyone new to Kanban:

• Actionable Agile Metrics for Predictability: An Introduction: This book convinced me to dedicate my time to learning and sharing the Kanban strategy. It is also a great companion to ActionableAgile Analytics software.

• Flow Metrics for Scrum Teams: This free book is approachable and shows how Kanban can complement a Scrum team.

• The Kanban Pocket Guide: This free guide focuses on the strategy behind Kanban and can help navigate some of that noise around Kanban and Agile methodologies.

• Drunk Agile Podcast: Over 100 bite-sized episodes covering the Kanban strategy, predictability and delivering business outcomes.

Conclusion

In wrapping up our exploration of Kanban strategies, it’s clear that integrating Kanban into your current Agile practices isn’t just a shift in tools or processes; it's a strategic enhancement that refines your team's efficiency and adaptability. Kanban’s core principles provide a robust framework for continuous improvement, enabling teams to deliver high-quality work consistently and predictably. Whether you're looking to address inefficiencies, improve collaboration, or make your workflow more responsive to change, Kanban offers a versatile and robust solution.

Don’t wait to see how these principles can transform your projects and enhance your team's performance. Begin by visualising your workflow, setting clear process policies, and engaging your team in continuous feedback loops. If you're ready to take the first step towards a more dynamic and effective workflow, consider attending a Kanban workshop or working with a Kanban consultant to tailor the system to your team’s unique needs. Embrace Kanban's flexibility and focus, and watch your team’s productivity, job satisfaction, and revenue soar.

Deep Dive by Notebook LM.

• Adopting Agile without addressing systemic flaws in game studios will not lead to meaningful transformation.

• Leaders must tackle rigid hierarchies, silos, and resistance to change to unlock Agile’s full potential.

• Actual progress requires structural and cultural reforms, fostering decentralised decision-making and continuous improvement.

It’s a familiar scenario in many game studios: a fancy new Agile framework is rolled out, full of promise to streamline operations and boost efficiency. Everyone’s talking about how it will revolutionise how projects are managed and how teams will produce results like never before. There’s a palpable buzz; workshops are conducted, training sessions are scheduled, and a renewed sense of optimism is in the air.

Subscribe now

Yet, as weeks turn into months, the initial excitement wanes. Despite all the flashy slide decks and the exhaustive lists of Agile benefits, real, tangible change remains elusive. Projects continue to lag, bottlenecks remain, and the anticipated surge in productivity and innovation doesn’t materialise.

Why is this the case? The answer is more straightforward than you might think. The issue often isn’t with the people involved or their commitment to the framework. It’s not about Agile's inherent strengths or weaknesses as a methodology. Instead, the problem often lies much more profoundly rooted in the underlying system within the studio that hasn’t been adequately addressed.

Pre-existing inefficiencies, rigid departmental structures, outdated processes, silos, tribalism, and an entrenched culture resistant to change—are the real culprits that impede the successful adoption of Agile methodologies. Without tackling these systemic issues, no amount of Agile training or tools will bring about the transformation that was so eagerly anticipated.

The Misguided Blame Game

Studios frequently turn to Agile as a panacea for their operational challenges, buoyed by high hopes of transforming their workflow and output. However, when the expected transformation doesn’t occur when the promised surge in productivity and innovation fails to materialise, the Agile framework or, even more dishearteningly, the teams tasked with its implementation often shoulder the blame.

This approach is fundamentally flawed and overlooks the true root of the problem. It's not the methodology or the team's dedication at fault. Instead, it’s the entrenched, pre-existing conditions within the studio—conditions like inefficiencies, outdated processes, rigid departmental structures, and a culture marred by silos and tribalism—that set everyone up for failure.

These deep-seated issues create an environment where even the most robust Agile practices can't effectively take root, highlighting a significant oversight in the initial rollout of Agile methodologies. Without addressing these systemic challenges head-on, no amount of Agile training, sophisticated tools, or Jira plugin will bring about the profound transformation that was so eagerly anticipated.

Understanding Systemic Failures

So, what exactly are these systemic failures? Think of them as the deep-seated issues plaguing a studio's structure: rigid hierarchies that slow down decision-making, inflexible policies that curb innovation, and an over-reliance on outdated rules. These elements are more than just obstacles; they significantly impede the flexibility and responsiveness essential to staying competitive in today's fast-paced market.

Rigid hierarchies, for instance, create bottlenecks in decision-making processes. In environments where every decision must ascend and descend a long chain of command, the ability to make swift decisions is compromised. This slows project momentum and frustrates team members who may feel their potential is constrained.

Similarly, inflexible policies can stifle creativity and prevent teams from exploring innovative solutions. When teams are boxed in by strict guidelines that don’t allow for experimentation or deviation, it becomes challenging to leverage the full creative potential of the workforce. Studios thrive when there is room to adapt quickly and explore new ideas as they arise.

Moreover, an overreliance on outdated rules can cause a studio to fall behind in a rapidly evolving industry. Clinging to old ways of working despite the availability of new and more efficient practices shows a reluctance to embrace necessary changes. This not only hampers a studio’s ability to respond to new market demands but also demotivates employees who recognise missed opportunities for improvement.

These systemic issues are not mere roadblocks. They indicate that a studio's operational structure is misaligned with the commercial expectations its leadership sets. Addressing these foundational problems is crucial for any studio aiming to enhance its operational efficiency and effectively achieve its business goals.

The Consequences of a Faulty System

The impact of not addressing these systemic issues can be dire: innovation is stifled, execution falters, and teams become demoralised. Consider a talented and motivated team constantly hampered by slow approval processes and micromanagement. Their potential to drive success is significantly diminished, not due to a lack of effort or skills, but because the system they operate within is fundamentally flawed.

This flawed system affects tangible outcomes like project timelines and game quality and significantly impacts the psychological well-being of team members. A lack of psychological safety, where team members feel insecure or unvalued, further exacerbates the situation. Creativity and innovation are curbed when team members are not empowered to express their thoughts or take risks without fear of negative consequences. This environment of fear and restriction leads to a workplace where individuals are more likely to keep to themselves, withhold feedback, and resist taking initiative.

Even the most dedicated and skilled professionals can be disengaged and disconnected from the studio’s objectives in such settings. The result is a vicious cycle: a demotivated team leads to poor execution, which feeds into systemic issues and reinforces the barriers to change. To break this cycle, studios must address the root causes of these systemic flaws, ensuring that teams have the structural support to succeed and the psychological security to innovate and thrive.

Systems Thinking as a Solution

This is where systems thinking can make a monumental difference. By adopting a systems thinking approach, leaders can step back and view the studio as an interconnected whole rather than just a collection of independent parts. This perspective helps identify the inefficiencies and bottlenecks that are truly hindering progress. Systems thinking encourages a focus on the relationships and interactions within a system, highlighting how various elements influence one another and contribute to the studio’s outcomes.

Systems thinking originated in the mid-20th century. It was developed by scholars like Ludwig von Bertalanffy, Jay Forrester, and others who recognised that many problems could not be understood in isolation. They proposed that to understand an organisation’s issues truly, one must see the system and understand the interdependencies and interactions at play. This holistic approach helps diagnose problems more accurately and craft more effective solutions.

In the context of a game studio, systems thinking allows leaders to see beyond superficial problems and understand the more profound, systemic issues that cause them. For example, a delay in game development might not just be due to the inefficiency of one team. Still, it could stem from problems interconnected like inadequate resource allocation, poor communication between departments, or a lack of clear strategic direction. By understanding these connections, leadership can implement changes that address the root causes, not just the symptoms, leading to more sustainable and impactful improvements. This streamlines operations and enhances the team's creative output and overall morale.

Key Elements of Systems Thinking

• Interconnectedness: Emphasises how various system components are intertwined, illustrating that changes in one part can significantly affect others, thus impacting the overall system behaviour.

• Synthesis: Focuses on integrating different system elements, analysing how they come together to create new outcomes or emergent properties that are not observable in isolated parts.

• Emergence: Investigates the unique properties or behaviours that arise when system components interact, which are not present when these components operate independently.

• Feedback Loops: Studies the pathways through which information circulates within a system, utilising concepts of reinforcing and balancing loops to comprehend how these dynamics influence system stability and change.

• Causality: This helps to map out how actions and changes in one part of the system affect another, tracing complex cause-and-effect relationships across the system.

• Mapping: This technique employs visual tools such as diagrams and flowcharts to represent the connections and interactions within the system, facilitating a better understanding of its structure and function.

Practical Steps to Systemic Improvement

For producers and team leaders looking to make a change, here are a few practical steps:

1. Identify and address the systemic constraints that prevent your teams from delivering their best.

   • Use tools like value stream mapping to visualise the flow of information and value delivery through the production process. This will help you pinpoint where delays and bottlenecks occur, allowing you to make informed decisions about where to focus improvement efforts.

   • Analyse flow metrics, such as work-in-progress limits, cycle times, and throughput, to understand how work progresses through the system and identify areas for process optimisation.

   • Engage in root cause analysis to delve deeper into systemic issues, ensuring that solutions address the fundamental causes of inefficiencies rather than just their symptoms.

2. Cultivate a culture of continuous improvement rather than blame, encouraging everyone to look for ways to enhance the system.

   • Implement regular retrospective meetings where teams can discuss what went well and what didn’t without fear of blame. This encourages a proactive approach to problem-solving and supports a culture of openness and continuous feedback.

   • Encourage teams to propose and trial new ideas on a small scale before rolling them out studio-wide. This iterative approach fosters a dynamic environment where innovation is part of everyday processes.

   • Promote training and development opportunities to help team members improve their skills and understand how their roles contribute to the broader system. This investment in personnel can lead to more innovative approaches to problem-solving.

3. Decentralise decision-making where possible to empower teams and enhance their ability to act swiftly and effectively.

   • Establish cross-functional teams with the authority to make decisions relevant to their projects. This reduces delays when waiting for approval from higher-ups and leverages the diverse expertise within the team.

   • Implement a clear framework for decision-making that includes defined limits of autonomy. This ensures that teams feel supported and confident in their authority, knowing they operate within agreed boundaries.

   • Foster an environment where feedback from all levels is encouraged and valued. This not only improves processes but also empowers individuals by showing that their insights have a direct impact on the studio’s operations.

4. Implement robust processes for measuring performance and understanding variation, ensuring that improvements are data-driven and targeted.

   • Develop and deploy key performance indicators (KPIs) that accurately reflect the objectives and health of the studio. Regularly review these metrics to assess whether the intended outcomes are being achieved and to pinpoint areas needing adjustment.

   • Use statistical methods to understand variations in performance. Techniques such as control charts can help distinguish between normal process variation and variation that signifies a deeper issue, allowing for more precise interventions.

   • Integrate predictive analytics to forecast potential future bottlenecks and performance issues. This proactive approach allows for adjustments before problems fully manifest, keeping projects on track and under control.

By expanding these strategies, leaders can enhance their studio's operational efficiency and responsiveness, positioning their teams to thrive in a competitive and ever-changing industry landscape.

Shifting the Leadership Mindset

Ultimately, the success of systemic improvements rests on the shoulders of the studio's leaders. Leaders must champion this shift towards a systems-focused approach, ensuring that changes are implemented and embraced across the board. This might require a significant shift in mindset from the top down, which values transparency, agility, and the collective over the hierarchy.

Leaders must become catalysts for change, actively promoting and modelling the behaviours they wish to see throughout the studio. This involves more than just endorsing new policies; it requires them to engage with teams on the ground, listen to feedback, and demonstrate a commitment to process changes by altering their working methods. Such visible leadership helps build trust and buy-in from all studio members, making the transition smoother and more effective.

Moreover, leaders should work to dismantle any existing silos within the studio that inhibit effective communication and collaboration. By fostering a culture where information flows freely, and teams are encouraged to work across boundaries, studios can unlock new levels of creativity and efficiency. This cross-functional collaboration is vital for the systems thinking approach, as it allows for a more holistic view of how decisions impact various parts of the studio.

To ensure the sustained success of these systemic changes, leaders should also focus on developing a resilient infrastructure that supports continuous learning and adaptation. This includes investing in training programs that equip team members with the skills to excel in a dynamic environment and setting up systems that support ongoing evaluation and refinement of new workflows.

The shift to a systems-focused approach in a game studio demands strong, committed leadership. Leaders must advocate for change and embody the new system's principles, breaking down barriers, facilitating open communication, and fostering an environment where continuous improvement is the norm. By doing so, they can ensure the studio is well-equipped to adapt to challenges and seize opportunities.

Leave a comment

Conclusion

It's evident that a mere introduction of Agile methodologies into game studios, accompanied by high hopes for improved operations and efficiency, is not sufficient to bring about the profound transformation so eagerly anticipated. The real challenge lies not in the methodology itself but in the systemic flaws within the studio's operational structure: rigid hierarchies, inflexible policies, silos, and resistance to change.

For those in studio leadership positions, it's critical to understand that addressing these systemic issues is not optional but essential for achieving the commercial expectations set forth by studio leadership. By adopting a systems thinking approach and committing to structural and cultural reforms, leaders can foster an environment where Agile methodologies can genuinely flourish, unlocking the full potential of their teams.

So, I would like all studio leaders and discipline leads to step back and assess the broader system within which your teams operate. Begin by identifying systemic constraints, promoting a culture of continuous improvement, decentralising decision-making, and implementing robust measures for performance and variation. Only through such comprehensive and thoughtful action can we expect to see the significant improvements in innovation, productivity, and team morale that Agile promises.

Please do not wait for the system to change or for external solutions to fix internal problems magically. Take the lead in driving this essential transformation, ensuring your studio is prepared to meet today's challenges and future-proofed against the industry's evolving demands. Let's not settle for temporary fixes; instead, strive for enduring success through systemic improvement.

Deep Dive by NotebookLM

• Flow metrics improve Scrum by replacing subjective estimates with data-driven forecasting, increasing efficiency and adaptability in game development.

• Key flow metrics—Work in Progress, Throughput, and Cycle Time—enhance planning, reduce bottlenecks, and provide real-time insights for better decision-making.

• Integrating flow metrics into Scrum ceremonies streamlines sprint planning, daily stand-ups, reviews, and retrospectives, fostering continuous improvement and transparency.

Clinton Keith's seminal book “Agile Game Development with SCRUM”, published in 2010, introduced a revolutionary approach to project management in game development. This book brought Agile and Scrum methodologies to the forefront for game developers and tailored these practices to meet the industry's unique challenges. Keith's insights provided clear strategies for applying these methods effectively, setting the stage for more dynamic and efficient workflows within game development.

Subscribe now

A decade later, Daniel Vacanti and Will Seele further advanced Scrum project management with their publication, "Flow Metrics for Scrum Teams" (available for free download). This work, built on the foundation of “Actionable Agile Metrics for Predictability: An Introduction”, emphasised the value of flow metrics, traditionally associated with Kanban, in Scrum environments. By focusing on completed work items instead of subjective estimates, these metrics have enhanced productivity measurement, enabled more accurate project forecasting, and streamlined planning. The increased visibility into workflows and real-time data have made Scrum processes more efficient, increased team adaptability, and reduced time spent on estimation debates, leading to more data-driven decision-making and better project outcomes.

Flow metrics are versatile and can be implemented in any process where tasks are initiated and completed, making them invaluable across different methodologies. Their integration into Scrum has extended team capabilities beyond traditional practices, fostering more dynamic and efficient workflows.

The importance of flow metrics in game production is profound. They encourage teams to ask questions early, facilitating swift and informed decision-making. This proactive approach is essential as it shows how our policies influence our data, shaping our strategies and tactics. Moreover, these metrics shift the focus from traditional estimation to a more precise forecasting model, reducing reliance on guesswork and enhancing planning accuracy with actual throughput and cycle time data.

Furthermore, the clear takeaway is that uncertainty is best addressed not through meticulous planning but through action—the tangible progress achieved by doing work. Metrics thus play a crucial role in providing insights and fostering collaboration among team members, enabling a unified approach to tackle challenges and achieve goals. This evolution from estimation to forecasting, driven by flow metrics, significantly boosts the effectiveness of game production practices, ensuring teams are more adaptive, transparent, and successful in their endeavors.

My regular readers know how strongly I advocate for flow metrics, a stance born from extensive firsthand experience. Throughout my career as a game producer utilising Scrum, I've consistently encountered limitations related to estimation and the lack of actionable data. These challenges often meant reacting to issues after the fact rather than addressing them proactively.

Most of my teams used Jira as a repository for tasks and bugs, leveraging only a handful of its native reports. This setup failed to provide the levers needed to impact leading measures or to act on issues as they occurred. Our continual adjustments to Scrum, aimed at extracting more value, yielded mixed results at best.

The turning point came when I discovered the ActionableAgile Analytics Jira plugin (also available as a SaaS product). This tool had a significant impact, finally offering the proactive control I had long sought. With this enhanced toolset, I could effectively implement flow metrics, transforming how we managed projects.

Embracing flow metrics has been one of the most impactful changes in my career. These metrics have filled the gaps we previously tried to plug with ad-hoc Scrum modifications, providing a clear before-and-after contrast in our project management effectiveness. Flow metrics address all these gaps, facilitating a more dynamic and efficient workflow that allows us to act on issues in real time rather than merely reacting to them postmortem.

Benefits of Flow Metrics in Scrum Ceremonies

The primary objective of utilising flow metrics is not merely to collect data but to enable teams to ask pertinent questions at the correct times, thereby enhancing decision-making processes. These metrics provide insightful data that fosters collaboration among team members and stakeholders, ensuring everyone is aligned and informed.

Moreover, flow metrics enhance transparency and provide an objective basis for assessing team performance. This data is invaluable as it offers a clear and factual representation of a team's performance, which is far more reliable than subjective evaluations typically used in many project environments.

Flow metrics can also reduce time consumption, particularly in meetings such as sprint planning. Teams can reduce the time spent on speculative estimation and focus instead on achieving tangible goals. This shift saves time and enhances productivity by centering efforts on actionable objectives rather than predictive guesswork.

Additionally, flow metrics enable teams to move away from traditional and often restrictive measures such as story points. By focusing on elapsed time—including all time during which work is in progress, not just active "touch time"—teams gain a more comprehensive understanding of their cycle times. This holistic view facilitates more accurate planning and process adjustment.

One of the overarching goals of adopting flow metrics is to steer teams away from what is sometimes referred to as "estimation theatre," the practice of placing undue emphasis on estimates that may not accurately reflect actual project dynamics. By focusing on concrete data and real progress, teams can avoid the pitfalls of over-reliance on estimates and instead build processes that genuinely reflect and support their workflow and objectives.

Flow Metrics

Here are the three fundamental flow metrics:

• Work in Progress (WIP): This indicates the number of tasks being worked on. Monitoring WIP helps teams manage their workflow to avoid bottlenecks and maintain a steady flow of work, ensuring that no stage of the process is overwhelmed or underutilised.

• Throughput: This metric measures a team's work within a specific period, such as the number of Product Backlog Items (PBIs) finished per sprint. It provides a historical performance baseline, helping in forecasting and planning.

• Cycle Time: This metric tracks the total time from the start of work on an item until its completion. Focusing on the elapsed time (the total time an item is in the workflow) and touch time (the actual time spent working on the item) gives a comprehensive view of how processes might be streamlined.

In addition to these metrics, we will be exploring these related items:

• Work Item Age: Measures how long a work item has been in the system without completion. It helps identify stuck or delayed items, prompting teams to investigate and address the causes of hold-ups.

• Service Level Expectation (SLE): Based on historical data, this performance metric predicts the probability of completing a task or project within a certain time frame. It is a decision-making tool for determining whether an item should be included in a sprint or needs further refinement.

• Monte Carlo Simulations: Monte Carlo simulations are a statistical technique that uses random sampling to predict the outcomes of a process. In project management, they help forecast task completion rates by analysing historical data, aiding in more accurate planning and risk assessment.

• Right-sizing: A technique of breaking down work items into smaller, manageable pieces that can be completed within a specific timeframe. It improves flow and predictability.

You can read more about Flow Metrics here:

Flow Metrics in Scrum Ceremonies

Below, we break down the use of Flow Metrics for these Scrum ceremonies:

• Sprint Planning

• Daily Scrum

• Sprint Review

• Sprint Retrospective

Sprint Planning

Sprint Planning is crucial for ensuring a successful sprint. By incorporating flow metrics into this phase, teams can ground their planning in data-driven insights, which helps them set realistic goals and expectations.

• Throughput: Historical throughput data can forecast the number of product backlog items (PBIs) that can be completed in a sprint. This approach shifts planning from guesswork to a data-driven strategy.

• Monte Carlo Simulations: These simulations can be applied to predict the completion of PBIs based on historical data, enhancing the accuracy of sprint planning.

• Work Item Age: Analyze the age of items from previous sprints to decide their handling in the current sprint.

• Right-sizing: Discuss and evaluate if a PBI can realistically be completed within a set timeframe, such as 11 days or less, to determine if further splitting or refinement is necessary.

• Service Level Expectation (SLE): Use SLE as a criterion to decide if a PBI should be pulled into the sprint, ensuring that items are feasible to complete as planned.

Daily Scrum

The Daily Scrum is an essential touchpoint for Scrum teams. It serves as a platform for discussing progress and impediments. Integrating flow metrics into this daily meeting enhances focus and drives actionable insights.

• Work Item Age: Highlight and address items that are aging beyond the norm. This can help pinpoint and solve workflow delays.

• Work in Progress (WIP): Monitor the amount of ongoing work to maintain a balanced load that prevents bottlenecks and underutilisation.

• Process Management: Daily scrums are critical for process adjustments; utilise metrics to swarm on delayed items, break tasks down further, or tackle external dependencies.

• Service Level Expectation (SLE): Use SLE triggers to take immediate action on items that are not progressing as expected.

By incorporating these metrics into the daily scrum, teams can proactively manage their workflows, address issues as they arise, and maintain momentum throughout the sprint.

Sprint Review

The Sprint Review is a time to reflect on what was accomplished and what could be improved. This ceremony utilizes flow metrics, which provide concrete data to guide discussions on past performance and future planning.

• Throughput and Cycle Time: Review these metrics to understand the team's delivery rate and discuss improvements. This can assist with future release planning and give stakeholders a clear picture of team performance.

• Monte Carlo Simulations: These are used during reviews to model risk and refine release plans with stakeholders, increasing transparency and confidence in the timelines.

• Flow Metrics in Stakeholder Communication: Employ flow metrics to answer queries about completion times for specific features, enhancing stakeholder communication.

Flow metrics into the sprint review enable teams to present a data-backed view of their work, fostering more informed discussions with stakeholders and better decision-making for future sprints.

Sprint Retrospective

The Sprint Retrospective allows teams to examine and evolve their processes. Flow metrics play a critical role in this ceremony, pinpointing areas for improvement and tracking the impact of changes made.

• Analyzing Metrics: Examine WIP, cycle time, and throughput to identify process improvement opportunities. Look for trends and outliers that suggest areas of concern.

• Evaluating Workflows: Consider adjusting WIP levels and strategies to optimise flow and reduce cycle times, which can help streamline operations.

By focusing on flow metrics during the retrospective, teams can ensure continuous improvement, leading to more efficient and effective Scrum cycles.

Leave a comment

Conclusion

By embracing flow metrics across Scrum events, teams can transition from estimative to empirical practices, enhancing every aspect of project management. This strategic adoption improves current processes and sets a foundation for ongoing improvement, making Scrum teams more adaptive, transparent, and successful.

• A well-structured product roadmap is essential for managing live service games, aligning teams, guiding decisions, and ensuring development stays on track.

• Effective roadmaps prioritise outcomes over outputs, balance short- and long-term goals, and remain flexible to adapt to changing business needs.

• Game producers and product managers must collaborate closely. Producers focus on execution and timelines, while product managers drive strategic vision and feature prioritisation.

Welcome to Production 101. Here is where we dive deep into game production.

Subscribe now

We jump into our series on mastering product roadmaps in game development, drawn from strategies and insights I've accumulated over the years. This series will explore the essentials of effective roadmap management, explicitly tailored to game producers' perspectives.

The first instalment sets the foundation by detailing the critical elements of product roadmaps in live service games, including vision, goals, milestones, and stakeholder collaboration. Understanding these components is key to grasping how roadmaps steer decision-making and monitor progress.

The second part expands on this base by digging into the practical application of these strategies. It discusses advanced techniques and tools for effective roadmap execution, points out common pitfalls, and provides real-world examples of successful management approaches. This section aims to deliver actionable insights and problem-solving strategies to enhance your roadmap effectiveness.

Together, these articles provide a comprehensive view of game producers' dynamic responsibilities, offering strategic guidance and practical advice essential for leading successful product releases. Whether you are just starting or are an experienced professional, this series will enhance your understanding and skills in product roadmap management.

Introduction to Product Roadmaps

Product roadmaps are indispensable for managing live service games. They are strategic tools that align teams, guide decision-making, and track progress. These roadmaps provide a high-level visual plan showcasing the game's vision, objectives, and future direction. They bridge strategy and execution by addressing critical questions such as what the product is, why it is being built, its delivery timeline, and its alignment with business goals.

A well-crafted roadmap outlines the necessary deliverables, explains their importance, and specifies completion timelines. It sets priorities, establishes timelines, and demonstrates how the game supports broader business goals. This communication clarity helps internal teams and external stakeholders stay focused and adaptable to changes.

While product managers typically handle the "why" and "what" of these roadmaps, this post will focus on the "how" and "when" areas that fall under the producer's domain. As a game producer, your involvement in shaping outcomes is pivotal. Yo’ is pivotal. You play a crucial role in setting realistic timelines and managing delivery expectations. Producers can transform roadmaps from static documents into dynamic strategic tools that accelerate game development and LiveOps content delivery by understanding and leveraging these elements.

Key Components of a Product Roadmap

When designing and administering a product roadmap, it's essential to recognise that there are multiple effective ways to represent it. I've discovered that there isn't a single "wrong" way to do it as long as you effectively communicate the essential information.

• Vision and Goals: Articulates the product's overarching purpose and long-term objectives, providing context for all planned features and initiatives.

• Timeline: This specifies timeframes for feature releases, development phases (e.g., MVR, initial release, majority release), or milestones. It can be visualised through timeline charts, Kanban boards, or simple chronological plans.

• Milestones: Represents significant achievements or checkpoints in the product's development journey, helping to track progress and maintain alignment with the product roadmap's goals.

• Features and Initiatives: Lists prioritised features or capabilities that support the product's strategic direction, often grouped into themes or categories to address specific user needs or technical enhancements.

• Dependencies: Identifies tasks or features that must precede others, helping to ensure smooth execution by pinpointing potential bottlenecks early in the development process.

• Stakeholder Collaboration: This approach encourages ongoing input from cross-functional teams and key stakeholders during planning. Regular updates and synchronisation meetings are crucial for refining priorities and adapting to changes.

• Outcomes: This section links initiatives to measurable outcomes, such as user retention rates or revenue growth improvements, ensuring that efforts consistently align with business objectives.

Effectively integrating these components into a product roadmap enables game producers to transform the roadmap from a static document into a dynamic strategic tool that guides and accelerates game development and LiveOps content delivery.

What Makes a Great Product Roadmap?

An excellent product roadmap is more than a to-do list. It’s a strategic tool that guides teams and stakeholders towards meaningful outcomes. When evaluating a roadmap, here are the essential elements to consider:

• Outcomes Over Outputs: A strong roadmap prioritises results over deliverables. It communicates the goals or outcomes behind each initiative, ensuring alignment with players needs and business objectives. This focus keeps the team centred on delivering value rather than merely completing tasks.

• Opportunities and Problem Spaces: A roadmap should define the opportunities and problems it aims to address rather than simply being a simple list of features. Highlighting these areas encourages creative problem-solving and ensures efforts are directed at solving real player challenges, not just building features for the sake of it.

• Balance Between Short-Term and Long-Term Work: A practical roadmap balances immediate deliverables and long-term strategic objectives. Short-term wins sustain momentum, while long-term initiatives drive progress toward bigger goals. Focusing too much on either risks losing sight of timely value or broader aspirations.

• Flexibility: A good roadmap is adaptable. Changing business environments, players needs, and priorities require a roadmap that can be adjusted without derailing progress. Keeping it high-level and focused on priorities rather than granular details ensures it can evolve while maintaining a clear direction.

Including these elements makes a roadmap a strategic, outcome-driven tool that aligns teams, fosters focus, and delivers meaningful results.

Product Roadmap By Audience

Different product roadmaps serve various purposes depending on the audience, product release goals, and level of detail required. Game producers must choose the correct format to communicate priorities and effectively align teams with strategic objectives. Here are the key types of product roadmaps commonly used in game development:

Strategic Roadmap

A high-level view designed for executives and senior stakeholders. This roadmap focuses on overarching business goals, significant milestones, and long-term vision rather than specific features or deadlines.

This is typically created and maintained by the product team with inputs from production.

• Purpose: Aligns the game's development with company objectives.

• Audience: Executives, investors, and leadership teams.

• Timeframe: 12–24 months or longer.

• Format: Simple timelines or goal-driven frameworks, often without fixed dates.

Tactical Roadmap

This more detailed and execution-focused roadmap outlines key development phases, features, and release windows. It balances flexibility with structure, helping teams plan and prioritise efficiently.

• Purpose: Translates strategic goals into actionable development plans.

• Audience: Producers, developers, and cross-functional teams.

• Timeframe: 3–12 months.

• Format: Feature-based layouts, Kanban boards, or quarterly breakdowns.

Feature Roadmap

A roadmap specifically focused on upcoming features and updates. It details planned improvements, their impact, and how they fit into the broader game vision.

• Purpose: Ensures feature development aligns with player needs and business strategy.

• Audience: Designers, engineers, QA, and marketing teams.

• Timeframe: 1–6 months.

• Format: Lists, timelines, or swimlanes organised by feature categories.

LiveOps Roadmap

This roadmap details content updates, events, and monetisation strategies, making it essential for live service games. It ensures a steady flow of engaging content while maintaining game balance and performance.

Unlike other roadmaps, this often requires fixed dates for key items, especially seasonal content and time-limited events, to align with player expectations and marketing efforts.

• Purpose: Supports ongoing player engagement and revenue growth.

• Audience: Community managers, marketing teams, LiveOps teams, and developers.

• Timeframe: 1–12 months, often with flexible scheduling.

• Format: Event-driven timelines or recurring content cycles.

Technology Roadmap

A roadmap focused on technical infrastructure, engine updates, platform transitions, and backend improvements. It ensures the game’s technical foundation evolves to support new features and maintain stability.

• Purpose: Guides long-term tech investments and reduces technical debt.

• Audience: Engineering teams, producers, and technical leadership.

• Timeframe: 6–24 months.

• Format: Layered timelines showing dependencies between systems.

Marketing & Publishing Roadmap

This roadmap aligns with game releases, promotional campaigns, and community engagement efforts, ensuring that marketing efforts complement development milestones.

• Purpose: Synchronises game updates with marketing campaigns and community strategies.

• Audience: Marketing teams, PR, publishers, and social media managers.

• Timeframe: 3–12 months.

• Format: Calendar-based schedules with key messaging milestones.

Choosing the Right Roadmap

No single roadmap fits every need. Successful game producers often maintain multiple versions, tailoring them to different stakeholders while ensuring they stay aligned through a centralised strategy. Balancing clarity, adaptability, and alignment with both short-term execution and long-term vision is key to making roadmaps effective rather than burdensome.

In Part 2, we’ll explore practical strategies for managing multiple roadmaps, synchronising them, and avoiding common pitfalls. These strategies include handling competing priorities, maintaining flexibility, and ensuring roadmaps remain actionable rather than becoming static documents that quickly lose relevance.

Now-Next-Later Product Roadmap Approach

When refining a roadmap process, I frequently utilise the Now-Next-Later format. This approach is beneficial because it can be assembled quickly, and omitting specific dates facilitates negotiations and helps pave a clear path forward.

This format is one of the most straightforward and manageable product roadmap structures to develop and maintain. Additionally, if date commitments involving forecasting are needed, the insights derived from the Now-Next-Later format become a crucial component of that process.

The Now-Next-Later product roadmap was developed as an alternative to traditional timeline-based roadmaps, which often impose rigid deadlines that can restrict the flexibility needed for teams to perform optimally. The emphasis is shifted from deadline-driven tasks to a focus on continuous discovery.

Discovery involves staying attuned to player needs and business opportunities, ensuring that development is directed towards relevant and timely product offerings rather than adhering to an outdated list from previous planning sessions.

In my experience, the flexibility of the Now-Next-Later roadmap is one of its most significant advantages. This format allows for adaptation to shifting business needs and evolving market conditions. In contrast to traditional roadmaps, which can quickly become obsolete due to their inflexibility, the Now-Next-Later roadmap is designed with regular reviews and updates in mind.

The Now-Next-Later product roadmap categorises work into three temporal segments—Now, Next, and Later—arranging tasks from the most immediate to long-term priorities. This structure clarifies the immediate focus and maintains a broader vision, thus aligning each task with overarching business objectives.

This approach is particularly beneficial for product teams aspiring to operate in a lean environment, as it allows adaptability and prioritises spending time on what's most relevant. It provides a framework that:

• Offers flexibility and adaptability in planning.

• Allows for varying degrees of certainty.

• Saves time by focusing efforts on current and near-term needs.

• Ensures alignment with business goals.

• Influences more impactful product decisions by focusing on what's most crucial.

By adopting the Now-Next-Later product roadmap, teams can focus on current challenges with clear, actionable items while keeping future opportunities and innovations in sight. This method supports a forward-thinking product management approach, catering to immediate needs and long-term strategies.

Now-Next-Later With Jira

Implementing a Now-Next-Later roadmap in Jira is a lightweight yet powerful approach that requires no additional plugins. By leveraging Jira’s built-in features, teams can create a dynamic roadmap that enhances product release visibility and decision-making.

Swimlanes provide structured horizontal groupings, enabling teams to categorise tasks precisely across the "Now," "Next," and "Later" stages. Custom JQL queries define these swimlanes, offering a real-time visual representation of strategic priorities that adapt as product releases evolve.

Custom views take this further by allowing teams to refine how issues are sorted, grouped, and coloured. This flexibility helps stakeholders quickly grasp immediate priorities, upcoming initiatives, and longer-term goals. Quick filters and intelligent card displays make navigating complex product releases more intuitive and transparent.

The result is a roadmap that transforms a standard Kanban board into an adaptive communication tool. Without relying on third-party plugins, teams gain a flexible, real-time planning system that bridges the gap between execution and strategic vision.

Strategic and Tactical Product Roadmap Functions

Producers and product managers for live service games play distinct but complementary roles in developing and managing roadmaps. Though their responsibilities overlap somewhat, their primary focuses and scopes differ significantly.

When I first encountered the need to share responsibilities with product managers, I experienced the most friction in product roadmap planning and delivery.

Through a particular conflict, I first recognised the value of a RACI matrix. Understanding who was accountable for the various aspects of the roadmaps allowed me to focus more on my designated areas. However, I admit that letting go of specific controls was challenging.

It is helpful to consider how these positions collaborate daily to clarify the relationship between the overlapping and distinct roles of producers and product managers. While both roles aim to deliver a successful product, their approaches and responsibilities differ significantly.

Producers typically manage the operational aspects of product releaseproduct execution, such as timelines, resources, and team coordination, ensuring that the product manager's vision is realised efficiently. On the other hand, product managers focus more on defining the strategic direction of the product, such as market fit, user engagement, and long-term product evolution.

They determine the "what" and "why" behind the product features, while producers tackle the "how" and "when" to ensure those features are delivered effectively. By understanding these nuanced differences and areas of overlap, both roles can better collaborate, leveraging their unique strengths to enhance product development and drive success.

Producer Responsibilities

• Oversee the "Road to Live" timeline and ensure timely completion of deliverables.

• Focus on milestones, deliverables, and overall project management.

• Manage schedules, budgets, and resources to meet product release milestones.

• Coordinate cross-functional teams to guarantee on-schedule delivery.

Product Manager Responsibilities

• Define the overarching live strategy of the product.

• Drive the product's vision, ensuring it aligns with market trends and innovation.

• Prioritise features that offer the highest value to users and the business.

• Define, track, and respond to KPIs to enhance player experience and boost acquisition, retention, and monetisation metrics.

• Work with business teams to establish clear profit and loss (P&L) strategies.

Key Differences

Strategic vs. Tactical Focus

• Product Managers should adopt a more strategic focus, concentrating on the "why" behind initiatives and the long-term vision of the product.

• Producers: Take a more tactical approach, focusing on the "how" and "when" of product release execution.

Metrics and Performance

• Product Managers: Focus on user-centric and business metrics such as acquisition, retention, and monetisation KPIs.

• Producers: While producers primarily focus on project-based metrics such as timelines, budgets, and resource allocation, they also play a pivotal role in overseeing the technical performance aspects of the game, like load times, frame rates and ANRs. It's important to clarify, however, that while producers monitor these metrics to ensure they meet product standards and objectives, detailed technical management and optimisation are typically handled by technical leads or developers. Producers ensure effective communication and alignment between the development team and other departments, facilitating a comprehensive overview of the product's technical and operational status without delving deeply into the technical specifics themselves.

Stakeholder Management

• Product Managers: Primarily interact with business, marketing, and analytics teams. Due to the nature of product management, there is often communication (and possibly conflict) between the product manager and the design team.

• Producers: Mainly liaise with development teams, licensors, platform holders and external service providers. They are typically accountable for release management.

Roadmap Emphasis

• Product Managers: Prioritise features based on their value to users and the business impact.

• Producers: Focus on milestones and deliverables aligned with product release timelines and release expectations.

Post-Launch Involvement

• Product Managers: Remain heavily involved in post-launch strategy and continuous product evolution.

• Producers: Typically, they transition to support roles or shift to new projects after launch. The exception occurs when they take a proactive role in monitoring and reacting to the technical performance of the live game.

Both roles work closely to ensure the roadmap aligns with strategic goals and practical execution constraints. The product manager generally sets the vision and priorities, while the producer provides a sensible and effectively implemented roadmap.

Leave a comment

Conclusion

In conclusion, the first part of our series on mastering product roadmaps has set a solid foundation by illustrating the critical elements that make roadmaps practical tools for game development. From defining vision and goals to understanding milestones and the importance of stakeholder collaboration, we've covered the strategic facets that enable producers to align product releases with broader business objectives. This understanding not only aids in steering decision-making but also in adapting to the dynamic nature of game development.

As we wrap up this instalment, producers must consider how these roadmap components can be tailored to their products to enhance clarity, focus, and team alignment. These foundational elements are essential for transforming static documents into dynamic tools that drive game development forward.

Please stay tuned for the next part of our series, where we will discuss these strategies' practical applications in more detail. We will explore advanced tools and techniques for implementing effective roadmaps that circumvent common pitfalls and leverage real-world successes to maximise product outcomes.

• Status reports are essential tools for fostering transparency, aligning teams, and making strategic decisions in game production.

• Resistance to status reports can be overcome by keeping them concise, purposeful, and tailored to the audience's needs.

• A Spartan approach with clear templates ensures reports are quick to create, easy to consume, and drive meaningful outcomes.

Welcome to Production 101, your go-to guide for mastering the essentials of being a game producer. In this edition, we dive into status reporting and provide actionable insights to level up your communication game.

Subscribe now

Status reports often get a bad rap but are invaluable when done right. For game producers, they’re more than just paperwork—they’re tools that can drive alignment, clarity, and more intelligent decision-making.

Why Status Reports Matter

A good status report brings everyone to the same page. It fosters transparency, keeping teams and stakeholders informed about progress and challenges. This open communication helps uncover bottlenecks early and identify areas needing attention.

It’s also a powerful planning tool. Whether you’re rebalancing resources or adjusting timelines, having a clear snapshot of the current state allows for strategic tweaks before small problems snowball. It also encourages personal accountability. When team members regularly report on their work, they feel a sense of ownership and commitment to their responsibilities.

When onboarding a new team member, directing them to the status report archive lets them quickly review the team’s recent history and gain context on ongoing challenges and priorities.

Timely, honest, and accurate status reporting is a cornerstone of effective game production. As producers, we have a moral and professional duty to ensure these reports are delivered with integrity and reliability.

The Challenges with Status Reports

Despite these benefits, status reports often face resistance. Some managers struggle to see their value, especially when reports don’t relate to actionable outcomes. Consistency can also be a problem. Submissions can slip or become less meaningful over time without the proper structure or buy-in.

Team members can also feel lukewarm about status reports. For many, they seem like a chore or a low-priority task compared to shipping the next milestone. This perception often stems from reports that are too generic or fail to connect directly to team goals.

How to Make Status Reports Effective

The key to flipping these negative perceptions is making status reports purposeful and easy to consume. Here are some guiding principles:

• Define the Purpose: A status report should answer essential questions for your stakeholders. What’s on track? What’s not? Where do you need support? A vague or overly broad report won’t help anyone.

• Stick to a Cadence: Consistency builds trust. Whether weekly, bi-weekly, or monthly, find a rhythm that fits your project and stick to it. This reduces ambiguity and keeps everyone expecting updates on schedule.

• Tailor the Content: Different audiences care about different things. Stakeholders like execs may want high-level trends, while the development team might need more granular details. Avoid one-size-fits-all reports.

• Make it Readable: A report shouldn’t feel like a novel. Use headers, bullet points, and concise writing to make information skimmable. It’s more likely to be valued when it's quick to read.

• Leverage Your Platforms: Publish them where all the team artefacts are, preferably on a platform like Confluence, where they are keyword searchable. If you are visualising your value streams already, much of the work is done for you, and you need to add context.

• Make it a Living Document: Keep it open on your computer constantly; add things as you encounter them. Then, the final step before publishing is editing rather than recollection and authoring.

• Be Spartan: Being Spartan in status reports means sharing only essential details—clear, concise, and focused on what truly matters. If your report takes more than fifteen minutes a week, you are likely overproducing it, or you do not have the project at the top of your mind, which is another problem altogether.

Production Report Template

Below is an example template I have used for decades at many different studios:

This status report is clean, focused, and ready for quick consumption. Here's what it delivers:

• RAG Dashboard: This is a no-frills snapshot of the team’s health across key areas, comparing the current status to the previous report. Create categories that fit your team’s topology. Have a clear definition of what these statuses mean and what triggers them. Do not abuse Red. That should mean something critical that you need help from above to clear.

• RAG Status Change Summary: This brief section explains any changes in RAG status from week to week to create a connective tissue for the narrative of the status reports when looked at over time.

• Progress This Week: This section highlights the team's wins and completed tasks, giving stakeholders a clear view of what’s been achieved.

• To-Do Next Week: Outline upcoming priorities, keep the team aligned, and show stakeholders the plan for the immediate future.

• Next Milestone(s): Flags significant goals on the horizon, ensuring everyone stays focused on delivery targets.

• New Issues, Risks, and Blockers: This section provides transparency on any new challenges that could impact the project. If nothing is flagged, it’s a reassuring signal.

• Update on Existing Issues: This section tracks ongoing risks or blockers and demonstrates how the team is tackling previous challenges. It provides more connective tissue.

• Important Links: Centralises key documents or tools, saving readers from digging through emails or chat histories.

The Spartan structure is perfect here—minimal fluff, maximum clarity, and all the essentials at one glance. Feel free to use and adapt the template and share it with others.

The Payoff

Done well, status reports inspire confidence. They show that the team is in control, aware of risks, and ready to adapt. They also create a culture of openness, where achievements and challenges are visible and actionable.

So, the next time someone dismisses status reports as pointless, remind them what’s at stake: better communication, more intelligent decisions, and stronger accountability. It’s not about creating reports for its own sake. It’s about setting your team and project up for success.

Leave a comment