A lot of game developers have found that the software development methodology of Scrum doesn’t work for them. In some ways I agree but this article is an attempt to show the other side; how we’ve found scrum works for us.

Game development and iterative development should be synonymous really, and Indie Game development more so. Anyone beyond their first game project will know this is true – what seems like a good idea in your head or on paper will absolutely be different from the game you ship whether that be due to technical limitations, mechanics that become boring after a while or, in a lot of cases just good old scope creep/design evolution will cause a game to change a lot from its original concept to final realisation. 

My adapted Agile Manifesto to suit my context as a Game Developer:

• Great team culture and communication over prescribed processes and tools
  That is, we agree on what is needed and how we will go about achieving it in a way that works for all team members
• Game development over Comprehensive Documentation
  That is, we have a shared understanding of how the game should work and have a process for identifying and documenting important features for future ease
• Player feedback over Following the Design
  Regularly engage players and iterate design and implementation based on feedback
• Embrace change over Following the Design
  Actively seek out opportunities that challenge your design

So I hope I can safely say that Agile (the overarching practice that encompasses methodologies like Scrum, Kanban and Crystal) suits the game development environment, but what about Scrum in particular?

Scrum is built for small teams that include all necessary skill sets to get the work assigned to the team complete (your cross-functional team). As one of the more prescriptive of the Agile frameworks, Scrum outlines five meetings or events within a containing event (the “Sprint”) built to encourage and routinify empiricism and Lean thinking (or Inspect and Adapt and Focus on the Essential/Reduce Waste mentalities). These meetings take about 10% of an average 40 hour work week and this is where a lot of people immediately start feeling concerned; that’s a month a year spent on meetings! 

My argument from ten years of watching game development teams that have these meetings and don’t is that teams that do (and especially if they have good facilitation/meeting focus) ship faster. Shared understanding and removal of barriers between team members provides coordinated focus, enables quality problem solving and reduces team stress. It feels clunky and unproductive at first, real clunky. Practise though and some facilitation makes these meetings a valuable use of time for all team members and your game.

The next area where Scrum turns off a lot of Game Developers is the “All in a Sprint” mentality where the Sprint Goal is started and everything is worked on from start to finish within that 1-4 week period. Scrum detractors say that this just doesn’t work for game development – either half the team is productive for half the sprint or you have sprint goals that elevate one area of the game development cycle over another e.g. if the sprint goal was to have Product UI for the main game screen implemented you’re leaving out the whole design and art aspect that has come before. I totally agree with this criticism of Scrum-for-game-dev. Throw out the traditional idea of a Sprint Goal for game development imo but still have a shared understanding within the team of what you’re aiming the game to look like or have at the end of the sprint.

See the thing I like about Scrum is it has a lot of rules because you’re supposed to throw out the things that don’t work for your context, or the prescriptions you’ve outgrown. You can also add tools as things change – a definition of done is probably more valuable when artists, programmers and testers need to remember each production build should run at 60fps on all platforms rather than when you’re just prototyping ideas.

Diving a bit deeper into these meetings I want to lay out why I think they work (or why I think they work for us at the very least) and the three that I think (in my infinite wisdom?) every team should regularly employ in one way or another.

Product Backlog Refinement:

Previously known as the Product Grooming Session this is the only meeting of the four that’s focus isn’t on the items of the sprint; rather it’s where you look ahead. This isn’t a Design meeting per-se, rather its a technical design meeting — how will you know this mechanic, feature or visual has been created or implemented as intended? Regularly reviewing the technical implementation of upcoming features will help you identify dependencies that have to be worked on before this one, potential problems that might arise in development (is there research needed?), and how you will test the feature including potential debug commands that would be helpful. The Product Backlog Refinement meeting is the implementation of the “gate at the top of the cliff vs the ambulance at the bottom” adage – when developing any product the earlier you spot a defect or the quicker it is to test the faster (and therefore cheaper) your development cycle.

We spend ~1 hour per week in Product Refinement, though expect to spend more time at the start of production than the end.

Daily Standup:

This is a set time each day where you coordinate with each other. Obviously lots of smaller studios are basically working in each other’s laps and it’s hard to see why this meeting would be necessary or valuable, but I think it affords us a few benefits: 

• It’s a good time to raise things that aren’t urgent enough to interrupt people with throughout the day but still need to be addressed / remind people of an issue that was found the previous day but doesn’t have a resolution yet.
• To coordinate your day – does someone need a build before x or someone else needs some of y’s time?

Having your stand up around your Sprint’s task board also keeps the team on-track and accountable to each other which helps strengthen your team culture. 

We spend ~5-15 minutes a day for our Stand up. It helps that our team all start pretty early in the morning and knowing you have Stand up at 8:30am is an easy way to plan out your day. We humans are pretty good with routines after all.

Sprint Retrospective

This is an action that, as you become more and more comfortable with Scrum and your Team, you start doing constantly throughout your sprint rather than just at the end; inspecting how you’re working together to achieve the tasks at hand and working out how to make it better.

Having a set time at the end of each Sprint where you can reflect on what has gone well and what felt like it could’ve gone better is such a valuable exercise, although if your team are looking at it as a “bitch fest” then they might have the wrong idea about it all. The goal of this meeting is to determine a couple of changes that the team should make in the next sprint in order to improve the process of developing the project together. Those changes may or may not work but you’ll review that at your next retrospective!

We spend ~30 minutes every two weeks for our Retrospective, although allow for an hour in case there’s more discussion to be had. Currently the theme of our Retros is “What is worrying me the most?” so we can work on a maximum of three improvements per sprint that also have the benefit of reducing stress within the team itself. Examples of a concern might be “I feel like I should know more about what the player will do in this game”, a potential solution to that is to book in some dedicated time where the team can talk through and confirm designs until you no longer feel you need that time anymore. 

It’s not Scrum, it’s you.

I have yet to hear a story about a team that was implementing Scrum in the spirit it is supposed to be approached in and still found it wasn’t benefiting them. The Teams I see upset and frustrated by Scrum unfortunately haven’t committed to the forms or are failing to adapt Scrum to their individual context – obsessing over the “strict rules” rather than embracing a framework that supports iterative development and player feedback while [if you’re doing it right] continually strengthening your team and facilitating the development of a healthy and supportive team culture. If you don’t think Scrum suits a game development environment, then I reckon you’re doing it wrong!

Hei konā mai! For more information about utilising Scrum as a game development methodology check out Mountain Goat Software’s and Agile Guru Mike Cohn’s presentation here, or to discuss more /  try and change Nadia’s opinion hit us up on our Discord or Twitter!

Images by Fox from Pexels and Michael Osmenda from Flickr