XML.com: The Emerging Art of Agile Publishing

The Emerging Art of Agile Publishing
by Michael Fitzgerald | Pages: 1, 2

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.

	Week 1-2	Week 3-4	Week 5-6
Writer	Chap. 1	Chap. 2, cover copy	Chaps. 3 and 1
Copyeditor	Cover copy	Chap. 1	Chap. 2
Production Editor	Cover copy	Chap. 1

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.

Share your experiences in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article

Titles Only

Newest First

Internet Publishing Manifesto
2006-04-18 21:12:28 rallen@cisco.com [Reply]

Good article Michael. I've also had similar thoughts. I wrote about applying advances in software development (eg, Agile methodology) to content development in my Internet Publishing Manifesto (http://netawaremedia.com/blog/2006/02/06/internet-publishing-manifesto/) . The publishing world has a lot to learn from the software community. -Robbie

Invovators of "beta books"
2006-03-30 09:24:54 newuser007 [Reply]

The idea that Dave Thomas pioneered "beta books" is a growing meme, but simply untrue. As Tim O'Reilly points out (in his comments here: http://www.loudthinking.com/arc/000580.html), O'Reilly), O'Reilly offered "JavaScript: The Definitive Guide" as a beta book (using that very name) back in the mid-90s.

And Apress was offereing early-adopter PDF editions several years ago.

This is not to knock Pragmatic Press, but to point out that the evolution of agile publishing has been happening for many years already, and its success is often a matter of chance, of having the right topic at the right time.
- Invovators of "beta books"
  2006-03-31 10:44:15 Mike Fitzgerald [Reply]
  
  Dave is "a notable pioneer," not the first or only. But his overall approach of offering his books early and as PDFs (unless I've missed an exception) is an excellent trend. I think O'Reilly and other publishers could learn some things from Dave and I hope they do. But it's not just Dave: it's the agile practice that I'm after. It's what customers are after, too. Fast. Timely. Abundant. On target technically. Available. Companies not getting in the way of themselves. This is what the market is looking for. It would be a mistake to say or think that Dave has not brought this to our attention, even if he isn't the first.

Agile Publishing with XML
2006-03-09 11:24:53 scottys.log [Reply]

Great article.

Agile publishing shouldn't need to worry about common tools, as long as everyone on the project is using a common format (XML) and common schema/DTD (e.g. DocBook). Each person could work on whatever section of the document they want using the XML editor of their choice (vim, jedit, Arbortext, you name it!) as long as there is some validation prior to checking it back in!

What is desperately needed are more XML editors that support RelaxNG. Thank you oXygen! However, we need the more author-friendly tools to support RelaxNG. (Psst! That means you, Arbortext and XMetal!)

Agile Publishing
2006-03-09 03:11:55 Dave Pawson [Reply]

Thoughtful piece Mike.
I can hear the screams and tears over using
common tools, even if we know it does make sense!

Is there any experience of using this?
O'Reilly or your own?
- Agile Publishing
  2006-03-09 23:02:24 PeterSefton [Reply]
  
  This is a nice article. I like the term 'agile publishing'.
  
  At the University of Southern Queensland we have been working on a Subversion-backed publishing system, and using it some of the ways suggested here. We were aware were doing agile development, but hadn't thought about our publishing processes in the same light.
  
  I've blogged this at my site:
  http://ptsefton.com/blog/2006/03/09/ice%3A_agile_publishing_%28with_a_long_snout%29