Agile Publishing

Noel Rappin, Monday, November 12, 2007 @ 4:04 pm

I'm currently working on my third technical book (Professional Ruby On Rails, available in February, wherever fine technical books are sold). Each one has had a slightly different process, in chronological order...

1. I submitted each chapter on completion directly to the Development Editor (DE) in charge of the book. Within a few days, she returned a well-commented revision.

2. I submitted each chapter on completion, as before. However, the DE did not turn around an immediate review. Instead, at the 1/3, 2/3, and finish points, the partial manuscript was sent to external people for review.

3. I submitted each chapter on completion. There is no intermediate review. Upon completion of the whole thing, it's sent to a technical editor to review code and a copy-editor for content.

Version three is a classic waterfall model -- all development is complete before any testing happens, and all revision happens in the next phase before the book moves on to the final production phase. Version one is about as close to agile as you'll get in the publishing world (with the possible exception of Pragmatic), and version two is somewhere in the middle.

Well, I got to thinking about these experiences as a kind of controlled experiment, with me as the common element and trying to measure what, if any, difference the process makes to the eventual outcome.

• The quality of the feedback makes a huge difference. In the first process, feedback came directly from the editor and was detailed and useful. In the current process, feedback is coming from copy and technical editors contracted by the publisher -- it's not quite as detailed about issues of style, but they are quite thorough about, say, when a reader might be confused by the text. In the other process, review was handled by outside volunteers, and we got a lot of "I didn't quite make it through the entire manuscript, but here are some thoughts on chapter one" -- there was very little in these reviews that was useful.

• I'm not sure whether a more agile process makes a difference in the final quality of the book, but it definitely makes a difference in the efficiency of the review. For example, the copy editor had an issue with a stylistic thing that I did. If I had gotten that feedback early, I could have incorporated it into later writing. As it is, the copy editor is going to have to flag this issue throughout the manuscript. There are similar issues with the technical editor and misinterpreted code instructions. The ending point will be the same, but the editors and I wind up doing some extra work.

• That said, there's a clear efficiency win purely from the publisher's side in that they only have to manage the review editors for a period of about six weeks, rather than the about six months they'd be on the hook if chapters were being reviewed on turn-in. I don't think it's much of a financial difference -- they get paid for the same amount of work either way, but it's easier for the publisher and editor to schedule in the waterfall model.

• From my perspective, the waterfall model is terrifying. Since there's no formal feedback on the manuscript until it's complete, I put in months of work before finding out whether it's acceptable. That's a huge potential risk, both for me and for the publisher. As it happens, the feedback has been quite good and there don't seem to be any showstopper problems. Still, I think it would have been nice for everybody to confirm that the road being walked down was, in fact, the right road.

I'm not sure the sample lends itself to big conclusions, but I think it's fair to say the faster iteration process is more manageable and efficient from the author point of view.

agile ajax

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment