Disclaimer

Applying a concrete process to a creative endeavor is highly dependent on personal style and goals. I want to share the below experience because it really helped me out, but by no means is this the "right" way to do things. Just potentially useful for some people, some of the time.

Context

I recently joined a Data Analytics team at my workplace. The team had begun to implement a Scrum framework into the way they planned and executed work; coming from a previous team that had been using traditional waterfall-type project management, the concepts of Agile and Scrum were a very welcome change for me. The flexibility offered by this framework was responsive to a fast-paced business that required frequent change. After working with it for a month or so and getting a feel for its strengths, I started to realise that these principles could apply to a problem in my personal life: I had been struggling to finish any new music projects since becoming a father.

Key Points

First, a quick overview of the key strengths that Agile and Scrum brought for me:

1. Frequent Delivery: finish valuable “products” in two-week intervals (a “Sprint”). This helped me build momentum by having tangible milestones I could achieve on a continuous basis.
2. Prioritization and Focus: do the important work first and limit work in progress based on previous experience. This helped me manage a schedule with very limited time to work on music (30-45 minutes per day on average, 1-1.5 hours on a good day).
3. Time-Boxing: do as much work as possible in a constrained time frame, then move on. This helped me ensure I could finish tracks, since realistically they could be worked endlessly.

If any of those advantages speak to you (musically or otherwise), read on! Otherwise this framework might not be immediately useful. But feel free to keep reading.

Scrum

Next, a little bit more about Scrum for those unfamiliar. It is a framework building on Agile principles that is designed to help teams build and sustain complex products. The framework is available freely at https://scrumguides.org/. It is designed to be flexible and lightweight, and in particular, continuously adapting based on the needs of the team. Briefly, it comprises three roles, five events, and three artifacts - wording paraphrased from the Scrum Guide:

• Roles:
• Product Owner: The (single) person responsible for maximizing the value of the Scrum team.
• Development Team: The professionals who deliver the work each “Sprint”.
• Scrum Master: The person responsible for promoting and supporting Scrum.
• Events:
• The Sprint: A time-boxed period where a potentially releasable product is created.
• Sprint Planning: Lays out what can be delivered next Sprint, and how it will be achieved.
• Daily Scrum: A daily 15-minute meeting for the Development Team to understand progress in the last 24 hours and plan the next 24 hours.
• Sprint Review: Held at the end of a Sprint to inspect the work done and adapt to progress and feedback.
• Sprint Retrospective: Held between Sprint Review and Planning for the Scrum team to inspect itself and plan improvements.
• Artifacts:
• Product Backlog: An ordered list of everything known to be needed for the product.
• Sprint Backlog: The Product Backlog items selected for a Sprint.
• Increment: Sum of all that is done for a Sprint and previous Sprints; must be in a usable condition and pass the team’s definition of done.

Why Scrum?

Most people do a double-take when I mention the idea of using Scrum for a creative process; so, right off the bat, let's get the weird stuff out of the way:

• I was a team of one, and I had to fill every role needed in Scrum (keep myself focused and cohesive, do the work, and interface with the customer).
• I was both the primary customer and the Scrum team (so I was working for myself).
• I didn't formally hold most of the events (even though I sometimes talk to myself - that would have gotten very zany).
• I was writing music, not developing software.

One or more of those bullets is what usually led to a confusion about why I would try to use Scrum - it just doesn't seem to fit my work. But what happens if we flip our thinking and take a look at the problems I was facing?

• I had very little free time to work on this.
• I had difficulty staying motivated after short initial bursts.
• I was jumping between 3 or 4 different album ideas.
• I was leaving many tracks half done for too long and losing their thread.
• I only had 2 new tracks of my own to listen to in the 2.5 years since my last album release.

So, on the one hand, there are some valid points about my setup that would be seen as incompatible with Scrum; on the other, I was faced with problems that Scrum could be of immense help with solving. Plus, by its nature, Scrum is meant to be flexible…

My Implementation

I will lead by saying that my team dynamics and personnel were a given for this project - I did not need to choose or find a Product Owner, or a Scrum Master, or figure out how to best handle interaction with the customer. I just had to be honest with myself about how much work I could manage in a Sprint, and judge for myself if I liked listening to my music. My music may not be for everyone, but I sincerely enjoy and listen to the tracks I wrote for this album - in fact, I am listening to them as I write this out!

Most software or advice about implementing Agile ways of working, most commonly Scrum or Kanban, have a lot of material on the Product Backlog. This is because, when executing a complex task, we usually need a bit more structure to what we are doing. For example, I had ideas for multiple albums, which would have each consisted of several tracks, which would have each consisted of several key steps to undertake, which would have each consisted of several small tasks to complete. Taking all of that into a single list would have made it unwieldy, so I put some structure around it. In particular:

1. The highest level was Album ideas.
2. The next level was tracks.
3. The next level consisted of complete passes through a track. These were the Sprint-level items that would result in something “usable” (listenable).
4. The last level consisted of day-to-day tasks.

The most important question that I had to answer was: what do I, the customer, consider to be usable? For me, once I have a full track structure containing some core motifs, I can listen to it and keep ideas flowing - no matter how rough or basic it is. That is what I used to define a “usable” increment, and allowed me to build and maintain momentum through this process. I suppose that the second level to the hierarchy was not strictly necessary, but who doesn’t love checking big things off of a to-do list? (Or in Agile terms, moving them to the “Done” column...)

I must also stress: the lists of items in each of these categories was ranked. For example,  despite multiple album ideas, I had to pick my top idea - and focus. This is a hard thing to do, since that meant leaving my other ideas alone for a while. But the reality is that my team did not have capacity for more work than that; without the discipline to say “no” or “not yet” to my lower-ranked work, I would have risked not finishing anything at all. This is probably the strongest overlap I had to my professional Scrum work: it can be really hard to say “no” or “not yet” to a possible client, or to a manager; but having too much work on the go means that all of it will suffer.

Finally, Sprint length: if it is too long, work may go off in the wrong direction for too long, or momentum might be lost; if it is too short, meaningful work cannot be completed. Based on knowing my team’s work capacity (i.e. my own work capacity), and knowing what the customer (i.e. me) considered useful, I settled on a 2-week Sprint. That 2 week length had the added bonus of grace for having a bad week; I have weeks here or there that don’t allow for much time to spend on my creative endeavours - yay for being a responsible adult - but that generally doesn’t happen for two weeks in a row.

Results

In the end, I managed to finish and release a 12 track, 58 minute-long album; all but one and a half tracks were fully done using the Scrum framework. From beginning this journey to releasing the album, I had eight 2-week Sprints. It has given me something that I can enjoy personally for a long time to come, and something I can share with others - including my family, both old and new. I plan to happily continue my use of the Agile mindset in my future personal (and professional!) work; it has yet to steer me wrong.

I hope that there are some helpful nuggets in this article, whether or not you are convinced about using Agile or Scrum; I am happy to follow-up on any questions through comments or direct messaging.

Final Note: I am currently in the process of posting all 12 tracks here on Newgrounds.