I admit I was somewhat skeptical upon my first introduction to the Wonderful World of Agile. At first glance, it seemed like something was off. After all, if it’s that good, why wasn’t everyone using it? After some research, I found out that countless companies were, in fact, using it for a great variety of projects and I decided to give it a go. It took me only a few sprints to realize that:
a) It’s really hard to implement properly
b) It absolutely rocks
But so far I’ve only witnessed its implementation in work-related projects, wondering if I could find a way to benefit from Scrum in my personal life, without focusing on house chores and shopping lists. I’ve decided to dig up my long-dead music-making hobby and try to create a song using Scrum principles and our VivifyScrum tool.
I should also note that I was considering switching to Kanban due to the schizophrenic nature of attempting to be the scrum master, product owner, and the developer, all at the same time. With that being said, Kanban’s focus on a continuous stream of work versus Scrum’s goal of a finished product made me go for Scrum, but stripped of the roles. I did have some amusing daily stand-ups by myself though.
With that out of the way, let’s begin with my retrospective:
Defining the goal
I started off by defining the goal according to the SMART (specific, measurable, attainable, relevant, and time-bound) criteria, this is the brief I ended up going with:
[Artist] - Work Brief
A very nostalgic track, inspired by the Lo-Fi House movement. Slow, groovy percussions and crackling vinyl sounds. Either catchy house chords or very 90s rave leads made entirely on hardware gear. Simple structure, short and sweet. Visuals - some ochre colored shapes.
A nostalgic Lo-Fi House track
- A completed track within a one-week sprint
- Roughly 4 minutes long
- Using fresh samples, either bought or recorded
- Typical Lo-Fi House structure
- At least 4 hours of work daily
- Using Scrum Method and VivifyScrum to track progress
- Sprint Retrospective
I set to allocate at least 4 hours every day for this project, including weekends, leaving me with roughly 28 hours to complete it. Being an optimist and a terrible estimator, I believed this was the minimum time I could invest daily, when in fact, it became the absolute maximum. The difference between using Scrum at work and in personal life is that in former you’re struggling to fit everything into the workday schedule, while the latter has you guessing whether you’ll even be able to show up that day. Nevertheless, sticking to the planned schedule was crucial in order to see how far I could push myself, as well as to plan future (much longer) sprints.
With that in mind, I began creating stories that would go into the sprint, from seemingly smallest tasks to critical no-brainers such as “record the track”. Surprisingly, having the entire process in one place wasn’t as daunting as I feared and gave me a nice overview to form a clear schedule of what to tackle each day.
These were my stories:
With 7 days in front of me, I decided to tackle them by categories: first I’d make sure everything is connected and working properly (leaving that until the last minute hasn’t been a good practice in the past). Then I’d move onto organizing the projects and compiling all the required assets to create the tracks. Then finally I’d start creating the tracks on the hardware until finally recording, arranging, mixing and mastering them within the software.
So in a perfect scenario, my sprint would look like this:
|Create clean projects and manage their sound libraries|
|Test the hardware/software sync|
|Record and import new drum samples into the project|
|Analog leads synthesis|
|Day 4||Hardware pattern programming|
|Record all separate tracks|
|Track arrangement (whatever is left to do)|
|Publishing the track|
In reality, no such perfect scenario occurred, and I felt more frustrated and under pressure than in my whole (non-music) career. With that being said, I only felt that way due to the badly estimated time constraints I’ve given myself and the fact I had at all points a perfect overview of what else needed to be done and was being postponed due to my inefficient tackling of the problem at hand.
Things I’m not proud of
Unforeseen technical difficulties
Although I prioritized hardware sync as one of the first stories to tackle, I wasn’t prepared for the chaos where my hardware decided they weren’t going to operate with one another, especially with software in the picture. A quick fix would be to shell out 500$ for an external sync device, or simply record both machines separately and adjust their tracks manually, which as you may guess took away a lot of my studio time.
You’d think that mistakes learned from at work would be easily avoided in personal endeavors, yet somehow I ran into the same problem of overestimating my competence. The optimist in me didn’t acknowledge any possibility of a writer’s block that would result in me carrying “Day 3” stories throughout days 5 and 6, resulting in much sloppier recordings and in turn, mix/master of the track.
Things I’m (somewhat) proud of
It’s a finished product
Which is something I can’t say for 90% of my tracks, still floating in some creative limbo. I’m not too happy with the product, but the truth is that I most likely wouldn’t be even with a whole month of rework and polish. However, given a similar project, I’d determine a much more precise timeframe of delivery and be better prepared.
Even as someone who revels in creative chaos, I needed to introduce some structure into my hobby as it felt like I was losing touch with so many unfinished sketches, it was overwhelming. I didn’t know if Scrum would do the job, however, as I perceived the hobby as an immeasurable, elusive process - one where you can strike gold with a sudden quirky idea or bash your head against the wall for a week without any good results.
Now, doing it according to the Scrum method not only provides you with a bird's-eye view of the project’s state at all times but, with enough sprints, should give you a clearer idea of your abilities and limits, making planning for and accomplishing goals much easier.
I’d say that Scrum works for music just as well as it does for any other creative endeavor - exceptionally well. But the struggle doesn’t come from trying a new workflow as much as it does from the fact that you will fail your first sprint. No matter what your standards are, you will fail by some criteria, but as cliché, as it may sound, it is the learning from your failures that will guarantee a better sprint each and every time. This means a better, smoother sprint and a better product at the end of it.