When I’m programming, I can usually sense when I’m off track, and have accumulated a bunch of tricks to direct my flow. When I’m podcasting, I envision automating some of the manual steps to make the production process smoother, but it doesn’t feel like flow yet. Every time I make it all the way to the end of my checklist, I feel a sense of relief. Here’s how the sausage gets made each week.

Choose the topic

Before there was a show, to convince myself I had enough to talk about, I made a backlog. Once there was a show, listeners started contributing suggestions for topics and other improvements. (You can too.)

Sometimes I look at the backlog. For instance, a couple nights ago (having shipped 22: Control), I knocked off the top item from the list of possible site enhancements: “Add enough iTunes-specific metadata to get listed in the iTunes podcast directory”. By the time “23: Whatever It’ll Be About” comes out next week, the show will have begun to expand its audience beyond a small set of motivated Agilists who are also podcast-app devotees and RSS fanatics. Being in iTunes will help more people discover Agile in 3 Minutes.

So far, I haven’t looked at the backlog for the purpose of choosing my next topic. I’ve just been choosing whatever topic is already appearing on my mind’s horizon after the previous week’s writing session. I have been peeking to remind myself of the ideas folks have expressed interest in, in case any of them ought to influence the week’s writing.

I don’t believe learning is linear or orderly, but I do believe there exist more and less digestible orderings in which the Agile memeplex can be unfolded. When I choose a topic, I’m intending to improve the chances of a rewarding learning experience for folks who are following along in sequence.

That’s why, thus far, I haven’t talked much about what to go do. I’ve talked mainly about what needs to be true in our heads for Agile to make sense to us, so that it can be of use to us, so that it can help us be effective in our work.

Write it

While an episode may follow logically from the previous, and contain brief echoes, it must also stand on its own. One reason: I hope listeners find particular episodes worth sharing, and I hope recipients who aren’t familiar with the show will find those episodes worth their time. Another reason: I hope Agile in 3 Minutes will grow to become a reference, such that for any given topic, listeners can expect to find a 3-minute treatment. So I consider each episode fully responsible for carrying its own meaning because it might be heard in any order (including none) and it might form someone’s first impression.

I begin writing, once the topic is decided, by quickly jotting down all the ideas that come to mind. Word associations, other associations, sentence fragments, previous writings of mine to revisit and try to steal from. Then I follow some of those ideas a sentence or three, maybe a paragraph, not worrying about whether I’ve said the same thing badly or twice. Just keep saying until I run out of steam, then riff-fill on the next thing and the next thing. This loosey-goosey phase stops when I’ve written enough words to constitute an episode. If only they were the right words!

Every episode starts with a question, but I don’t always know the question before I start writing. Every episode has a title; I always start with a working title, and usually don’t need to change it. For the question, I tend to wait to see what I’ve written, because it tells me the hidden question I’ve been asking myself. That’s almost always the one I want to ask you.

How do I get to that point? Write and revise, write and revise, all the while asking myself more questions. Which concepts are holding together nicely? Which ones don’t quite follow in my mind? Which need more help if they’re to follow in yours? How does the whole thing follow from last week? What have I overexplained? Can I explain something better by way of my own experience, possibly my experience making the show? Is there an analogy to be made? Are there enough examples? Might a bit of self-reference kick the whole thing up a notch? Am I having fun writing this? Is there a grin on my face because I’m already looking ahead to reading it?

With rare exceptions, I don’t try to prepare more than one episode per week. It takes my best energy and self-awareness to dig deep for my best ideas in my best words in my best order. If I want the output to keep being any good, I need time to recover between attempts. Exceptions: I wrote the first two so there’d be enough show to announce, and I wrote 11-13 so I could go on vacation (which I then needed!) without impact to the weekly cadence. In the other direction, since the show began, I’ve missed only one week: Episode 5 was delayed by a bout of bronchitis, and you can hear the urgency to get back on schedule in my still-recovering voice.

You can hear me talking a bit about this writing process at 42:24 of Agile for Humans 013. In short, I mash my thoughts and feelings, stir, pour through a fine sieve, and chill for several hours. I’ve just thought of a fun way to make my work visible. Next time I’m ahead of schedule, I’ll try it.

Record it

I travel for work every week, so I bring my USB microphone, pop filter, headphones, laptop, and iPad. I set them up in my hotel room, turn off the climate control, unplug the fridge, and wait for outside noise from the street and neighboring rooms to die down. I read the script off the iPad, through the pop filter, into the microphone, into QuickTime Player. If it’s a good read, I plug the fridge back in.

Postprocess it

I open Audacity, import the audio, chop leading and trailing space, run the Compressor and Noise Removal filters, and export to AIFF. Using a shell script wrapper around LAME, I compress and tag the MP3, then delete the intermediate audio files.

Describe it

Using a custom ikiwiki template, I write show notes in a mostly declarative format, usually with at least one link to the C2 wiki and another to Wikipedia. I also define lots of tags, even though the Agile in 3 Minutes website doesn’t make use of them yet, because otherwise at some point when there are lots of episodes and I want to provide a tag cloud for navigation I’ll have to assign lots of tags on lots of episodes. I hate grunt work, so I do a little of it every week. Also grunt work: manually create an HTML container so Twitter can show an inline audio control when anyone posts a link.

Publish it

git add the MP3, the show notes, and the HTML container. git commit. git push. Ikiwiki puts the episode on the front page and adds it to the archive and the RSS feed. Easy!

Share it

I post the episode to Twitter and other social media. I post it to Twitter several more times over the course of the day, 2-3 hours apart, with a variety of quotes pulled from the episode script.

Improve it

More automation would help me sustain my pace. If all I had to do each week besides write the script, record the read, and jot some show notes were to push a button to do everything else, that would be really fun — I’m a programmer, I think grunt work being done by code I wrote is fun! — and would let me focus even more on the writing that makes the show what it is. So anytime there’s a little slack in the production schedule, I’ll be looking to automate one more step.

Do you know a cool writing or audio-production trick? Got ideas for the show? Let me know in the comments.