RPM Challenge: The Workflow Experience

When I started to consider participating in this year’s RPM Challenge, I already had a pretty effortless way in mind to do that, using proven-in-use approaches.

Prepare gear setup for a MoinSound Studio Session the evening of January 31st. Play the session starting exactly at midnight into February 1st. Play for exactly 35 minutes. Take the recording and upload it. Enjoy the rest of February.

I decided not to follow this approach.

Personal Goals

I didn’t participate in the RPM Challenge to do a POC for the approach described above, and definitely not to set a new speed record, the latter mainly because speed has never been a good KPI in music.

(Know those world’s fastest guitarist/drummer/whatnot titles? How often do you listen to their music, instead of putting on something with, say, Hendrix, Towner, DeJohnette or so? Exactly.)

My goal was to try a few things that, for various reasons, never made it into a project/endeavour of mine that got the attention of an album production (and thus, those ideas never led to anything).

Like “why don’t I try something with field recordings”? “I absolutely should use those powerful sampler instruments more”! “Ambient might be a genre worth looking into”. “There’s so many unused but cool hardware effects boxes…”. Add to that unused/underused (and definitely underprogrammed) hardware synths, and you have the key musical ingredients of Neue Sachen aus dem Notenbüchlein für coole Instrumente.

So a regular album, with novel things content-wise at that. Only to be done in a maximum of twenty-eight days.

Considering how long I goof around with my usual albums, that is indeed a challenge. I needed to do something with regard to such hip things like workflow. Or methodology. Or whatever you may call it.

Weekend Sprints, Workday Ownership

As a person with a standard day job, the part of the week to get a lot done in a limited amount of time is the weekend. On the other hand, anything that requires to revisit things, sleep over them etc. is best placed during work days, as there’s a limited productive time from the project’s POV available anyway.

Notenbüchlein 180218
Product ideas

Furthermore, with all roles being held by one and the same person (i.e. me), it takes longer, but organization gets easier.

Applying the ideas from the SCRUM methodology, you could then have sprints over the weekends, sprint planning right before that/review right afterwards, and storywriting/product backlog maintenance during the week. In other words, the artist (applying his skills in multiple personality disorder) is a product owner during the week, a SCRUM master and multiple development team members during the weekend, and all of these roles right before and after the weekend.

A period of 28 days has always exactly four full weekends in it. So four sprints it is. And with that, we have an organizational approach of weekend sprints and workday ownership.

Product
Product backlog

With February 1st being a Thursday, there wasn’t a lot of stories/log items in place for the first sprint, and there wasn’t the organizational idea I’m now explaining to you in place, so the first weekend was really goofing around and collecting ideas for epics.

However, in time for the second weekend, I had enough ideas documented, knew how to tackle them, and was able to create one or two shippable products (in that context, track-like audio file things I could upload somewhere).

This approach continued for the remaining time – reviews after the weekends, working out details for backlog items during the week, and implementing them in the weekends.

Backlog
Sprint backlog

Similar to a software development workflow, the number of products was only finalized near the end: the full log contained 16 products, yet the final album only had six tracks on it: it was round the time for planning the last sprint that I found that I either could add another product to realize the album concept I had had in mind for some time, or reduce risk and decide to get the album without that track done really well.

So how did it work?

First of all, the approach made it possible to keep track on the product ownership level without committing to anything too early. After all, the hard requirement was to have 35 minutes (or then tracks) worth of unreleased material – and with the approach to have shipable products at the end of each weekend per track, I could already announce compliance on February 18th.

Another positive aspect was that all of those things that didn’t make it onto the final album were left in a well-documented state – which means they could go very well into another project, even sometime into the faraway future.

Is there an Agile Record Production Future?

The big question for me is: can I work this way on all (or some) of my future projects? Is SCRUM (or an agile methodology in general) the way to go for music (album) production?

Well, why not?

In a typical setup, music is not a product with long lead times (like mechanical engineering where a grey-cast piece will set you back tens of weeks), so having that idea of a shipable product at the end of each sprint is perfectly sensible, at least if we take the mastering stage out of this.

Also, the typical organization is the right size to have one development team for, say, a standard music ensemble, and practically always if we consider the development team only to consist of the “creatives” (which may or may not include a lead engineer, but will not include a full symphonic orchestra with choir).

The assumption that requirements will change while progress is made does very often apply – you’re working on an album, and while one track idea turns out to be crap, another one might just come to your mind. Still, the idea to build the album from individual products and at a given release date ship whatever set of products is available may not be the best if you’re Richard Wagner or Karlheinz Stockhausen – but will most probably work for most other artists.

I still haven’t fully worked out how to map the typical roles in both disciplines – which for me isn’t a problem because I’m mostly doing a one-man-show with the occasional helper.

The question remains how the roles of product owner and SCRUM master are assigned. Is the product owner the artist (if it’s one person) or the head of the ensemble (if it’s an ensemble), and the producer the SCRUM master? Which would mean the lead artist is both product owner and development team member. Or does the role of the product owner fall to the executive producer (which would put him into a very art-related position)? Producer as product owner and a production consultant as SCRUM master? This might be the best approach; the fact that the music industry doesn’t work like this should not keep us from doing it just this way.

Even with that open question, following an agile approach for one of my next projects is however a promising idea.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s