Agile publishing: Creating better books through transparency

Trade book publishing is not a complicated process. Publishers acquire the rights to publish new titles primarily through relationships with agents. Once the agreement has been signed, the process from manuscript to shipping is fairly predictable and more or less linear:

Acquisition => Manuscript => Editing => Prepress => Production => Marketing => Sales

Each step of this process can be clearly identified by the associated teams who work on each step (e.g., Editorial, Design, Marketing and Sales teams). This siloed approach to publishing has, for the most part, worked for more than a century, helping publishers effectively deliver a finished book to the marketplace within a reasonably well-projected window of time based on their capacities.

The problem with this approach is that while it focuses on the activity of bringing a group of titles to market, it neglects how publishers might improve their products through a more collaborative and transparent approach.

This is where I believe agile thinking can help.

What is agile?

Beyond the standard definition, in the software development space agile is known as a set of principles related to how projects and teams operate in producing “potentially shippable increments” to market.

You may be thinking “How could publishers benefit from agile, when their goal is usually to deliver a single, finished product to the marketplace instead of software that is released in continuous versions over time?” It’s a good question, so let’s consider how three specific agile practices within the Scrum framework could better help publishers to deliver higher quality new titles to market with each release cycle, known as a span, resulting in better per-title performance and quality as well as more collaborative cross-departmental teams.

Scrum¹

One method for managing development throughput in software is know as Scrum. The term Scrum is taken from the game of Rugby (scrummage) when play is resumed after a stoppage. In technology, Scrum is best thought of as a framework for defining and prioritizing a set of tasks for small specialized teams to work on in intensive work sessions known as “sprints.” Sprints typically last two to four weeks in duration and are highly focused on accomplishing a prioritized set of tasks (the backlog) decided upon by the Scrum team at the Product Owner’s direction at the beginning of the sprint during a dedicated planning session.

It’s in this initial session when the team decides, based on their technical understanding of the requirements for a set of tasks, an estimation of how much time will be necessary to complete a particular sprint. If the estimation exceeds more than a few weeks, then the work may need to span more than one sprint. Completion of a sprint must always result in a “potentially shippable increment” of working software. The following three practices are a part of all successful Scrum teams’ workflows and if implemented within publishing teams, I believe they will also result in a similar outcome: a high quality “shippable” product and improved team dynamics based on a high level of transparency and communication.

Estimating

Estimation is admittedly a guessing game, hence the name. However, a good scrum master (in the case of publishing this would be the Managing Editor) will rely upon daily Scrums and retrospectives (more on those in a minute) and reporting to help better estimate toward the future. One such report, known as the burn down chart, tracks the estimated amount of time needed to complete the work at the beginning of the sprint on the x-axis and then projects a downward line as work is completed throughout the sprint, with the line ideally resolving at zero on the y-axis at the end of the sprint.

This chart is the tool by which a team’s ability to estimate is measured. With this information gathered and analyzed over time a good Product Owner (think: publisher) will be able to better forecast the necessary investments to complete versions, or titles, in order to meet the goals for the overall business.

In my experience working on and with publishing teams, the process of estimation is, for the most part, one that relies strictly on financial forecasting at the acquisition phase instead of incremental evaluation and adaptation in the way that Scrum does. At the beginning of a book’s life cycle the “Pub Board” as it is affectionately termed, performs a financial estimation plugging in numbers such as cost of goods, marketing, advance and ongoing royalty percentages as well as other line items along with a “guesstimate” of first year sales and a unit projection for a set number of years beyond that know only as “lifetime” or “balance.”

The cost side of this process is typically estimated based on actual historical figures as publishers typically have a good handle on printing, obsolescence, freight and other expenses. However, the guessing game around how many units a title will sell is always  just that. And in that way, publishers typically don’t employ the same decision making process as software teams when making decisions about future releases. Sure, many publishers employ the use of report cards that track projected vs. actual numbers, however this data seldom makes its way back to the acquisitions team in future rounds of projections. Instead, teams typically look on these numbers strictly as an indicator of past performance.

Overall, the evaluation of a span’s performance is primarily sales oriented and after the fact. Seldom do publishers take the time to consider the effect the publishing process, including the teams involved, have on a book’s ultimate performance.

How it’s done

By employing agile estimations in publishing, the Publisher and Managing Editor should gather all teams together at the beginning of a cycle/span to go through each release in detail, outlining the requirements. This meeting will take a number of hours to complete, planning at least an hour for every three titles in a span. During this meeting, the Publisher will detail the overall goal for each title, including its hook, target audience and projected sales volume. The managing editor will then go through the logistics and technical aspects of the book: timeframes, trim size, binding, etc. This process will give each specialized team an opportunity to ask any questions relative to their work as well as giving everyone an overall understanding of the role they play in the books success or failure.

Finally, all teams must agree to what success looks like for a finished span. This must be stated up front in order that the process and products can be evaluated at the end in order maintain continuous improvement.

By investing this time up front, publishers will see teams that are more personally invested in the overall success of a span and also take in qualitative feedback from team members that will help to better inform the process, including which books they acquire, in the future.

Daily scrums/standups

Publishing teams are notoriously siloed. This isolationist mentality has, quite frankly, gotten a bad rap. I, for one, am a firm believer in silos. As you can tell from the agile definition above, specialized teams are a prerequisite for agile methods to work, and in that way publishing closely mirrors software development. The problem most people often have with silos in publishing organizations is the all too familiar lack of communication that exists between teams when a project is deep inside of another team’s process. This is where the idea for “standups” comes in.

In agile organizations, teams working in the Scrum framework meet daily for fifteen minutes to discuss what each member of the team is committing to for that day. In publishing, those who would be mandatory at this meeting would be all team members responsible for a title or group of titles and it would be up to the managing editor to facilitate these meetings as a servant leader. This meeting is not a check-in to make sure folks are doing their jobs. Instead this meeting consists of three questions:

1. What did you do yesterday to help us meet the goal for this span?
2. What will you do today to help us meet the goal for this span?
3. What impediments are standing in your way from helping to meet the goal for this span?

This process serves to clearly communicate how much work has been done and how much work remains. It also helps everyone to clearly understand any impediments that are stalling progress, which will have impacts further down the pipeline. It is then the managing editor’s job to work on removing the blockers so that work can continue.

This practice of daily standup meetings will further enhance communication within silos as well as bring transparency to a book’s development and help to alleviate any frustration before it begins for those further down the line.

Reviews and retrospectives

A sprint review is conducted at the end of a sprint and it involves not only the Scrum team (in this case the Publisher, Managing Editor and teams responsible for doing the work) but also any other stakeholders such as Marketing, Sales and other Executives who are invested in that span’s goals and performance.

A retrospective gives the Scrum team involved an opportunity to unpack what happened during the previous release cycle or sprint. In publishing, this is a process that should take place for the entire publishing team responsible for the work involved in producing a span’s titles. The purpose for a retrospective is to understand not only what happened, but how can we learn from it and make improvements going forward. This includes not only evaluating the products that were created, but also the processes used.

As in all things agile, this meeting is democratic and the team as a whole decides together how the meetings should be conducted. Of course, it is of paramount importance that trust be fostered in these meetings, so this is an opportunity for everyone to be reminded by the Managing Editor that we were all rowing toward the same finish line and everyone did the best job that they could. This should be laid out up front, which will ensure that no one casts aspersions at any other team member and everyone stays focused on the objective, which is to learn and improve both product and process.

Wash, rinse, repeat

Once you’ve implemented these agile methods into your publishing operation and gone through a complete cycle you will be amazed at the amount of communication that goes on. Of course, in publishing if there is one thing we bemoan it is the number of random meetings we’re required to attend on a daily basis. By implementing agile methodologies, namely Scrum tactics into your systems, the need for ad hoc meetings should diminish as the communication lines will be far more open and frequent through a systematic approach.

Through repeated use of title span planning meetings, daily standup reviews and retrospectives, your entire publishing team will be in-tune to the goals and performance of not only the finished products but the process itself. This discipline will, by its very nature force you to see where improvements need to be made and with a savvy Managing Editor and Publisher duo you should begin to see continuous improvements in your team and your products’ performance.

BONUS

One final tactical tip for you. To aid in the daily interoffice communication, I would recommend you consider eliminating email and move to some type of enterprise IM tool such as Slack or Hipchat. These tools will allow you to group interoffice discussions into themed conversations, providing needed visibility to other team members where email does not. There is still the necessary direct messaging built in to provide for private conversations, as well as the ability (in Slack at least) to quickly call someone or start a conference call in a channel (the technical name for a themed conversation). This tool has become critical in the teams I lead and I believe it could be a huge help to your team as well.

¹ DISCLAIMER: It’s important to state right up front that these ideas are only pieces of the Scrum puzzle. True Scrum adheres to a whole host of rules and principles that when not executed entirely results in something less than Scrum. Because publishing houses typically work on spans over a period of a few months (spans), true Scrum is not an option. To that end, the following practices, while derived from the official Scrum Guide^TM, do not comprise all of Scrum. For more information on all things Scrum, jump over to scrum.org.

This article was written by Michael Covington. With a unique background combining more than 10 years in bookselling, 10 years in publishing and presently serving as a product manager for Disciplr, Michael has a one-of-a-kind perspective on the intersection of books, publishing and technology. Michael and his family live in Colorado Springs, CO where he invests his "spare" time helping publishers solve old problems with new solutions through his consultancy, FuturePub.