Last year, me and the other guys in Six Foot Machine put out our first release, (get it here for free!) a ten and a half song album entitled “Monday Night Miracle”.

SFM records are fundamentally different creatures than literally all of the other albums I’ve worked on in the past. While I’ve started to explain some of the logistical differences here in the past, I found a much better analogy the other day, related to work.

“Waterfall” and “Agile” development is in the news a lot these days because of the healthcare.gov rollout, and of course, its problems. This is going to be an oversimplification – and I’m not an expert, just a frequent witness to this kind of stuff – but the gist of it is that in “waterfall” style development, everything is done in one big piece, while “agile” development is rolled out as soon as possible in its most basic form, and pieces are improved & added as you go.

</sound of any developer/project manager reading this freaking out and demanding details and exceptions be stated, and referring to books from 1997>

Now, when I say I’m not an expert, I mean in the purest sense of this. There are certifications and books and generally accepted schools of thought on these concepts, but honestly, they bore me and I’ve never needed to speak in those terms, so I don’t. There are plenty of people who do, so if you’re interested, you should ask them and not me. But the general principles behind these methods are really important, because they’re more about approach and priorities than technical or process specifics. Waterfall style work – even non-development work, like writing something on your dumb blog – tends to put a very strong emphasis on the importance of the whole being bigger than the sum of it’s parts. Your vision is this big, functional system, and if it doesn’t do everything, it doesn’t really do anything at all. On the other hand, Agile style work lets you get something very basic out there and in something close to the real world; you very quickly understand the costs and benefits of your general approach, instead of doing all this work and then realizing it’s fundamentally impractical or ineffective after putting in months or years of work.

No matter what you’re building or trying to accomplish, you’re probably working somewhere along the spectrum covered by agile and waterfall. When I used to build product videos, I initially started off – as a web generation guy – doing things with an agile approach. I would storyboard out scenes, put together an extremely rough cut, and then show my bosses and co-workers and get feedback.

In my case, this was almost always a disaster for a couple of reasons. The biggest one was that I had a complete vision for the final product that people couldn’t grasp from a storyboard and rough cut. There were too many little touches and details that I simply couldn’t convey the value of without actually having them in place. In that particular situation, basically my work didn’t accomplish ANYTHING, or have ANY VALUE at all until it was completely done. It was a waterfall style project, whether I wanted it to be or not. 

Increasingly, I started doing more work that way, but only because of the nature of what I found myself doing. When I was doing something new (investor decks, for instance), and wasn’t sure if it was worth doing, I’d almost always work from a more agile perspective – and when I didn’t, and tried to keep the whole thing to myself until unveiling the finished product, it usually blew up in my face.

So there you go. If you can solve a big chunk of the problem without perfecting the solution, or you’re trying something new, agile is a great approach. If the outside community can’t add value, or if your solution is truly useless until it’s completely finished, you’re probably stuck working on a waterfall. Naturally, you can see why big, giant waterfall projects are really scary, and extremely risky, and conversely, why risk-averse people LOVE agile development, even when it’s impractical.

Now, what the hell does any of this have to do with making records? I’ll tell you.

My shock, and initial resistance, to the way SFM produces our finished recordings is a lot like some middle-aged software developer who’s used to building big, detailed, waterfall projects, and is thrown into an agile environment. All of my old records were waterfall projects, in fact. Here’s how Glenn’s Army would make a record.

1. decide it’s time to make a record
2. figure out how much money we could spend
3. figure out how many hours we could book in a studio for that amount
4. figure out how many songs we could do per hour (.28 or whatever)
5. decide the length of the album
6. decide what songs to include, and start writing whatever was missing
7. book studio time
8. get really, really good at playing all of those songs, over several months, in the exact way we’d need to play them at the studio
9. go to the studio for several days and do everything perfectly (or as close to it as possible)
10. have a record

Everything about this screams waterfall; maybe it’s not a big surprise that two thirds of our band works for the federal government today. Our projects worked because we got really good at setting requirements, meeting deadlines, and accurately assessing our capabilities and the capabilities of the people we worked with or were dependent on. When things DID change, it drove me (and probably the other guys) bonkers. On Fight Songs, Andrew wrote – I think – two songs pretty close (for us) to our recording time, and I really didn’t want to add them. It’s not that they weren’t good. It’s that they weren’t part of the original requirements, and that terrified me. They ended up being two really good songs, but adding them was not without risk.

This process, with or without a studio, was how I did every album for every band prior to SFM. Plan, plan, plan, practice, until the big day. BOOM. Record. Success was driven entirely by our ability to plan ahead and accurately project future situations. When Elementary recorded our studio full length in 2011, I went right back to my old playbook and ran the same process verbatim. 

Today, as with software, improved, cheap tools and the internet have completely blown up the necessity – not the value, but the lack of choice – that’s always come with musical waterfall development. While famous artists or rich guys could screw around in different studios and do things piecemeal, that was rarely the case for small bands with few resources. Today, SFM is a perfect example of the previously nonexistent choice facing musicians. As a post-2010 band, we basically prepare for nothing when it comes to recording. Jesse will usually put together a very simple, structural demo of a new song literally the day we record it, and send it all to us to mess with and think about. From that point forward, unless we actually change the structure (which is rare, but not that hard to do when we choose to), the final song you hear a few months later is based on that very skeleton, even though every single part – guitars, drums, bass, vocals – has been completely re-done. The bones of the final track exist from day one.

Is this better? Boy, I really, really don’t know. It’s certainly better for us; we’re adults, and we only get to practice once a week. In high school and college, Andrew and Steve and I would practice three or four times as often when writing or working on a record; if I recall correctly, we recorded almost nothing until it was time to go to the studio. If SFM did that, we’d never have any songs. We’d simply have forgotten them by the time we played again. The side projects Steve and I are working on today, in fact, are somewhere in the middle of these two approaches, and we don’t make progress anywhere near as quickly as SFM, largely due to the constraints of waterfall style song development. We forget things all the time, retrace our steps, decide things are bad after working on them for weeks, and constantly deal with other forms of adversity, because we lack the agile development skills the other guys in SFM (i.e., not me) have.

Is agile development of music less “artistic”? I don’t put it in quotes to be a douche; in fact, to me, a lot of times it feels like it is. But some of that – maybe all of it – is based in nostalgia, and it’s important to be aware of that.

Anyways, the point of all this is that SFM has a new album just around the corner built exactly this way, and like just about everything else I’ve ever done, I’m really excited about it. Sure, I love the music, but I also love that I’ve been able successfully adapt in order to make sure that music actually got made. Old dog, new tricks, and all that.