Everything good and true about Agile I learned DJing

Gary Givental
7 min readMar 6, 2021
Author DJing at a Chicago warehouse party, early 2000s. #Vinyl. #Analogue.

It was late 1996, I was a sophomore at the University of Michigan studying Computer Engineering, and for the first time in my life, I was going to a rave in Detroit.

I had always thought DJs sat in a booth at a radio station, played popular music and between songs recited commercials. That night, I was to be proven wrong. Detroit, the birthplace of Techno that gave the world such greats as the Belleville Three, taught me that night a secret few in America were lucky to already know.

Photo by Matty Adame on Unsplash

DJs were about to become the rock-stars of the new generation. And I wanted to be one of them.

And so, I bought a pair of used Technics 1200 turntables, a cheap Numark mixer and a handful of records to get on my way to DJ stardom. I had no idea how to mix, but I hit the record button on my Panasonic boombox and shortly thereafter, my first mix tape was done.

It was absolutely terrible. Awful.

I kept going, making tape after tape, eventually giving them to friends willing to listen. Some would tell me the tapes were “pretty good”. Others were honest and pulled no punches in telling me it was total garbage. And one day, I got the response — “Hey that mix was not bad. Not awesome, but I liked it”.

Soon thereafter, I played in public for the first time, at a college house party. And the year after, my first warehouse party. And some years later, I performed at the 2001 Detroit Electronic Music Festival — one of the largest free electronic music events in the world at the time.

Author at Burst warehouse, Detroit

Dear reader, so what, might you be wondering, does DJing have to do with Software Development lifecycles and specifically Agile.

Everything.

I propose that learning to make mix tapes, performing live in front of thousands of people — my journey from awful to crowd-pleaser is exactly identical to the spirit of Agile, building working software, improving it over time, and delighting the customer in the process.

Today, Agile is the darling word of every software and technology company. Countless teams and organizations are undergoing agile transformations, learning Japanese words such as Kanban, following two-week development cycles called Sprints and doing daily stand-ups — Scrums.

User centered design, aka Design Thinking, has come into vogue as another great philosophy and practice used by many companies striving to create experiences customers love.

Before I even knew what Agile was, I realized, if I wanted to get good at DJing, I had to give my terrible mixtape to someone I trusted to give me feedback and then do it all over, hundreds of times.

Feedback Loops and Frequent Releases

Short feedback loops, “Fail Fast”, frequent releases of working software — these are all some of the core principles of Agile.

Recording hundreds of these bad mixes, listening to them over and over, struggling to make them better, and getting feedback from friends, I was discovering and using these Agile principles before ever being formally introduced to this concept.

Showcases, Retrospectives and Responding to Change

Agile practices such as Scrum recommend showcases at the end of each development cycle known as Sprint, and Retrospectives to identify opportunities for improvement.

After many months of making mixtapes, and getting involved in the local electronic music scene, I finally had an opportunity to play “publicly” at a house party in Ann Arbor. My first showcase has finally arrived.

In those days, especially for new DJs playing at small events, every gig was potentially nerve-wrecking and fraught with risks. The mixer provided by the event organizer was likely not the same one I owned and was comfortable with. Often not all the functions on the mixer even worked. The lighting was usually dim and controls hard to see. The turntables were cheap and hard to control to properly beat match and mix.

Every gig presented unique challenges that were unknown ahead of time and totally outside of my control. Including the people who were the ultimate judges of my amateur skills. And so, I would soldier on, doing my best not to screw up the mixes (called train-wrecking in DJing — when the transition from one song to the next does not blend properly and the overlapping drum hits sound like a train), and most importantly watch the crowd and hope not to clear the dancefloor.

Photo by David von Diemar on Unsplash

Just the same in software development, working software that performs functions that delight the user are the only metric that matters. First releases are never bug-free, they’re often clunky and missing features, but the goal is to give the user something of value, even just one compelling function they actually need and then get feedback as quickly as possible.

And yet, what I often see in software projects is never-ending design, with meticulously drawn pixel-perfect interactive mockups generated so far ahead of development that by the time code is written, momentum is lost, requirements have changed, and precious time has been wasted talking about ideas, rather then executing.

You see my dear reader, to a DJ, no matter how technically skilled you are, how excellent your home studio is, how extensive and exclusive your vinyl collection, the ONLY measure that matters is what the crowd does on the dancefloor.

Fail Fast vs. Planning — aka the live gig vs. recorded album

For just a moment, though, lets consider — is planning versus failing fast really all that bad? Am I really suggesting that all projects should be executed guns blazing, rugged yet working code graduating right to production? No, not at all. In fact both approaches are critical to employ at the right time, in the right context. In fact, a fantastic article on the danger of misusing the idea of Fail Fast states plainly:

When senior executives of an organization do not properly arm themselves with adequate depth of understanding to terms such as “Lean” and “Agile,” they end up not only lumping them together, they urge the organization to then “fail fast, fail often.” If we’re “Lean” we must “fail fast, fail often.” Or, if we’re “Agile” we must “fail fast, fail often.” -Dan Pontefract

The key is thoughtful and iterative progress.

In order for DJs to get booked for an event, typically a mix is required — your audio resume. In 1990s, mixtapes were typically used for this, and if you’ve ever recorded onto a mixtape, then you know, dear reader, it’s a one shot deal. You hit the record button, do your best, and if there are any mistakes, you have to do it all over again. Planning the mix carefully, practicing dozens of times, make test recordings, before cutting that final mix, is paramount.

In product design and software where the risk of failure carries a high cost — same applies. I imagine NASAs software is planned and tested much more carefully then a freshly deployed cloud-app.

However, the live performance for a DJ can be a great opportunity to fail-fast. I used to have this argument with fellow DJs dozens of times — should you plan out your mixes for a live gig, or feel the crowd and play to the audience.

As a DJ, I have never pre-planned the whole set for an event. What I did do, is something very similar to Design Thinking Hills — I would have a rough idea of the beginning of the set, middle and end. I might have even had a few 2–3 record sequences that I knew played well together — a trick akin to software patterns.

However, when I put out mixes as promotional material or for sale, I planned carefully, deciding on the sound I wanted (mission), choosing the tracks (design and architecture), iterating the mix over and over until it sounded right (iterative development and frequent reviews) and then recording the final mix for distribution (shipping the product).

Author’s first mix CD sold at local music stores, original artwork by Adam Scenna.

So what?

My dear reader, whether you’re a seasoned IT professional, or just starting out in your career, I want to inspire you with one simple truth.

Your hobbies can inform, sustain and energize your career.

The path to getting good is relentless action, incremental improvement, creativity, courage to receive feedback, willingness to fail and try again.

Author at Carbon Lounge, circa 2002

Software Development is as much art, story-telling and self-expression, as any of the skills I learned DJing, making mix tapes, and performing at music events.

So, please, dear reader, take action, show up, put out your work, get feedback, plan, practice, be Agile, fail, succeed. Your hobby just might teach you skills you leverage in your professional career!

--

--

Gary Givental

Software Engineer, AI geek, and longtime yogi and martial artist.