Expert publishing blog opinions are solely those of the blogger and not necessarily endorsed by DBW.
Last week I had the opportunity to moderate a webcast titled “Agile Content Development for Book Publishers.” We had less than an hour to explain, demonstrate and sometimes defend the agile methodology in its use for books. We certainly didn’t have time to question, even redefine, our end product; the book. But if agile book development catches on, we will have to do it.
This season, more than ever, the book development process is under review. At a Womens’ Media Group members’ gathering last week, guest speaker Carolyn Pittis, HarperCollins SVP for Publishing Transformation, discussed re-examining the internal processes publishers have long used to create and publish books. Both Carolyn’s initiatives and agile development address one of the predigital legacies of publishing; the concept that our business is the creation of a fixed, complete package by a succession of exclusive process “owners,” with the ultimate product owner—the reader—at the very end of the line.
Agile methodology comes from the world of software development. It was intended to cure some major problems in that field: projects taking too long to complete; projects so complex and expensive that mistakes, only discovered at the far end, amounted to disaster: projects that, upon completion, were found to miss the mark in major and minor ways because communication among stakeholders had fallen down: projects that simply failed to fulfill the user’s requirements.
What agile development provided was a way to work in short “sprints,” resulting in “iterations”—versions of all or part of the product—for testing and feedback from “stakeholders,” a group that included the end user or the funder. One manager oversees the process, not the product. A series of sprints might or might not lead to a product that was ready for distribution and/or sale.
At first, this just doesn’t sound right for books, or at least not for trade books. So why is agile methodology being applied to book development? Because in our current cultural environment of instant downloads, regular updates and reader feedback, the leisurely process of making a book and the siloed organizational structure within publishing houses have come to be obstacles to success. Publishers could certainly benefit from greater speed, accuracy, functionality, end-user satisfaction; perhaps agile development methods can deliver them.
The agile process becomes part of the product in a way that book publishers will initially find uncomfortable. Agile process would let all stakeholders take part in the content creation. For fiction, would publicists weigh in on character development? Would digital media producers get involved in scenic decisions that affect embedded videos? (I can just see digital producers telling editors to ditch those troublemaking semicolons and m-dashes.) The walled garden containing author and editor would become a lot more crowded.
Then there are iterations: agile book development might point to a new definition of short-run printing, even of “editions,” of books. An agile-made book might be a “first edition” in a planned series of “editions” that would or would not be for sale or for download, and would or would not include reader input and feedback as it marched toward completion—or toward a new definition of “completion.”
A few publishers are experimenting with agile development for book content creation. Sourcebooks, since announcing this direction in January, is moving forward this season with one project that we’ll be watching. Meanwhile, a few developers are readying digital platforms for agile book creation. By summer we should be getting our first look at what agile thinking can create in the trade book business, and how customers respond to this new type of product.
Agile development doesn’t map point-to-point with book creation as we currently understand it— but that is the point. If we want to make products quickly but with high accuracy; products that understand are designed to address business needs from sales and marketing to investors; that give the end-users what they want; and that respond to the swiftness of change in the marketplace and the current culture, we may need to fashion ourselves less like 20th-century, “bucket-brigade” book publishers and more like agile software developers.