TL;DR My band had problems, so we put in place some methods that fixed them. I’ll tell you about what those problems were, how these methods addressed them, and how you can apply them to your problems, too.

The start of 2016 was a rough time for my band, Golden Idols. Just as we had started to gain momentum in the Seattle music scene, our drummer quit. We had felt it coming. We were getting stagnant in the creative process: not finishing songs or releasing any new material. We were bickering all the time about what direction to take the band. As soon as we finally replaced our drummer and felt like we were getting back on track, our lead guitarist also quit.

In contrast, the second half of 2016 has been huge for us. Some of our best writing has happened. We recorded a full length album. We ran a successful Kickstarter pre-order campaign to release that album to vinyl, which was 185% funded. We’ve been getting more offers from bookers to open for nationally touring acts. We’ve created a handful of videos. And we all love each other so much that we end each practice with a group hug and call each other “babe” all the time.

The happy family with our band mascot, Bam. Photo by Michael Good.

What was the catalyst for all this change? We created a system for managing our band based on Agile practices commonly used in software development.

Recognizing the Issues

In order to make positive changes in any organization, you need to first recognize the problems you are facing. At the start of 2016, we had quite a few.

Turnover: 2016 wasn’t the first time we had to replace our drummer and lead guitarist. Turnover is a huge problem for any band starting out as you work out how committed everyone is to the project. It’s incredibly time consuming to replace members. You have to take time off of playing out and it can kill your momentum. We wanted to make sure that the next people that joined the band were really committed. Unorganized communication: Working within a hybrid system of text message, Facebook group, email, and in-person communication a lot of information got lost or missed. Some members preferred one method of communication over another so they’d check messages but ignore the Facebook group. This meant that important communications had to go through multiple channels to make sure everyone saw it. Lack of consensus: The previous problem of communication difficulties fed into a feeling of a lack of consensus. Those of us who were checking all the channels knew what was going on but other members missed important info or were left out of decisions because they never replied. One person doing all the work: Our lead singer Patrick does the bulk of the songwriting in the band. For some, that made the band feel more like “Patrick’s Band” than “Our Band”. When that’s the dynamic you have, it’s hard to get people to take the lead on a task or project, even if they’d be better suited to tackle it, because they don’t feel as invested. Nothing got finished: Patrick and the rest of the band all came up with great ideas, but without others helping out and making sure things were getting done, most projects fizzled out when Patrick or I lost interest or hit a block.

When you boil all of this down, the major issue was a lack of buy-in from the other band members. While most would attribute this to not having the right chemistry as a band, not having a system in place that allowed us to recognize and address these issues exasperated the problem.

The Methods

Around the time that our current lineup was solidified, I started a new position at Tableau Software as a product manager. As my team was new to working with each other, we went through an Agile workshop to help jumpstart the team, get buy in on the mission, and figure out how we wanted to work with each other. After seeing the success of that in my professional life, I thought we could apply the same techniques to the band. With all of the current lineup working in tech in some capacity, they were open to trying it.

The Kick-Off Meeting

The start of our agile journey was a kick-off meeting. Everyone came over to my house and we wrote on sticky notes what we wanted to know by the end of the meeting. We put them on the wall, grouped together similar ones, and voted on what order we wanted to tackle things in. We ended up with three main objectives for the meeting:

Align our goals as a band Figure out what our “working agreements” would be Build up and prioritize the things we wanted to accomplish.

One of the first things you should do as a team is figure out a mission. What are you trying to accomplish? What does success look like to you? For us, that was talking about long term goals. We were all basically in agreement with what the purpose of the band was for each of us. We decided we wanted to work towards a place where our passion could fund itself and we could tour. We also learned that no one was planning on quitting their day job, unless the band became profitable enough to not have to change our lifestyles. Making sure we were all at the same level of commitment was crucial.

Setting our working agreements ended up directly addressing a few of the aforementioned issues about communication. For example, Patrick is an early bird and we often received texts at 7am asking a question that could’ve waited until everyone was fully awake.

We came up with processes of how decisions should be made. We chose what tools we were going to use. We also gave everyone an area that they’d be in charge of and making sure things happened there.

Patrick would be responsible for the creative pursuits of songwriting and video making.

I would use my years of marketing experience on managing our social media accounts and networking.

Saba, who I’ve heard referred to before as ‘The King of Seattle Gear Swap”, would be in charge of equipment and facilities.

Eric, the most technically minded of us, would maintain the website, email automation, and any other technical tools we were using.

The bulk of our kickoff meeting was spent thinking about all of those half-finished projects, pie in the sky ideas, and ignored maintenance issues and figuring out what we needed to complete them. We immediately saw that the roles we came up with were validated because each member focused on creating tasks in their area of focus. That list of tasks became our backlog.

The Backlog

Our Trello board

The central component to our Agile practice as a band moving forward from the kickoff meeting is the backlog. One way to manage a backlog is to use kanban. To manage our kanban board, we use Trello, an awesome free app that allows teams to all work off the same backlog. On our board, we created five columns that tasks flow through:

Ideas: These are things that we think we might want to do sometime but haven’t fully committed to.

These are things that we think we might want to do sometime but haven’t fully committed to. Planned: Once we decide that we really want to make an idea happen, we move it to the planned column. Ideally, this column should be prioritized so that when we have the bandwidth to take on a new task, we take it off the top of the list.

Once we decide that we really want to make an idea happen, we move it to the planned column. Ideally, this column should be prioritized so that when we have the bandwidth to take on a new task, we take it off the top of the list. Doing: These are things that someone in the band is currently working on. Teams will often define a limit to how much in progress work a teammate is allowed to have (for example, a max of 2 tasks). This ensures that people don’t move on and start something new without really finishing one of their tasks.

These are things that someone in the band is currently working on. Teams will often define a limit to how much in progress work a teammate is allowed to have (for example, a max of 2 tasks). This ensures that people don’t move on and start something new without really finishing one of their tasks. Blocked: If we are waiting for something, say the masters for our album or an email from the booker, we move it to blocked. This shows that there’s nothing we can do here until we get what we need, in which case, we’ll move it back to Doing.

If we are waiting for something, say the masters for our album or an email from the booker, we move it to blocked. This shows that there’s nothing we can do here until we get what we need, in which case, we’ll move it back to Doing. Completed: While it might seem pointless to keep all your completed tasks around, it allows you to see everything you’ve accomplished recently, which is a great morale booster for the whole band. It also keeps all the information that went into making the decisions around that task in case you need it in the future.

Each task flows through these columns, allowing you to track your work and what everyone is up to. This helps solve a lot of the issues around people feeling out of the loop on certain things. In Trello, each task can include checklists, file/image uploads, and comments. That way all the discussion for a specific task can have a central location instead of being spread across our group texts, Facebook group, and email.

An example of a task making use of all the things you can add to a task.

Standup Meetings

Having a backlog is really helpful for facilitating a conversation but you also need a venue for that conversation. In an Agile methodology, this is often called a “standup meeting” because it should aim to be quick and efficient enough that people don’t need to sit down for it. Daily meetings seemed pretty overkill, so we went for holding these chats at every band practice or trying to have a quick group call if practice was cancelled. Whenever our tiny practice space gets too hot or someone needs a smoke break, we head outside and go down the list of what people are working on and where they are in the process. This is also a time to discuss any blocking issues that may be able to be resolved at practice, e.g. if we need someone’s track for a demo or opinion on something.

Knowing these meetings will happen allows us to save non time-sensitive decisions and discussions for practice, eliminating the need for extraneous communication outside of that. Using the backlog to drive these discussions meant that things weren’t forgotten or missed.

Retrospectives

A huge plus of our Agile process is its flexibility. If something isn’t working for you, you should have a process to change it. That’s the point of a retrospective meeting. For scrum teams, this would come at the end of a “sprint”, a set time period of work. That doesn’t make as much sense for a band, so we decided to do these after performances or when completing a big project, like our Kickstarter.

To track our thoughts for these meetings, we use a tool called Scatterspoke, which works great for holding these kinds of meetings when you can’t all be in the room. It also allows for some anonymity so that people feel more free to fully speak their mind and voice any concerns.

Retrospectives also serve as a time to celebrate everything you accomplished and what went well. For us, it’s also a time to eat a ton of ribs.

The Results

Whenever I see someone I haven’t talked to in a while, they have the same comment. “Man, it seems like Golden Idols is killing it right now! You are doing a lot!” Part of this is because I’ve somewhat honed our social media strategy using data, but the bulk of the credit goes to the band’s active participation in these methods. We are getting more done than ever at a higher quality than we thought possible. We’ve settled into a system that works for us now. We also know that if it stops working, we have a process to refine the system.

Hooray for agile!

If you have questions about how to make Agile methods work for you, hit me up on Twitter: Jewel Loree. If you are based in or near Seattle, I’d also love to help coach you through your kickoff and help you development a management strategy.