The Project

Recently my friend asked if I would be interesting making music for his final year project for his Animation course.

I’m a big believer in building motivation by setting deadlines, especially if you involve a third party. Involving someone else makes the project more than just an internal struggle (which can be constantly postponed). More is on the line such as your reputation and even your relationship with others.

My friend also mentioned it would be showcased at film festivals around the world, which was great as I’ve been trying to get more involved with music production — as well any boosting my public profile

My Approach

When I jumped into the project I had a clear set of paradigms taken from my experience working as a programmer within Agile Development teams.

A lot of the knowledge I’ve obtained programming I consider fairly universal — much like how I think programming can be extremely similar to making music (maybe I’ll write a blog post about this in the future).

These are the three main categories:

1. Staying Healthy

Ambitious projects are well known to cause health issues for people that try to exert more than their body can endure. Not only obvious physical issues (wrist pain, eyestrain), but also mental issues from lack of sleep or poor diet. This is an even bigger struggle when you have to juggle a full time job on the side.

Agile Development doesn’t exactly say anything about health, but it has certain measures such as time boxing and estimations, that shields individuals from unrealistic expectations, which can then consequently cause strain on personal health.

Here is what I focused on with staying healthy:

  • Being conscious of how many hours of sleep I sacrificed, and for what purpose (it’s easy to fall into the trap of thinking you’ll catch up on sleep in the future).
  • Trying to maintain healthy eating habits by ensuring there’s plenty of healthy food at home that doesn’t take too long to prepare.
  • Minimising alcohol consumption. Alcohol can be great for strenuous projects as it can (temporarily) reduce stress. But it the long run I find it decreases energy levels and enthusiasm.

For staying healthy I feel I did well. The biggest challenge was paying attention to the amount of sleep sacrificed and making sure I made it up in the future.

2. Communication

Good communication is essential in any project. Agile Development tries to provide guidelines and facilitate communication by creating meetings such as stand-ups and other reoccurring meetings that have an explicit and clear purpose.

I’m a firm believer that the majority of issues in large projects have bad communication at least partly to blame somewhere in the process. From figuring out vision and requirements, to communicating issues while the project is in progress. Communication is prevalent at almost every step and any unaddressed issues are hard to overcome.

In this project there was the unique problem that my friend was living in New Zealand while I was in Berlin, which caused a ten hour time difference.

Here is what I focused on for communication:

  • Preferring vocal communication over text messages as it’s generally more efficient and less likely that key points will be missed.
  • Communicating often, and not only about the project. Talking about non-project related topics can give context and subtly communicate mood. It’s good to keep in sync, much like how a stand-up does for Agile teams.

For communication I feel like I could have definitely improved. There was an initial conversation over Skype about requirements, but after that the remaining conversation was done over email which introduced a lot of latency and ambiguity. For future projects I would like to place more emphasis on regular conversations with explicit purposes.

3. Providing Consistent Feedback

Arguably one of the best features of Agile Development is the idea that a product is always usable. If priorities shift or resources change, you can still technically publish the product, although likely at a lower quality than desired.

This aspect is great for big projects, as it’s often unsure what the end product will be — or even if there will be enough resources for it. It’s also good for constantly adjusting goals based on feedback, to make sure the end result is similar to what was imagined at the start.

Here is what I focused on for consistent feedback:

  • Sending mixes back for feedback often in order to stay on track and communicate progress.
  • Trying to reach a stable state as early as possible, in order to account for any problems later in the project.
  • Focusing on horizontal slices instead of physical slices ie. everything finished but with average quality, versus the first seconds done perfectly, but the rest unfinished. This makes it continuously ready to release.

For providing consistent feedback I feel it was one of the biggest points I failed on. It made me realise that artistic projects don’t necessarily make sense when you consistently evaluate the status. It’s not until you add ‘that sick bass’ that the rest of the mix makes sense, or that ‘bit of red’ that the painting becomes complete.

Conclusion

I’ve read a lot of criticism about Agile Development recently — and rightly so. Choosing a workflow is one of the core decisions that will influence the way you work and plan throughout a project, so it makes sense to analyse it as much as possible.

Agile Development isn’t the best for every situation, and using it outside of programming, for something more creative definitely highlighted some points where it’s not so useful.

There are also other situations where it isn’t the best tool. Smaller projects, and also bigger ones with clearly defined goals won’t leverage advantages that Agile Development really shines in like adaptability and transparency.

Agile Development doesn’t work for music production, and likely isn’t the best solution for many other creative projects.