This post is for the game studios and teams that have “gone agile” (or are considering it) yet feel that something is a bit off: writing user stories feels awkward, sprints end with a lot of work-in-progress, or no one can agree who should be the product owner. Underneath it all, there is this awareness that friction and frustration within the team is building up, time is being wasted, and opportunities are being missed, but it may be unclear how to improve; it’s like shifting to a higher gear but not feeling the torque you expected.
How did we get here?
Over the last decade or so, the game development industry has made a big shift towards agile methods like Scrum and kanban, and with good reason. Working in a “waterfall” way had become frustrating. Gantt-charting everything in advance became recognized as delusional (reality never matched the plan), full-project plans were hard to maintain and didn’t reflect the collaboration that happens in a team (or worse, it promoted siloed perspectives among the different roles), and it didn’t support the creation of an engaging game; it was all about coordinating to delivery features on time rather than outcomes for the players.
In comparison, frameworks like Scrum seemed like a breath of fresh air. They prompted teams to inspect and adapt frequently, which would result in more useful planning, and it created opportunities to focus on outcomes, i.e. evaluate the game itself between sprints. It also emphasized collaboration and shared goals over each roles’ delivery of their part of a feature, which sounded great!
However, I still see the majority of game teams struggle with the popular agile practices, and in many cases, double-down on the practices in response to the struggle. They focus on writing the perfect user story, or slicing their features into smaller pieces, or getting better at planning poker. It reminds me of the waterfall-era mentality of “Our original plan was really different than what actually happened during development – we’ll need to plan everything more thoroughly at the start of the next project!”. I also see game teams use agile methods as a reason to avoid thinking or planning beyond a few sprints of work. And many teams also continue to use it primarily as a way to manage output; how often do you see outcomes like player feedback and behavior shown at the end of a scrum board, or visible in planning, instead of “velocity”?
So how can we do better?
It’s time to take a big step back, and recognize the context in which agile principles and practices solidified in software development, and where most of the practices, literature and advice is still coming from today: task-oriented or “functional” software development, where customers have a problem that needs solving, or are trying to “get something done”. (To avoid writing that phrase out over and over, I’m going to simply refer to them as “applications” from here on out.)
The general assumption is that because games are driven by code, they should be viewed as software, so prominent agile software methods are applicable – this is a sort of “bottom-up” view of the game as a product. However, the customers’ motivations, experience and expectations are almost entirely different in games – this is the “top-down” view of things. Taking it a step further, we can see that games actually contain just as much non-code as code – this is an “inside-out” view of the game.
Let’s merge those views and take a look across the differences, to see how context really matters. One caveat here – this view is a generalization across games and applications; in reality, each has its own sub-contexts and there are products that blur the lines a bit, such as games with very little complexity, or mobile apps with “gamification” aspects added.
Experience segmentation
- Applications tend to have short, decoupled experience loops inside of the larger experience, lasting a few seconds or minutes. In Spotify, you can find and play a song, build or organize a playlist, see what your friends listen to, and change your settings, but they don’t rely on each other very much (which then enables “slicing” of that functionality during development). These loops are often simplified and streamlined further as the software evolves, to reduce friction and time spent inside the actual application; think 1-click or single-swipe actions, notifications, auto-complete and other shortcuts.
- Games tend to have long experiential loops that range from seconds (player actions) to minutes or hours (levels or zones) to days (live events) or even months (seasons) which are usually nested together and tightly coupled. In contrast to applications, the “slicing” of work becomes significantly more complicated.
Experience cohesiveness
- Due to those short and decoupled loops, applications have very few “throughlines” (some use the term “horizontal aspects”) that require cohesiveness along the entire experience, other than consistency in UI style and usability, and brand considerations like tone and messaging. If there is a longer line of interactions, it’s typically the wider relationship with the brand or service, not just the product/software experience.
- By comparison, games have many additional “throughlines” requiring cohesiveness within themselves and also across each other: aspects like level or world progression, difficulty progressions and player skill growth over time, progression of character abilities, ongoing narratives, art direction and evolving visual themes, economy progression, etc.
Validation of their purpose / value
- Applications have a focus on helping customers achieve functional goals, so validation of their response and behavior is more straightforward – their need is met or not, and in a cumbersome or efficient way. Observing them using the product and asking them clarifying questions can elicit a lot of insights.
- Games focus on engaging intrinsic motivators and emotions, so evaluation/validation of their customer value is much tougher. A feature or key moment may trigger opposing reactions in different players, or be difficult for players to separate from the entirety of the experience, or be difficult for them to articulate.
Delivery flow
- Applications have a relatively small “delivery stack” of roles needed to go from ideation to deployment into the wild (i.e. DevOps): product design, engineering (sometimes of varying expertise areas), UI designers, and QA; the efforts of the last two are significantly reduced by usability and UI standards, and automated testing.
- In games, there is typically a much larger “delivery stack” of roles with little to no overlap in skills and capabilities: engineers, game designers, artists, many of which are often sub-specialized, along with exploratory QA which is very difficult or time-consuming to mitigate through automated testing. This makes team planning, alignment and delivery activities much more complicated.
Evolution of delivery
- Applications have tech stacks that are enabling more and more generalism in engineering, and extremely rapid deployment. They abstract specialist knowledge needed through APIs, and automate a lot of standard functionality. These stacks are evolving very rapidly simply because of how widespread software development is, and the increasing shift towards open-source development and sharing of solutions.
- Games have tech stacks that are a mixture of general solutions like game engines with authoring pipelines, plus custom-made tech and tooling to fit the specific needs of each game. This makes it challenging to make broadly-useful improvements in the solutions available, and forces teams to make constant return-on-time evaluations and trade-offs – do they invest more in tech to save time later and speed up delivery, or continue to “do things manually”? For which roles? Which areas of the game? The tech stack evolutions are also moving more slowly than those for application development, due to the smaller size of the game development industry and reluctance to shift towards open-source (given all of the above, it’s no surprise that any tech to speed up delivery is seen as a competitive advantage!)
So what does it mean for trying to be agile in games? Is it hopeless?
Absolutely not! In the next post in this series, we will dive into common agile methods and practices that should be re-evaluated or even avoided, and how to develop better approaches based on their original purposes, current agile and lean principles, and the key context points outlined above.
