From Waterfall (Environments) to Agile (Warriors)

An audio guy learns to work more effectively in a modern development environment

Looking back on time spent with Blade Symphony the aspect where my process changed the most, where I learnt the most, is in regards to adapting to agile development styles from my more waterfall-centric methods.

The Waterfall

I come from a film background. I prefer to work in a conservative production style even within film. My work processes before Blade Symphony would begin by figuring out the fine details of the finished product in the first stages of pre-production. By the time pre-production really got underway the finished product would be decided upon, documented and approved. From there everything moves like clockwork to get the finished product in the correct formats on time and on budget. I'd get the final product on paper and define what was needed to make that product.

How the Waterfall Worked Within an Agile Team

My work process when I started with Puny Human looked like this:

Define Required Changes

What that means is that I will define what needed doing (eg. 'we need footfall on glass sound'). Here I decided how present or important the sound needs to be in the soundscape. This will be tested and iterated upon - but I'd make a call as a starting point here. The main question I'd ask myself is this: "does the game event triggering the sound contain important gameplay information for the player?".

Plan Changes

Here I'd think about how I would actually make the sound asset (gathering materials for a Foley recording session for example) and how I'll implement the sound (which affects how the assets are made). I'd consider how many variations I might need and whether I'd make variations using the game engine or game variables or simply create distinct sound assets. Any implementation challenges might get highlighted here and I'd talk to a programmer / artist / animator about any issues that might come up. I'd plan my recording session or gather assets from sound libraries.

Action Changes

By now all that is left to do is to follow the plan I designed in the previous step. One of the most fantastic things about this process is that because I've gathered all the resources and planned everything out I get to experiment and 'play' with the ingredients a little bit. Usually I'll try and get all the baseline material down in a recording session first and then use any spare time for trying out crazy ideas.

Mixing and mastering the sounds leaves me with some finished sound assets ready to hook into the game with some clever scripting.

Test & Analyse Changes

Here I'll test, by myself or with a tester or fellow developer if required, to make sure everything works and that the work done satisfactorily 'solves' the reason for the work. Almost always it will fail in some way and move back to step one asking "why or how did it fail?", "what needs to change?" or "what new information do I have on how to (or how NOT to) 'solve' the 'problem'?".

Typically I would follow this cycle at least three times and often over twenty times. Sometimes starting from scratch and sometimes making small tweaks.

Once I was satisfied in the testing phase that I had 'solved' the 'problem' defined I would upload the changes to SVN and, typically, collapse for a moment.

Problems With This Method

So what kind of problems came about because of this method? One of the most frustrating elements is that almost all of my work and troubleshooting was invisible to the team. They also felt disconnected from the work I was doing. From their perspective I'd say I was working on stuff for a while and then make an SVN commit. Often I'd receive feedback from the team suggesting I try something that I did ten or twenty iterations ago and I'd often forget or not know how to clearly communicate why that idea failed (or that it just sounded 'bad', as subjective as that might be).

The other issue is that this process represents a real big chunk of work and time. Sometimes I'd commit only to find that I'd misinterpreted the brief, or what my colleagues thought they wanted they now realised was not so great, it doesn't work how it did in their heads. I would then take feedback and go through this hole huge process again; sometimes feeling a little demoralised.

The method I described above created excellent work - both aesthetically and technically. Unfortunately it is a very individualist approach; it systematically made it difficult for me to collaborate well. It also resulted in stunted flexibility as input for change was available at disparate points in the cycle of getting the work done.

A More Collaborative and Agile Approach

As we near Blade Symphony 1.0 and got ready to launch had I settled on a much better method of working; one that enabled myself and the team to work and communicate more closely. Feedback was opened up, and the workflow was faster. To me it felt reckless; but the team get what they want and faster. The process is basically to chuck something that might work in the build and then work out, together, what works about it and what doesn't and put something else in the build that maintains the strengths and addresses the issues. It looks something like this:

It really seems obvious to me right now but it was honestly difficult to let go and allow my co-workers to see what I would consider my first drafts. One of the obvious advantages is that ideas the team dislike or ones that are not working are thrown out sooner. I had to let go of some control and trust that through iteration we would arrive somewhere great.

Communication is Key

When you want something to sound powerful what image comes to your mind? I think of a gigantic waterfall. Or a volcano. Or a big cat roar. Or… Well, already, I have gone from liquid to mineral to animal and I could list more things that sound 'powerful'. This demonstrates one of the difficulties of communicating, in abstracts, about sound. We solve this with reference material. It is imperative that we use something concrete and outside of lingual semantics. Most of the time the perfect reference does not exist. So we need to use references as signposts that help us navigate discussion rather than material to emulate. Another thing I would do is consider what my colleagues were asking for and very quickly throw some ideas on a timeline. This would give us examples to speak about, we can use the different examples as signposts for discussion. An example of some of the videos can be found here:

The quick iteration methodology also does take some foresight and a little bullheadedness when someone is convinced a solution is the right one and simply needs some polish or a implementation change in order to get right. In these cases trust and communication among the developers is essential. Outstanding results are far more likely to be achieved when there is a clear definable objective for the audio of the project; this allows a framework for decision making and assessing ideas as well as aiding in the cohesion of the the project aesthetics.

I hope this little write up may assist other developers transitioning from traditional development styles to Agile methodologies faster and with more confidence.