“Towers. Open Fire.” – Burroughs
I’ve been meaning to post on an, admittedly experimental, method of Agile Development that i’ve been working with for the last few years, but have never quite got around to documenting. It’s not for everyone, but then neither is Agile. I want to see if anyone else is working with and attempting to formalize adaptive iterative methods like this, and secondly I want to see if there are audio designers or directors who are working with Agile methods in a more ‘by the book’ manner and finding them to be successful. Writing (and re-writing!) this post has led me to some quite deep pondering on the Agile process and how to re-think it specifically for audio, and i’ve come to the conclusion (for now) that by thinking about tasks differently, by scaling them, you can have structure, trackability and freedom. My guess is that most audio folks work this way anyway, though perhaps think of it in different terms.
Obviously different teams and cultures, different software products have different interpretations of Agile development techniques and implement them differently based on what works well for that particular team. I’ve always found the by-the-book Scrum and Kanban techniques to be dry and process-driven, where the most important thing always seems to be following the rules of the game, rather than working collaboratively and openly in more informal discussion groups.
Kanban seemed like a better philosophical approach, and more geared towards open collaborative x-discipline game development, however i’ve found both to be relatively short-sighted and not have enough focus on ‘the big picture’. There is also a big question of who is running the show, the scrum master, or PM, or game director, can often wield quite a lot of power simply by cutting user-strories based on priority, rather than a collective gut-feel for if something is truly worth doing or not. This is I guess why these methods work well for more structured, incremental software development, and perhaps not so well to the awkward, uneven and chaotic world of game development.
This brings me specifically to audio in an agile world, you may suddenly find yourself in the following situation, without much planning or thought about the approach… Let’s say we have a large team. From my own experience, this usually looks like this: There is the team, broken down into cells, all doing their daily morning stand-ups. As an audio team, or even a single audio resource on a project, there is instantly a problem here when several cells are meeting at the same time, and the audio resources are spread so thinly as to not be able to show up in the different cells. Shift the timing of the cell meetings to be able to accommodate, and you have the problem of being in meetings all morning. These morning stand-ups DO work well, when the team is small, meaning around 10 – 15 people, so that a single morning stand-up can happen and audio can be at the table to update and be updated without cell meeting burnout. One of the things you quickly learn is to keep these things short, entertaining and meaningful. So, audio updates tend to be just that, maybe without the entertaining and meaningful parts, but, we do our best. So why does this work better at the small team level? On larger teams the ways in which different members of the audio department work within a cell may be quite different, and may even vary at different times during production. Some may choose to detail all their work down to the smallest element, while others may simply work with broad strokes at a higher level. I find agile methods like scrum tend to focus most heavily in on the small details, which is where I can find them dry and tedious, and I guess the part I like least, is that I tend to see teams and groups getting ‘lost in the details’. By the same token, they also tend to ‘leave out’ the bigger picture stuff… so I’ve always been trying to find a way of simultaneously having a good handle on both. Scrums, for me at least, can often feel like something is missing in terms of focus.
Perhaps now is a also good moment to take a step back from looking at the problems of that ‘scrum daily standup’ moment, to think about what is going on from a higher structural level. I should mention the actual scheduling process. This is critical in determining when the team, and when audio, will be allowed to be ‘agile’ and when they have to morph into a beast of delivery and rigidity. I’ve found that working backwards from a ship date to be the absolute best way of knowing where you are and where you should be right now. Milestones are still very necessary and meaningful from an audio viewpoint, perhaps one of the few barometers for where the entire project needs to be. Audio, being last in the production dependency baton-race will typically indicate where things need to be complete by, and by scheduling things like a final mix, or a sound beta and sound alpha period, all the relevant ground spikes are hammered into the schedule and you can begin to build up a pretty decent skeleton of where things need to be and by when.
Certain audio tasks may not appear to be very compatible with agile methodology at all, at least not in the widely accepted ways they are done inside most development studios. Dialogue production, for one example, has a myriad of dependencies and conditions that need to be met at various milestone: narrative script, cut-scene script, AI script writing, filename and productions script preparation, casting, booking, placeholder recording, implementing, recording, editing, implementing, reviews, re-writes, re-records, re-edits, mastering, mixing – these dependencies are so waterfall-like that it is almost impossible to see where agile development can fit into that process once it gets started. It kind of lives outside that whole ‘fast iteration’ cycle – even more difficult with mo-cap. Writing tends to be agile, as it turns in tandem with the twists of the game design – but once you get into the solidified waters of the ‘script’ things gets locked down pretty tight. One small, but significant area where I have found fast iteration can be applied to dialogue is during the actual session, where actors can improvise and provide re-writes on the fly. This is not agile development, but straight up improv within the confines of the ‘dialogue line’ or ‘event’. This is a philosophy you have to be prepared for and ready to embrace, but it can be awesome and create some really compelling performances. So, in that tiny ‘dialogue recording’ window, you have an opportunity to be agile. (As an aside, I think the further we can get away from actors ‘reading scripts’ in video games, and get to the place where they ‘learn lines and improv scenes’ the performances will ‘read’ as much more compelling by the audiences – iterative and improv based dialogue session are one way to do this, but the window of opportunity to capture this is very small – precisely because it is one of the only periods of freedom inside an industrialized waterfall production process).
So, dialogue production is not really something that plays nice with a by-the-book agile methodology. It would be awesome if it could, and there were systems whereby actors could always be available to come in and instantly change content on a weekly basis, but it is so industrial a process, that this is probably not something we’ll see for a while, certainly less likely at the A3 end of development.
Music production, similarly can be a process of either industrial production based on several iterative stages of pre-production sketches to delivering finished pieces mission by mission, milestone by milestone, feedback being provided at various stages and then having them enter a brief post-production phase (of mixing and mastering), or it can be a more ongoing iterative process for smaller titles with less music – the ongoing iterative process here can produce music of finished quality at almost the beginning of the process, and constantly change throughout production right up until the end. The methods of working, and the production pipelines implied by different styles of music (electronic over orchestral for example) largely determine the process and agility inside that process – so then, here agility and iteration times are influenced more by chosen production style, than by a team’s desired way of working. But, as with dialogue, these kinds of productions are likely to include periods, or levels, of both agile and waterfall.
Depending on the scale of production, and here is where I finally get into my idea of a different way of thinking about and scheduling agile tasks, items such as ‘music production’ and ‘sound effects production’, at the highest level, are often better represented on a schedule by several very long-term time boxes. Essentially these huge time-boxes are large spaces of time dedicated entirely to producing and iterating on content until time either runs out, or a part of the process feels finished. The advantages of these ‘large, broad iteration cycles’ (or timeboxes) are many. They simplify the audio production task definitions for non-audio PMs and other disciplines. They show clearly where the agile tasks rigidify into drop-dead delivery dates (so we don’t open the audio up to endless noodling when the clock is running out). They also free up the producers of this content to iterate and experiment with these broad categories in their own way, at their own pace, they can procrastinate, knuckle-down, explore new ideas, essentially have complete ownership over those areas of the game sound. Part of this is to never have anything in the game as ‘final’ or ‘finished’ until the final mix. This leaves flexibility and honesty in the schedule and also allows big decisions to be made at the final mix (where very often sounds are replaced based on new unforeseen contexts that have arisen late in development) and major stakeholders are present for the audio sign-off.
I’ve broken this down elsewhere, but as an audio lead, my high-level audio schedules usually consist of two kinds of tasks. Long-term iterative tasks, and short term tasks. Short term tasks may be things like developing specific audio features for the game on the programmer side, or those waterfall tasks described for dialogue above such as ‘casting’ and ‘recording’. Long-term iterative tasks are those ongoing areas that will always be changing as development trundles along, yet they remain as high-level as possible in terms of description, purely to allow the PMs and scrum tasks to have insight without worrying about every single piece of minutiae about the work.
A SOLUTION: TASK SCALE
So, there is a difference here that needs to be addressed, and that is one of TASK SCALE.
I’ve found a useful way of thinking about tasks, and resolution of tasks, is as a kind of atomic scale, like zooming in on that photo in Bladerunner. I reckon there are (at least) three useful levels at which to consider tasks…
1) The Molecular Level (The detailed / nitty gritty /individual wave files, event triggers, volume and pitch attenuations, all the tweaking-knob-twiddling detail of any particular task, the smallest components)
2) The Object Level, the level at which you can give things names that other disciplines can relate to – weapon x, music cue y, location z.
3) The Project Level, as described above, the large high-level PM way to look at and break down tasks, music, ambience, prop effects, UI sound, mix – big things that you can talk about holistically.
The Molecular Level task is not something that I think works well at being tracked at all, so I don’t think this really works with Agile methods, it is too granular and is always the kind of stuff that people who start a discussion about need to usually take ‘off-line’ and collaborate together on elsewhere. This is a level of detail that I hinted at earlier as being something that an individual has ownership over and autonomy over – but the ability to ‘scale up’ and be able to talk about and update on those details at the Object level IS important…
The Object Level. This is a category of tasks that I believe can be tracked nicely with Agile methodology, and lends itself well to x-discipline group exposure. Discussions are tangible and not too technical, details can be figured out offline, and progress can be tracked e.g. ‘The sound for 10 weapon classes is on schedule for the end of the week’, ‘the music cues for missions x, y and z are now implemented and ready for feedback/testing’.
The Project Level. This is a PM, or Audio Director / Lead level perspective and requires a solid knowledge of where everything is on the object level. When things change on this level, they ripple down to the levels below via either extra polish time, additional levels, objects or animations, or reduced scope.
All these TASK levels related to one another, but depending on another SCALE, the scale of production, the amount of sound resources required to do this effectively changes a lot.
There are two ways a project and its resources can be scaled. A project can either have DEPTH, or BREADTH.
A Racing genre game with very few tracks, but with a massive amount of vehicle types, could be considered a game with shallow feature sets and DEEP content. A third-person linear adventure game, with lots of variety in the different locations and player activities throughout the experience (I’m thinking Uncharted, Arkham Asylum etc) could be said to be game with a BREADTH of features and content, but only one or two DEEP mechanics. An open world game such as GTA, Assassin’s Creed or Saints Row could be said to have both BREADTH (tons of features like driving, shooting, hand-to-hand combat, navigation) and DEPTH (tons of variety in vehicles, weapons, mission types and locations). A mobile title such as Angry Birds or Candy Crush would by contrast have comparatively shallow Depth and Breadth. (There is also the factor of TIME, which for now, I am not considering, but will make a large impact on the amount of sound personnel required).
This is where sound personnel matters a lot, and how they are organized to handle TASK SCALE levels becomes important. An open world title might require several sound designers and implementers with ownership over several broad areas of the game, all handling both Molecular and Object Level tasks and require an Audio Lead to monitor and connect that team to the Project Level Tasks. In a small mobile game studio, one person may be handling all of the task levels themselves.
Attacking a project on all of these levels is kind of what I mean by “Attack on All Fronts”. When a painter or sculptor works, the way they often work is a quick and meditative (subconscious) interplay between the molecular level detail and the big picture level detail, going back and forth very quickly and rapidly iterating using the material they work with. This is how working on a mobile title can feel when you are a single person audio department. The object level completely disappears and there feels like little need to track anything, or communicate anything because the work is so fluid. This can lead to problems in communication, and obviously game development is very different to painting in that there is a team involved in the creation process. For larger teams, that middle step of thinking about the Object Level tasks becomes a pivotal part of the process, where high-level and detail level thinking can interface and I believe in that level is one of the best places, and most collaborative places to discuss the project. Sometimes it is easy to loose sight of the process and the levels of tasks and responsibility…
At certain points in full production, for long long periods, we often find ourselves simply attacking stuff. As it gets added, we attack it. As it changes, our sounds become out of date, and we attack it. This is a full-frontal assault on all aspects of the game from all angles, weapons, hud, foley, ambience, music, voice, UI – that ongoing, iterative approach can become a fog of a war that is “Attacking on All Fronts”. This can be a long period of iteration, and I think it can be crucial in producing good work, provided that relationship between personnel and task scale is maintained. Through iteration, the more something changes, the better it gets, sometimes it gets worse before it gets better, and sometimes it just gets cut. In almost all cases, it is better for the project. Up at the Project level it is an incredibly open and deliberately anti-detail process. This allows you to attack the project in clever ways, via scope for example. If you have ownership over weapons and UI at the Object level, then your long-term tasks, for the entirety of production is to attack those areas as they change on the x-discipline level. The freedom in how to approach that iteration lives at the Molecular level. Molecular level scope is also left totally open and free for that person running that section. In the end, a focus on the end user at all levels provides the incentive for ways to either add to or remove from the work required (Removal of sound is a huge area of sound design and iteration, and not one that you’d instantly think of as being something you’d schedule for. Its almost like scheduling anti-work). Attack on all fronts at all task levels is closer to the process of a painter slowly building up paint on a canvass, or a sculptor working constantly on a sculpture, the feedback is very instant and as things change, the overall ‘work’ begins to form. It changes as it forms and it is important that it is the big picture that is tracked, as much as the details.
Up at the Project Level, these long-term tasks will eventually turn into short-term polish tasks, or post production tasks, whereby they are pre-mixed, finalized and everything starts to solidify and get ready for the final mix. As long as these dates are clear, I find you can work in a totally flexible and free manner until you need to switch gears.
Once post-production, or sound alpha, or sound beta is reached (terminology differs here between developers). The Attack on All Fronts approach continues, but it moves into a different gear. Polish and removal. Removal, again, is as big a part of the iterative process, particularly in terms of Object Level areas like weapons, but when all these different areas come together and are presented in context with one another, a new level of removal needs to take place. This is where things again really get focussed on the player, and the end user experience. Any clutter or sound that is getting in the way of the experience is removed, or diminished, or mixed in such a way that the experience becomes more honed and focussed. This is essentially the job of the final mix, but also a process of sound effects replacement, premixing, polish, cutting, all informed by a period of intense scrutiny and reviews takes the foreground.
Defining the periods of rigidity and the periods of agility at the Project Level seems to be very important in being able to both control and let go of the game development process for audio. To deliver and also to maintain a degree of freedom and opportunity inside of various tasks feels important. I think that most tasks, even those as rigid and industrial as dialogue production can be broken up into short-term and long-term tasks: with corresponding levels of freedom, experimentation, detail and overview.
Big picture tracking is a fairly difficult thing to quantify and relate to, it is based on constant review and constant iteration and is based a great deal on a ‘feel’ for when something is right in x-disicipline context, rather than just running out of time (although that can put an end to the process too) or being buried in checking small tasks off a checklist. The structures i’ve tried to pin down here are ways of having STUCTURE via the Schedule and tasks at the Project Level, TRACKABILITY at the Object Level and FREEDOM via the open nature of tasks at the Molecular Level.
As already stated, game development projects tend to be very uneven and even ‘chaotic’. I like some of the agile systems as loose frameworks for certain kinds of tasks and for inter-departmental awareness and communication. Finding a balance that works for the project, culture and personnel you have often means a lot of mixing and matching, and a high degree of seeing whatever does and doesn’t work. But I think one step towards that is understanding this notion of identifying task scale, which is something that can sometimes feel easy to get lost inside due to the complexity and constantly changing elements of production.