This is Part 2 in a series of posts focused on re-thinking common agile methods and practices within game development.
Part 1 covered some critical contextual differences between games and task-oriented software (referred to here as “applications”) from the perspective of the customer’s experience, and its composition and delivery. We’ll now move on to specific examples of some common agile methods that I see teams struggle with over and over, which are not fit-for-purpose, and risk wasting significant time and creating frustration.
I’ll also outline how to reconsider them, taking us out of the solution space and back into the opportunity space, by re-framing them through their original purposes, the context of games, and modern lean and agile principles. In the spirit of coaching rather than solving, I will avoid prescribing any specific practices, but will provide some potential starting points for thought and inspiration. (If you do want to discuss specific practices, feel free to contact me).
User stories or jobs-to-be-done stories
As a <type of user>, I want <some goal> so that <some benefit or reason>
When <situation>, I want to <motivation>, so I can <expected outcome>
Purpose: Their purpose is to help development teams empathize with/think like their customers, to understand the opportunity or problem space first, and leave the solution space open-ended for exploration and discussion.
Context matters: The format of these inherently assumes something is wanted by the customer to achieve a functional goal, and that it is useful to articulate it as such. In games, we are usually delivering part of a yet-unknown experience for entertainment purposes; this makes the concept of customers wanting something almost irrelevant, other than wanting to be entertained. Imagine the audience of a Netflix series or a VR experience attempting to do this – “As a viewer, I want Ava’s pet hamster to die so that I can feel sad”, or “When I land my cruiser, I want to see Rey fighting stormtroopers so that I can feel excited”; it doesn’t really work. There are a few prevalent exceptions in games – when there are significant themes in player feedback that are being articulated as a want or a request, such as being able to customize something in the game, to see a specific piece of information in the UI, and so on; and when building internal tools and tech for the development team (which is essentially task-oriented software).
Reconsider:
- Explore different ways to capture parts of the larger experience you want the player to have, in a way that is useful for game team conversations. How do you want them to think, feel, or react? Why? For how long? How does this connect to the game’s vision, or other related areas of the game?
- With this critical intention for the player now captured, how can you connect it to potential solutions (features, systems, etc.), and ultimately the work to be done by teams and individuals? Don’t limit capturing this information to a phrase – explore visualizations or combinations of different elements.
- Embrace different approaches for different contexts, such as the type of work, development state of the game, or team communication styles; trying to find a standardized way of capturing this information across an entire game’s effort is antithetical to supporting context.
Flat product backlogs
Purpose: Their purpose is to create a view of the work to be done that provides value to the customer, to clarify and support prioritization of the work, and if working in timeboxes or sprints, to create visibility into what might fit into each.
Context matters: As covered in Part 1, games are typically complex customer experiences, with significant coupling among interactions, agency and optionality for the player, longer throughlines of cohesiveness, and many more visual aspects. Flat backlogs require each team member to mentally map each backlog item into all of that complexity, leading to a lot of coordination overhead, mental overhead and wasted time from misinterpretations. Even in the context of developing applications, flat backlogs have become accepted as a poor artifact for aligning effort; approaches like user story mapping or opportunity backlogs are becoming much more common. To paraphrase Jeff Patton, the creator of story mapping: “If the understanding of our customers and the resulting vision of our product were thought of as a tree, then a flat backlog is like a bag of mulch. Made from its leaves”.
Reconsider:
- Think about how to better-represent the game holistically as a complex experience, and then identify where the general priorities are within it based on what needs to be learned or validated first.
- Worry about the challenge and value of estimating work, planning iterations and releases, priority trade-offs etc. after that. This might mean using multiple complementing artifacts.
- Consider approaches similar to customer journeys, often used by other “complex experience” teams to represent and align their work – those that also contain short and long loops that are interconnected, contain significant customer agency and optionality, and require experiential cohesiveness.
- Look for insights in how this is done outside of software: developing new theme park experiences, immersive theater productions, or innovative museum exhibitions.
Ending sprints/iterations without work-in-progress, slicing work into small “vertical” pieces
Purposes: In simplest terms, iterations are the core of agile, which is to “inspect and adapt”. Practically speaking, having “clean” sprints or iterations can help ensure they are releasable or nearly releasable (i.e. low technical debt), supporting consistent delivery of value over time. Vertical slicing of work supports delivery of value within the iteration itself, further enabling clean iterations, and reducing wasted effort if priorities suddenly change within the iteration.
Context matters: At the heart of these approaches is the concept of delivering value – benefits for the customer, and knowledge for the team – and avoiding waste. However, in games, the role-lopsided work and dependencies across those various roles for delivery result in a wide spectrum of implementation timelines, from a few hours to several weeks, creating a massive challenge to clean iterations. As noted in Part 1, applications are functionally much easier to slice for delivery, both horizontally (between and within experience loops) and vertically (across layers of throughlines). Pushing for vertical slicing in games to create clean sprints can lead to incredible waste over time, especially in areas with significant art or visual considerations (or any throughline that is effort-intensive). Imagine the modeling, rigging, skinning, and art direction re-work (and resulting frustration) of delivering a 3D character across several sprints, with each sprint containing a “vertical slice” of only the currently-highest-priority animations. Or a series of pop-ups delivered one pop-up per sprint at release quality, requiring revision to the art style and layout each time one needs a new type of functionality.
Reconsider:
- Explore what “value” really means, for the players and team, and use that to guide inspecting and adapting – what will actually be put into players hands, or used for learning or making decisions when an inspection point occurs, such as a sprint ending?
- If work is about to be sliced for verticality, will it actually add value at the next inspection point? Or will it create more work or re-work later, regardless of the inspection point?
Fixed-duration iterations or sprints
Purposes: Fixed-length iterations help the team set a predictable cadence and sustainable pace, and understand their “velocity” for planning purposes.
Context matters: Similar to the issues related to clean iterations, slicing work, and single-point estimating (below) – the inherent variation in how the roles collaborate, the lopsidedness of their work, and implementation times all challenge the feasibility and benefits of fixed-length iterations.
Reconsider:
- Explore the pros and cons of a fixed vs. variable cadence, and embrace that it might vary across teams and types of work, based on the concept of value, or the unknowns involved.
Leaving significant ambiguity in the deeper backlog and long-term plans
Purposes: Plans should be open to change as the team learns and the product or service evolves, so planning too far ahead in too much detail can be wasteful (due to the overhead,etc.). By leaving some ambiguity in longer-term plans (the “agile iceberg”), that waste is potentially reduced.
Context matters: Due to the complicated experiential loops with nesting and dependencies in games, and the larger layering of throughlines and delivery stack, the level of long-term ambiguity should be carefully managed in games; not planning far enough ahead can create significantly more waste from rework compared to waste in re-planning. For example, it’s very common to have several lower-priority features that would require a rewrite and rebalancing of a core gameplay mechanic, or require replacing or refreshing gameplay content, creating knock-on effects across many of the experiential layers and loops, in addition to the changes in code.
Reconsider:
- In general, more planning up front needs to be done with regards to the throughlines that are critical to a game’s vision and success, whether that’s art direction, player progression or narrative.
- Invest time in exploring the real effort and potential waste of planning too far ahead vs. the effort and waste of rework, across all roles and game areas, and make informed prioritization decisions. Embrace the fact that the cost of detail vs. ambiguity may vary significantly between them.
Estimating cross-discipline team work with a single number or “size”, and using relative sizing
Purposes: The purposes of this practice are to support teams thinking of commitment collectively, to abstract the effort and complexity required from the individuals doing the work, and to simplify planning while retaining useful accuracy.
Context matters: The highly-varied composition of most work in game development, and potential to be role-lopsided, often makes it uncomfortable for teams to embrace single-value sizing, and unreliable for estimating future work completion. There is also more variance in the effort needed due to the permutations in role combinations and resulting collaboration, communication, dynamics, etc. which can further reduce the usefulness of relative sizing. The analogy often cited in agile circles is a restaurant server using their hands to illustrate size differences between small, medium or large portions of food, but this assumes the food’s composition remains consistent; in games, a more appropriate analogy would be trying to represent the difference between every item on the menu using only your hands. Doesn’t really work.
Reconsider:
- As with most estimating and planning practices, start by understanding the purpose and impact of predictability in delivering work – what actually happens if predictability is off, or isn’t possible? Use this to evaluate whether your approach is meeting its intended purposes, whatever the format may be.
- Embrace the reality that work in games can be very role-specific and role-lopsided, with variance in how the roles collaborate and split up work, even within a team that remains together and stable for long periods of time. Factor this into how the longer-term plans are represented and coordinated – it will probably feel a bit like a jigsaw puzzle, but that’s the reality of the work.
- Note that this approach overlaps with revisiting the practice of using a flat backlog, so consider revisiting both in parallel.
Focusing on “availability” when breaking down what will fit into an iteration or sprint
Purpose: Similar to single-size estimating and “chunking” of work into iterations, the purpose of this is to balance value vs. overhead in planning activities.
Context matters: Agile planning often focuses on the number of available hours from each individual as the primary constraint of what will fit into an iteration, relying on the flexibility and generalism within the team to shift effort organically within the sprint. Quite often in game development, this approach results in team members not digging into their dependencies during planning, and then unknowingly blocking each other, starting un-planned or low-priority work if they become idle, which can waste time and effort in relation to the goals. (Note that this issue depends heavily on the awareness and discipline of the team – some have this problem, and some don’t, but the point here is that it’s rarely a good idea to ignore the dependencies alongside availability.)
Reconsider:
- As with single-size estimating, embrace the fact that game development has work that only certain roles can do, and can be very role-lopsided; some work can be “swarmy” and collaborative, but some work has very clear sequential dependencies and hand-offs. Unpack this during iteration planning, make it highly visible, and use it as a critical lens when working towards the short-term priorities goals.
Burn-down charts to visualize progress
Purpose: The intent is to help teams understand their progress towards their delivery commitment in a sprint, recognize trends, and discuss/adjust as needed.
Context matters: This practice relies significantly on single-size estimation and the generalism of application development, which as noted throughout these posts, is not as relevant to the context of game development.
Reconsider:
- I would recommend avoiding this practice completely, due to the inherent contextual issues. Instead, focus on how teams can consistently surface and discuss progress within their work, from both a delivery standpoint and a player outcomes standpoint.
