Having survived long crunch periods that have become somewhat notorious for the video game industry, I’d like to tip my imaginary hat to Scrum. The last game I’ve worked on probably wouldn’t be delivered on time if it wasn’t for the Agile method and the sheer will of the team to adhere to it.
You see, as much as we’d like to talk about the perfectly measurable positive effects of Scrum on project development, it’s an entirely different beast when it comes to the game industry and carrying it out was daunting.
And although I quit the industry shortly after that to join VivifyScrum, let me tell you why switching to this framework might be the best decision if your team is struggling. Here are some Scrum-oriented solutions for your everyday game dev problems.
Problem: lack of communication between departments
This could be one of those obstacles that are entirely unique to the video game industry, and it revolves around much more intricate production pipelines - each department delivering a relatively small aspect of the game: 2D and 3D artists, assemblers, programmers, game and narrative designers, as well as producers, all working simultaneously to create the final product.
In the perfect world, all of the departments/teams would be in perfect sync, with everybody perfectly aware of each project’s status and how far along each team is, thus always aware of the next goal. There also would be no crunch, sudden layoffs or shoehorned microtransactions.
Of course, the bigger the company is, the worse the communication between all the department gets. This is amplified if we introduce team-specific tunnel visions, derived from each individual immersed in their craft, thus elevating the importance of their pipeline segment above all.
In the best case scenario, this results in teams working out of sync - waiting for others to complete their goal in order to start theirs. In the worst case, this results in delivering a subpar product due to being completely detached from the project.
Solution: a cross-functional team
This won’t work with large companies’ pipelines but can do wonders for any small-medium dev team, especially indie. The departments/teams can be split and reordered into cross-functional teams, with a member or two from each division, all responsible for one single game or project. This does not only promote openness and learning among the colleagues but also accountability and commitment towards delivering the best possible project.
Problem: lack of communication within the team
With a new cross-functional team assembled, everything seems to be more in sync, but you still run into the problem of team members simply not communicating with each other. There is no team spirit and things are done at half the speed and quarter of enthusiasm. This setup may function as a quick fix but won’t leave you with a great playable product in the long run.
Solution: Scrum events
One of the most important features that Scrum cannot be executed without are events - an absolute necessity for the team to be in sync, and for the tasks themselves to be understood and executed as well as possible. These are Sprint Planning, Daily Scrum, Backlog Refinement, Sprint Review and Sprint Retrospective. This, by far, has had the most positive influence on our project.
All of these events focus on bringing the team members together to discuss the project in various level of detail. For instance, during the Sprint Planning, all of the members go through the entirety of the project’s backlog and decide which crucial features they’ll tackle in the following week or (preferably) two.
Once these are set, the Sprint begins, during which each member takes on the responsibility to finish their tasks on time. On the other hand, the Daily Scrum serves as a micro-conference during which the team briefly discuss what tasks they are working on and the obstacles they’ve encountered.
To you, these may sound like activities your team likely already participates in, but give Daily Scrum a shot and you’ll be amazed by how much more informed you’ll all be by the end of the week. Not only that, but giving your colleagues the crucial time to reflect upon each other’s progress, achievements and impediments will unite you and evoke a more symbiotic approach to problem-solving.
In addition to inspiring the team to discuss their own task-related issues, this will also will give everyone an opportunity to discuss their vision of the project. There is nothing worse than having unmotivated members giving their minimum to achieve gameplay features they never had a voice in. By giving them the platform, you enable your project to flow and grow into something everyone is satisfied with internally.
Problem: market changes
This might just be the worst case scenario during a development cycle, especially since it’s out of our hand. You've been working on your game for a while now when, suddenly, you realize that the market has shifted into a different direction - one you’re not covering with your game, either due to the genre becoming oversaturated, outdated gameplay mechanics, or an identical narrative theme in a game released just a week ago.
Good games take ages to develop and especially in this day and age where the market is booming with new franchises, chances of this happening are growing steadily and the (frankly) outdated waterfall system doesn’t account for it. Your product is either met with dislike or indifference.
Solution: incremental development
One of the core philosophies of Agile is to always work on incremental or iterative builds, meaning each successive version of your game builds upon previously implemented features.
Let’s say you’re working on a rogue-like RPG, more precisely on your playable character’s (PC) special abilities, which we’ll refer to as Feature A, Feature B and Feature C. In your previous sprint, you’ve set the groundwork for them, leaving them at Feature A 1.0, Feature B 1.0 and Feature C 1.0 and are rebalancing or fleshing them out for versions 1.1. However, bad news come in, as you see an open beta for an eerily similar RPG game with almost identical features.
You begin to worry about having to explain your career choices during the next Thanksgiving, but suddenly remember that you’re agile and can adapt your entire gameplay mechanics in order to stand out from (or at least beside) the direct competition.
For your next Sprint, your 1.2 versions will undergo a major change and perhaps won’t even be related to the PC, but his NPC companion while you come up with new abilities. This can only be done because you’re not too far into the development cycle and can easily backtrack. You haven’t drawn a gorgeous, hyperrealistic nose, only to realise you can’t put a face on it, instead, you’re constantly improving a very rough sketch until it reaches the satisfactory level to be considered done.
Working in small increments gives you the right environment to properly assess your product at any given time, as well be prepared for any sudden market changes or unexpected competitors.
Problem: boring Concept Proposal (CP)
You’ve been a game designer for a while now. You’ve worked on your concept proposal for countless days and nights, and believe you have it all figured out. The core gameplay loop seems fun, the special features are unprecedented and you’ve even compiled enough lore for an entire trilogy.
Sadly, nobody seems to care.
Even worse, everyone you ask calls out different parts of your CP, making it impossible to pinpoint the exact issue and what could have been your first AAA game slips into oblivion.
Solution: usability testing
Just like with the previous solution, you don’t want to define the entirety of your game and pitch it all at once. At that point, modifying or excluding even the smallest elements may break the entire concept.
Write out the concept in a paragraph or less and pitch it to the one person you trust and can profile based on their taste. Then scale it out some more and pitch it to a small group. Write down their reactions and begin elaborating on your pitch while dealing with the issues that have been pointed out. After that, start throwing in mechanics, creating a playable vertical slice and always keep testing.
Not only should you be able to create a more concise pitch with small increments, but (and this is a big deal) you’ll also get a better picture of your target audience and niche, enabling you to start creating real user stories based on the information you obtained about their profiles and tastes.
Having Sci-Fi Simon criticize your high fantasy game may not be a big deal, but if Medieval Mandy says it’s too boring, this should raise some flags.
Keep in mind that none of these suggestions are prescriptive. They simply describe the issues I’ve encountered and ways they may be overcome. Scrum is a framework to make you more invested, motivated and honest, above all to yourself, about your creative process. Depending on your situation, these solutions may or may not work for you, but hopefully, you’ll decide for yourself through sheer experimentation.