Why a micropodcast?
I’ve told the origin story of Agile in 3 Minutes, my micropodcast about doing business effectively, and narrated how I create the show each week. Last week, I wrote about writing consistently, because I seem to have arranged for that habit.
In my last job, when I found myself frequently fighting for my team’s continued right to its disciplined practices, I often hoped that those sitting in judgment would be willing to take a few minutes, read something potentially clarifying from some non-me internet person, and have a conversation with me about it. Looking back, I strongly suspect those managers and colleagues would have been more willing to take a few minutes to listen to something. With Agile in 3 Minutes, I’m hoping to engender the kinds of the conversations I’d hoped for.
It’s gratifying to hear, then, that the show is being put to that use. For instance, a manager in an Agile-seeking workplace is holding biweekly group discussions of particular Agile in 3 Minutes episodes to build shared understanding of where they’re headed and why. I love it! And I love that I’m not the only one who hopes for more of that:
”I cannot recommend this podcast enough. Listen to every episode. Talk about them in your team. Share them with your managers. Managers, share them with your teams.”
Why not only a podcast?
While some folks prefer listening over reading, episodes are often densely packed, and 180,000 milliseconds goes by quickly. Some listeners have requested transcripts, and I’d probably want that too (I read a lot). Everyone absorbs and digests ideas in their own way; 3 minutes of listening isn’t everyone’s best way.
And some folks want to financially back the show, but would rather not drip-fund it.
Solution: a podcast and a book
Now available on Leanpub: Agile in 3 Minutes, the book. Subtitle: “The simplest essays that could possibly work.”
Want to peruse the material and ruminate at your own pace? Buy the book!
Want to make a one-time donation? Choose your amount, then please accept the book as your free gift. (If you didn’t want it, tough luck. It’s yours.)
Either way, as new episodes come out, new essays will be added to the book. As with any Leanpub publication, once you own it, all updates are free.
I appreciate your devotion of time and attention to my work on Agile in 3 Minutes. Since it’s a labor of love, your love is another way to support it. Now that the show’s included in the popular podcast directories, you can help others discover Agile in 3 Minutes by reviewing it in iTunes or Stitcher. Please do!
I’ve always written a lot
I’ve been writing on my website, on and off, for nearly half my life. When I started, as a teenager freshly dropped out of college into my first job, I tried to write so far-flung friends and family could read it and get the references, and so that if the occasional internet stranger ran across it, they’d get a rough idea. A key learning, early on, was that my best posts included both (1) what happened and (2) how I felt about it. But the benefit I sought was primarily my own: to clarify my thinking, to remember my feelings, to document the significant-seeming rapids of my turbulently flowing life for my friends and my future self. While my writing was publicly available, if other readers were finding it, I was unaware of them; and in any case, I was convinced that people who didn’t already know me could not possibly find anything of value in my words.
I kept writing, sometimes every day for half an hour, sometimes not at all for long stretches. There was a period from late 2008 to early 2013 when this site was offline and I didn’t write. It was a relief to bring it back up (including all the drafts I never published), and a further relief to get them out of a database and into revision control. Feeling safer about my words not being lost has been (as I suspected it might) a contributing factor to my writing more often this year. Another contributing factor has been Erik Dietrich. He’s been writing on his website for a long time too, and a ever-growing audience values his voice. So thrumpteen weeks ago, when Erik offered some simple guidance on how to make my blog more valuable to me by making it more valuable to readers, I listened.
I’ve always read a lot
Of his suggestions, one that sounded most actionable was to publish new posts on a regular schedule. But I didn’t see why that was important. When I run across a post I like well enough that I’m interested to see what its author says next, I subscribe to the site’s RSS feed. My feed reader is rss2email, so whenever I feel like catching up on blogs, I simply switch to my email’s “Feeds” folder and read whatever catches my eye. Given this reading workflow (see also my coding and podcasting workflows) and my being a fast reader, it’s easy to be an opportunistic subscriber. My investment in flow is self-reinforcing, because the wide-ranging ideas and information I gather from my readings further increase the area under the remainder of the curve.
As I heard myself explaining all this to Erik, I realized just how atypical a reader I am. Most people don’t chase the dragon of consuming their entire Twitter feed or subscribing to every blog they’ve ever liked. My reading habits are weird even to most of my RSS-reading fellows, let alone reasonable people who have a more casual relationship to everything they could possibly be reading on the internet. The way I consume, I don’t care about anyone’s publishing cadence, other than to miss them when they haven’t posted for a while.
My experience may not be universally representative
But it doesn’t matter that I don’t care. Lots of readers do. Lots of folks open their browsers and go to a handful of sites to see what’s new. Readers who are not like me — which is to say, nearly all readers! — add a site to their reading rotation if and only if it pays off: if they can expect to keep getting something valuable, and if their expectation keeps being met.
Now I understood Erik’s suggestion as not only actionable, but also sensible. And I loved the idea of returning to a disciplined practice (as I’d had when I started my online journal at 19) about writing. I wasn’t confident that my well of topics wouldn’t quickly run dry, because I’d never been conscientious about filling it. But I’m a pretty opinionated dude, and my line of work regularly stimulates thought, so I figured I could probably figure out how to keep the topics coming. (Lesson learned from software development: if I want to start solving the problem in front of me, I’d better stop trying to solve problems I’m not having yet.)
Try and see
So I acquired myself the habit of writing and publishing one new post every week. This week was a little tricky, so this post was started in a car, mostly finished at a coffeeshop, and published from the guest room at a friend’s house. That’s what it took to put together my 27th weekly post in a row? So be it. In 2014 I wrote a total of 15 and wished for better; in 2015 I’ve already written 33 posts. I still carry around a low-grade, back-of-mind fear that some future week I’ll have nothing to say, but it no longer feels like an imminent threat.
I’ve always found writing to be rewarding, but painful. The process is becoming less painful for me; I’m hopeful that the results are becoming more rewarding for you. In any case, expect me to keep at it.
Plot twist: I’ve actually been writing two new things every week! Give a listen to Agile in 3 Minutes, my micropodcast about thinking and doing business effectively.
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.
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.
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.
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.
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.
git add the MP3, the show notes, and the HTML container.
git push. Ikiwiki puts the episode on the front page and
adds it to the archive and the RSS feed. Easy!
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.
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.
Julio Merino recently described his coding workflow and invited others to describe theirs. My previous workplace development environment looked a whole lot like Julio’s, but my current one necessarily looks pretty different. Having needed to revisit some of the reasons for my preferences, I can more readily distinguish my current nice-to-haves from my can’t-do-withouts.
|Build Radiator||Standalone VM with a custom
|Backlog||Markdown files in Git||Rally|
|Architecture||CLI/GUI client/server||web services|
||IBM Rational Software Architect (Eclipse-derived)|
I had been an
nvi fuddy-duddy until my teammates finally prevailed on
me with their fancy colors and configs. Thanks, guys.
Mere strong preferences
I grew up as a computer user on classic Mac OS and NetBSD. When Mac OS X Server 1.0 came out, all clunky and expensive, I bought it just to have it; when the Mac OS X Public Beta came out, I knew my worlds would usefully merge, and I could look forward to not having two computers on my desk. As a developer, when I don’t have these at hand, I sometimes fumble to compensate:
pkgsrc (”package source”) gives me an easy way to install most any other tools I might need on any Unix variant with any level of system access. I gave a lightning talk about it at CodeMash 2013.
On my own time, I choose a Unix-centered environment whenever possible, to which the two open-source projects I spend the most time with (pkgsrc and ikiwiki) happen to lend themselves very well. I’m sure there’s cause and effect in both directions.
When I’m stuck on Windows, where I don’t feel as comfortable or productive, I usually wind up arranging for a Unix environment, and using it from time to time to keep myself from getting sidetracked too often figuring out how to do some small thing.
When I’m stuck with a weird revision control system, I often use Git in parallel. The administrative overhead of syncing with the source control system of record is more than paid for by the speed and clarity of diffs, which I check quite often as I go along.
When I’m programming, I’m more attuned than usual to bottlenecks in the flow of my work, because I’m more accustomed than usual to having the agency and the means to ease them. I’ve learned that while not having Unix tools is often a bottleneck, it’s not always so, and I can wait until I’m having that problem to do something about it.
In software development, there’s a problem I always have: I make lots of decisions, some of them are bad, and I need to know about those ASAP. So I don’t wait until of-course-I’m-having-that-problem-again to do something about it. Unless the code’s getting thrown away in a few minutes, I always start by arranging for a fast red/green feedback loop.
It doesn’t have to display actual red and green, or use an established testing framework, or finish before I can blink. It does have to start with a keystroke, finish with a clear indicator, and return me to my context. These affordances ensure that I’ll reliably make at least one decision well: whether to run the tests. Because I’m sure I will, it’s worth the marginal effort to add more tests as I go. And because I’m sure those tests are the fastest way to catch my mistakes, it’s worth the marginal effort to start with tests and use them to drive my design decisions.
It’s not about tools
I don’t worry about optimizing test speed until I’m adding tests often and running them often and the run is starting to feel slower. I don’t want to solve it before it’s a problem (it might never be), or after it’s a hard problem (I don’t care for those).
It’s about flow, both kinds — my state of mind and my delivery of outcomes — because they’re tightly linked. If I let problems grow large, they’ll impede my flow later, so I avoid knowingly creating future hard-to-ease bottlenecks. If I let myself be bothered by problems that aren’t yet impeding me, they’ll impede my flow now, so I avoid any further worrying about future bottlenecks.
My coding workflow is continually being optimized for speed and predictability. I look for the present bottleneck, work to ease it, and repeat. Every time I pay for smooth, my investments yield strong returns.
I’m finally coaching! Considering I was hired as a consulting coach in January, started with a client in February, and landed with a team in March, that’s an odd thing to say, isn’t it?
What do I mean by “coaching”?
”Coach” (the role) includes teaching, training, mentoring, and any other kind of situationally called-for behavior, but aims to center on coaching. “Coaching” (the activity) means helping people and teams become more themselves. I recently discussed this topic with Zach Bonaker and Ryan Ripley on Agile for Humans 013, and I’ve got a blurb about how I and others see what I do.
Others use the word differently. For instance, some say “coach” to mean “consultant who will tell us what to do.” I don’t want to do that, and I don’t think it has much to do with coaching. To take another example, I often hear a distinction made between “process coach” and “technical coach,” with which I have at least three beeves:
- I’m not coaching processes or techniques. I’m coaching people.
- As a coach, I’m more effective when I consider the whole system.
- In Agile software development, process and technique are intertwined.
Why did it take so long?
I was brought in as a hands-on technical coach, as a deliberately influential member of the team. I liked the sound of that, especially after so much time off. Let’s get paid! Let’s go to offices and work with people! Let’s see if I can earn trust, influence and be influenced, help a few people who wish for better to get it.
It was a slow start, for a variety of reasons: two weeks to get new-hire oriented at my consultancy, more than that to arrive at clarity about which client team to place me with, much more than that to get me a development-capable machine with a development-ready environment. During those months, when the only way to learn the domain and the codebase was to bother someone who was trying to get their work done, I tried pairing a couple times and decided to stop. (I hate wasting anyone’s time.) Until I could acquire the local knowledge on my own, I looked for other ways to start helping the team, such as:
- Hands-on classroom sessions for an hour every afternoon, alternating between exercises to build new code skills (TDD, refactoring) and legacy code skills (characterization tests, refactoring). After a while, not seeing how to apply what they’d learned to their production codebase, the team lost interest and we stopped the sessions.
- Whole-team programming for a full two-week iteration. It wasn’t textbook mob programming, or even close, but it was a start at learning to work together more effectively. They were nearly as productive as they’d been the previous iteration, plus key knowledge spread to many more brains, plus everyone on the team was animated and engaged in the problem-solving. But under perceived pressure to maximize velocity, the team decided they couldn’t afford to continue working in this way.
One obstacle was the sheer size of the team (at its largest, about a dozen). With a team that size, it’s hard enough to have a direction, let alone try to change it. Another obstacle was the frequency with which members joined or departed, constituting a new team.
How can I tell I’m coaching?
I’ve lost trust by trying to help in ways that haven’t helped, earned some back by finding ways that have been desired. I’ve found ways to offer potential value to the team without asking more than they’re willing to offer. I’ve listened, asked questions, and offered suggestions in conversations with and without keyboards, in groups and one-on-one. I’ve identified feedback loops in need of repair — several of which involve me — and have been repairing them.
In short, I’ve tried a bunch of things that didn’t work, and found a few that are (for the moment) working. I’ve danced insensitively, and learned some signals to be more attentive to. I’ve improvised ineffectively, and learned some new moves to try.
I know I’m coaching because, as the team’s needs have not yet been primarily technical, I haven’t been doing much “technical coaching.”
I know I’m coaching because I’m sometimes aware when I’m failing, when I’m succeeding, and when I’ve learned something.
I know I’m coaching because I’m sometimes aware when people want what I’m offering, and when they want me to be offering more.
I know I’m coaching because I’m not even sure “coach” is a thing anymore. Maybe nothing exists but people, the actions we take, the behavior patterns we choose, the capabilities we grow, and the environments we design. Some of what I do each day could be called coaching, some programming, some teaching, some delivering. My job is to catalyze mutually desired improvement, and I’m finally, perhaps, beginning to.
How do I feel?
This work is exactly what I wanted. I’m finally wrestling with all the challenges I hoped and wished this job would consist of. What’s more, I’m being supported in ways I’d learned not to hope or wish for. As a new coach, I’ve leaned heavily on Pillar folks and other coaches at the client, all of whom have lent their expertise and experience to help me when I’ve asked. I’ve been very lucky to have such easy access to terrific consultants, to know I’ve got the backing of program management, and to bring my whole self — because the work needs me.
I would have regretted not doing this. I also would have regretted doing it badly. But I seem to be getting the hang of it.
It’s everything I wanted, and then some.