XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.


The Emerging Art of Agile Publishing

March 08, 2006

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 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.

Pages: 1, 2

Next Pagearrow