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.
- Internet Publishing Manifesto
2006-04-18 21:12:28 rallen@cisco.com - Invovators of "beta books"
2006-03-30 09:24:54 newuser007 - Invovators of "beta books"
2006-03-31 10:44:15 Mike Fitzgerald - Agile Publishing with XML
2006-03-09 11:24:53 scottys.log - Agile Publishing
2006-03-09 03:11:55 Dave Pawson - Agile Publishing
2006-03-09 23:02:24 PeterSefton
