Hack:
Understanding Task Scale
Not everything you do can be tracked, but it can be thought of as part of more relatable task-stuctures.
If you are working in development of any kind (here i'm using game development and audio production as an example), 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 can work well, when the team is small, 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, often 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 in using agile methods like scrum there can be a focus on small details, which is where I can find them getting 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 really big picture stuff (product goals and pillars)… 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, sometimes the details, sometimes the big picture - when it should probably really be about neither of these things, but some kind of mid-level...
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/Atomic 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 (or ‘Feature’) 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 ‘Features’ that make up the back of the box, exec summary type-stuff.
The Molecular/Atomic 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 (you might say, too agile) 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, or small collaborative group, 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 (or any other tracking method), 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 Feature/Project Level. This is a PM, or Audio Director / Lead / Exec level perspective and often requires a solid knowledge of where everything is on the object level (depending on your role). When things change on this level, they ripple down to the levels below in a big way, 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.
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.
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.
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. Tasks are something that can sometimes feel easy to get lost inside due to the density and complexity of constantly changing production, recognizing the scale of tasks, and how they are nested can at least give a degree of clarity in communication and understanding.
You need to register in order to submit a comment.