The Emerging Art of Agile Publishing

March 8, 2006

Michael Fitzgerald

Writing books and publishing them can be arduous tasks. A book may take years to write, and, once written, may languish in production for months. Writing 300-plus pages takes soul-searching, no matter the topic, and getting a manuscript cleaned up and ready to print requires a sustained team effort. Given the traditional processes, we have come to expect a lot of sweat and tears out of writers and editors.

But the time has come to collapse these processes. Not for all books, mind you: I wouldn't expect a novelist to produce a novel in a few weeks, nor would I likely read such a book, brilliant talent notwithstanding. I am talking about technical books.

There are a lot of things we can change to make writing and publishing technical material quicker and easier, and to improve the revenue models for the people who write and who publish. Some of these processes are beginning to take shape, and others are just dreams. In this article, I'll recognize these efforts and hopes, those that are in place and those that may only have been scribbled on a napkin.

What Do You Mean by "Agile"?

Five years ago, in February 2001, a group of 17 people got together at the Snowbird ski resort in Utah to talk about ways to break free from old, over-starched software practices. The result was the Agile Manifesto whose tenets are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

In my 20-plus years writing about software, I've probably spent most of my time grinding under the weight of the right side of the manifesto, not the left. The manifesto, and folks who support it, value people over processes, the real thing over the imagined thing, and close customer involvement. They respond intelligently to the inevitable revelations that come along when you are creating something new, rather than being stuck in rigid compliance to uninspired and uninspiring plans.

I like what I see on the left side of the manifesto. I hope you do, too. If you are interested in finding ways to bring these ideas to life in your publishing and writing work, read on.

Writer/Editor Teams

The key to improving efforts to produce software, and books about software, is communication. Not meetings, and meetings about meetings, not a blizzard of mind-numbing, indigestible documentation, but real communication between individuals and groups who have decided to create something they and their customers will like, and perhaps be proud of as well.

When people communicate well, they tend to find more agreement and common ground—obviously—and then they become more focused and productive—less obviously. They trust each other, and support each other. I have seen it happen, but too rarely. Rare because vertical management styles and human insecurity often get in the way of making good things happen. But I'm not going to worry about or try to remediate what doesn't work. I'd much rather talk about what does work, and how to make it happen more readily and more often.

What would an effective team of writers and editors look like? Not much different than it already looks (I generally have good communication with the editors I work with), but there is one important difference. It is in the quality of focused informal communication. I think we see a lot of organizations with successful formal communication: meetings, memos, newsletters, intranet sites, email updates, and so on. That is not an issue. And we also find plenty of informal communication about the new baby, last weekend's sailboarding adventure, the vacation to Patagonia. What we need is more informal communication that is focused on the work at hand. What do I mean?

Over the years, I have seen tremendous leaps in communication when that communication happens in a relaxed and emotionally safe atmosphere. Settings where good food and people mingle, where there are frisbee courses, ski slopes, or hiking trails, where folks can let their guard down, develop trust, and talk about what they really think and believe, with little fear of "What will the boss think?" or "Will someone steal my idea?" When this really happens, ideas blossom, motivation soars, and people get excited about their work. That is the environment I like to work in.

Another thing that helps is something I'll call interleaving.

Interleaving

Interleaving is a style of work where tasks are integrated with other tasks and among groups, not just held by individuals in missile silos until launch time. For example, I normally write in my cave, an 11-by-17 office above our garage, for weeks or months before an editor sees my work. Why? Because my chapter or article is stored exclusively on my hard drive.

If our work were interleaved, it could be stored in an online Subversion repository that could be accessed by HTTP. Then the editor could read the message logs or "check out" what was going on anytime. Intrusive micromanagement? No, because we communicate with and trust each other. We help each other instead of yelp at each other. It keeps us clear, accountable, and unstuck.

Are you thinking, "But that doesn't work"? If you think that, of course you're right. I choose to think something different, and I am right, too. We see opposite worlds, and they exist in parallel. Choose yours, and I'll choose mine. But please don't create my world in your image.

Another way of interleaving work is to share tools. If I were a production editor, I might be working in the Adobe FrameMaker editor to produce camera-ready copy for the printer. As a writer, I've worked in FrameMaker as well. Why not share the same tool? It would cut out a lot of time if we both used the same tool. Too much time is eaten up converting and munging files from one format to the other, to say nothing of the cleanup required. Uncommon? Yes. Impossible? No.

Sure, I might prefer Vim with Textile, but wouldn't it be time-wise to make a compromise here? I don't mind. We're a team. We trust each other. The whole is greater than the sum of the parts. For the time being, let's set aside our isolating prejudices and get the work we share done.

Singing in Tune

Singing on key comes naturally to some of us, but a good soloist is a rarity. I like to sing, but my singing sounds better in a choir where I can hear and tune in to the better singer standing next to me.

It's like good project management: team members can "tune to the choir" by sharing what they're doing in, for example, an online, accessible tool like Basecamp or by simply exchanging iCal files. Use whatever the team agrees on, but share what you are doing daily. Set up an IRC channel and talk, talk, talk. Chatter about what matters, and watch things get better. It will take discipline and maybe a little courage, but soon it will be a matter of course.

Let a team member help coordinate the project and schedule, preferably someone who is actually involved in the work and understands it, not just an anxious overseer who trembles at the presence of upper management. The team communicates. They trust each other. Leadership is a natural thing that grows out of the team, not by scrambling for recognition. If arrogance or glory-grabbing infiltrates the team, confidence slackens and work falls off.

Carve Up Your Work

Isn't it easier to eat a sandwich a bite at a time, rather than stuffing the whole thing in your mouth at once? Sure, you see it happen in the junior high cafeteria, but how could you taste anything, or enjoy it for that matter? You can't savor it much unless you do it in bite-sized pieces.

Writing and editing, in my view, are better experienced in bite-sized portions. So divide the work in pieces with short cycles. In other words, write short chapters, or divide longer chapters into smaller sections, and then turn the chapter or section over to your editor. She will likely turn it around quickly, because it is no longer a daunting task, hovering in her inbox.

When the writing and editing happen in short cycles, there is more of a flow to the stream, rather than breaching log jams. See what I mean? If the work flows more smoothly, there is less opportunity for contention among teammates, and more opportunity for frequent, rapid exchanges of work among them. When the work starts to flow, momentum builds, and the momentum itself helps the flow.

Interleaving Schedules

I have a preference when I am cooking in the kitchen: I like to clean up as I go. I don't like a double-sink full of dishes to face in the evening when all the cooking is done. I like to work that so dirty utensils and dishes can disappear into an empty dishwasher rather than clutter up the sink, counters, and my brain.

What does that have to do with writing? A lot. Who likes to carry home an inch-thick stack of documentation to review overnight? I don't. I much prefer to spread out the work, a little at a time, so my mind is fresh and my edits are more accurate.

This is how to apply it to an agile team. The writer or writers, copyeditors, and production editors are working continuously on the same project, not in long, separate cycles. Long cycles tend to create camps and campers with their own campfires. On an agile team, the writers and editors share the same campfire.

Here is how it might go. The writers complete a draft of Chapter 3 at the end of a week. The copyedit and production people pick it up. It's a short chapter, so it is quickly read, proofed, and returned to the writer by the end of the next week. While waiting for Chapter 3 to come back, the writers enter edits from Chapter 2 and work on Chapter 4 during the following week. At the end of that week, the writers and editors swap work again. The work flows, and you feel like you are getting somewhere.

The following schedule shows a slice of an agile schedule.

You get the idea. Work is staggered. The pieces are smaller, so they are less likely to fall out of sync. If they do fall out of sync, there is time built into the schedule for recovery. If a team member falls completely off the map, try triage. Failing that, console then replace the poor soul and adjust the schedule, but remember that people are more important than the things they produce. I am easier to work with when I feel like I matter. I have observed too much of the opposite tack. How about you?

Out the Door

Ship early-adopter editions, early. The production editor or some other technonaut creates a PDF of the first three chapters and parks the mini-book on the company website with a For Sale sign. The eager consumer gladly pays a few bucks for the chance to get up to speed and chip in. Such consumers have the privilege of contributing to the revision and improvement of the manuscript, using tickets in Trac or some such. You can't promise that you'll incorporate every suggested change, but you appreciate any and all comments just the same. This sort of feels like an open source project, doesn't it? A better work environment for my tastes—how about your tastes?

Dave Thomas of Pragmatic fame does a great job with this. He is a notable pioneer to this clever delivery and revenue model. O'Reilly is catching on, too, with its Rough Cuts editions. Before long, any tech publisher who does not do early, online editions will be left behind. I appreciate what Dave has done for the industry, and I hope he gets the recognition and prosperity he deserves.

What About Herb?

I can hear you now. "Herb will never go for any of this." (Doesn't everyone have a Herb to deal with?) Well, then, Herb isn't really on your team. Let him work on some other team, or do something harmless, by himself. You say that you have to work with Herb? No you don't. Try to persuade him, but if he is unyielding or abrupt, find someone else to do his job. Part company cheerfully, but let him off at the corner. Herb isn't agile. And if anyone on the team isn't agile, the goal is out of reach.

Summary

I conclude with this summary of how to publish with agility:

• Build real trust through constant, informal communication
• Interleave work processes between writers, editors
• Share work openly, don't store it in secret silos
• Store source files in an online repository and give all members of the team access to it
• Agree on and share tools to reduce the waste of format conversions
• Carve up your work into small, easily consumed and exchanged pieces
• Keep track of what you are doing daily with some other suitable tool
• Publish your work early and often, charge a little something and get free reviews
• Let Herb do things his own way, but not on your team

Agile is fun. It is still uncommon, but it doesn't have to be. Change the way you look at your work, and it will change with you. Get agile, live longer, and live happier.