Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

January 10 2012

How agile methodologies can help publishers

Agile methodologies originated in the software space, but Bookigee CEO Kristen McLean (@ABCKristen) believes many of the same techniques can also be applied to content development and publishing workflows. She explains why in the following interview.

McLean will further explore this topic during her agile methodologies presentation at the upcoming Tools of Change for Publishing conference in New York.

What is an agile methodology?

KristenMcLean.jpgKristen McLean: An agile methodology is a series of strategies for managing projects and processes that emphasize quick creative cycles, flat self-organizing working groups, the breaking down of complex tasks into smaller achievable goals, and the presumption that you don't always know what the finished product will be when you begin the process.

These types of methodologies work particularly well in any situation where you are trying to produce a creative product to meet a market that is evolving — like a new piece of software when the core concept needs proof from the user to evolve — or where there needs to be a very direct and engaged relationship between the producers and users of a particular product or service.

Agile methodologies emerged out of the software development community in the 1970s, but began to really codify in the 1990s with the rise of several types of "lightweight" methods such as SCRUM, Extreme Programming, and Adaptive Software Development. These were all rolled up under the umbrella of agile in 2001, when a group of developers came together to create the Manifesto for Agile Software Development, which set the core principles for this type of working philosophy.

Since then, agile has been applied outside of software development to many different kinds of systems management. Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project. At the end of the day, it's about getting something out there that we can test and learn from.

How do agile methodologies apply to publishing?

Kristen McLean: In relation to publishing, we're really talking about two things: agile content development and agile workflow.

Agile content development is the idea that we may be able to apply these methodologies to creating content in a very different way than we are traditionally used to. This could mean anything from serialized book content to frequent releases of digital content, like book-related websites, apps, games and more. The discussion of how agile might be applied to traditional book content is just beginning, and I think there's an open-ended question about how it might intersect with the deeply personal — and not always quick — process of writing a book.

I don't believe some of our greatest works could have been written in an agile framework (think Hemingway, Roth, or Franzen), but I also believe agile might lend itself to certain kinds of book content, like serial fiction (romance, YA, mystery) and some kinds of non-fiction. The real question has to do with what exactly a "book" is and understanding the leading edge between knowing your audience and crowdsourcing your material.

Publishing houses have been inherently hierarchical because they've been organized around a manufacturing process wherein a book's creation has been treated as though it's on an assembly line. The publisher and editor have typically been the arbiters of content, and as a whole, publishers have not really cultivated a direct relationship with end users. Publishers make. Users buy/read/share, etc.

Publishers need to adapt to a radically different way of working. For example, here's a few ways agile strategies could help with the adaptation of a publishing workflow:

  • Create flat, flexible teams of four to five super-talented individuals with a collective skill set — including editorial, marketing, publicity, production, digital/design, and business — all working together from the moment of acquisition (or maybe before). These teams would need to be completely fluent in XHTML and would work under the supervision of a managing publisher whose job would be to create the proper environment and remove impediments so the team could do its job.
  • An original creative voice and unique point of view will always be important in great writing, but those of us who produce books as trade objects (and package the content in them) have to stop assuming we know what the market wants and start talking to the market as frequently as possible.


  • Use forward-facing data and feedback to project future sales. Stop using past sales as the exclusive way to project future sales. The market is moving too fast for that, and we all know there is a diminishing return for the same old, same old.

TOC NY 2012 — O'Reilly's TOC Conference, being held Feb. 13-15, 2012, in New York City, is where the publishing and tech industries converge. Practitioners and executives from both camps will share what they've learned and join together to navigate publishing's ongoing transformation.

Register to attend TOC 2012

This interview was edited and condensed.

Associated photo on home and category pages adapted from: Agile-Software-Development-Poster-En.pdf by Dbenson and VersionOne, Inc., on Wikimedia Commons

Related:

June 30 2011

How one newspaper rebooted its workflow with Google Docs and WordPress

Bangor Daily News Google DocsDigital media not only forces newsrooms to face economic challenges, but also workflow issues. In a recent post, Todd Benoit, director of news and new media at the Bangor Daily News addressed the root of the workflow problem in his newsroom:

Like many newsrooms, until very recently we were production heavy because we had to be. Moving stories to the web was a copy-and-paste affair, but that's not where the trouble started. If you begin with a print-directed front-end system, as we did, how does that system accommodate a story being updated from the field? Or how would the full possibility of story assets land online, to be chosen among for print? Even simpler: When do reporters add links? The answers, as countless journalists know, are: It can't; they won't; they don't. From there, it's all production, not creation.

The Bangor Daily News attacked the problem head on, incorporating Google Docs and WordPress into a new front-end system that handles the flow of news in the digital era. As Benoit describes the solution:

... the guiding ideas we have put into practice are to match the tool to the job we need done (rather than the reverse), reduce the number of steps required and anticipate how our audience will want the information next. And the cost should be next to nothing.

To find out more about how the project came about and how it works in practice, I reached out to William Davis (@williampd), the online editor at the Bangor Daily News and the architect of the new system.

Our interview follows.

How did you end up gravitating toward a Google Docs / WordPress / InDesign system?

William-P-Davis.pngWilliam Davis: My boss [Todd Benoit] has a great post on our dev blog on the topic, and I talk about it a bit on one of my blog posts as well.

We picked Google Docs purely for its ease of use and its collaboration tools. We wanted a place where reporters could work on their articles easily from wherever they are — we have quite a few bureaus, and our reporters often file from events. The collaboration tools are terrific and have really proved useful, for example, when we're editing articles on tight deadlines or when reporters are working on stories together. On Election Day we had three reporters at different campaign headquarters all working in one doc, and it went very smoothly.

We chose WordPress because we wanted a content management system (CMS) that allowed us to develop components quickly and easily. WordPress has a great API and it's very extendable — we've been able to easily change pretty much any part of the CMS without hacking the core, which allows us to maintain the integrity of the system.

Both systems are quickly evolving and pushing boundaries in their fields, without any prodding from us. WordPress has frequent updates that push the platform to a new level, and Google Docs' collaboration tools, for example, are second to none.

Finally, we chose InDesign because it is the industry leader in page design software.

TOC Frankfurt 2011 — Being held on Tuesday, Oct. 11, 2011, TOC Frankfurt will feature a full day of cutting-edge keynotes and panel discussions by key figures in the worlds of publishing and technology.

Save 100€ off the regular admission price with code TOC2011OR



What was involved in developing the system?


William Davis: We started development in August [2010] or so, and it's still ongoing. We launched things on a rolling basis by department, and started with sports, which turned out to be the hardest because it's the most complex. We then rolled out politics in time for the elections. We got the entire newsroom using Google Docs early this year.

The display desk transitioned to InDesign in April, and then earlier this month we finished the website transition and turned off our old systems. As we developed the components needed for each department, we would move them over, test and tweak things, and then move on to the next department.

What are some of the major challenges you've encountered?

William Davis: We've had a few instances where Google has changed the way they structure their content in Google Docs or changed the way a part of the API works and we've had to adapt. We've also faced the usual technical problems that come with hosting any large website, but we haven't really encountered any challenges that we weren't able to solve fairly quickly.

Some components we've rebuilt a few different ways and will probably rebuild again. The wire feeds are an example. Those were originally running directly into WordPress. We decided we didn't want to put the strain of tens of thousands daily stories and photos on our website and so we tried running the wires directly into Google Docs. We encountered problems there, as well. I`n the third iteration, which we're using now, we have a separate script that ingests the wires and provides a way to browse them, then sends the stories we want into Google Docs. That's worked pretty well, though that's not to say we won't rebuild that component or others in the future as needed.

The great thing about building our own system is that we can tailor it to our needs. Because we're doing it all in-house, we can change quickly, rather than waiting for a corporation to adapt with us.

Was it difficult for people to adapt to the new system?

William Davis: With a transition to any new system, there are of course going to be problems, but I think the ones we've encountered have been pretty minimal. Reporters seem to have had a pretty easy time adapting to writing in Google Docs — many of them, especially bureau reporters, were already using the system to write their articles. They understand why it's important to move content quickly through the system so their articles have the best chance to succeed online.

Can you give us a walk-through of the publishing steps involved — from story idea to final web and print versions?

William Davis: Reporters start their stories in Google Docs, and when they're finished, they drop them in a folder for their section — Metro, State, Business, etc. Editors read the story and move it on to a copy editing queue, where a digital desk editor reads it before sending it to WordPress.

In WordPress, the digital desk editors will categorize it, attach media such as photos and video, and then they will publish the story. This is done throughout the day — we have digital desk staff on from 5 a.m. until midnight. When the display desk comes in to lay out the paper, all they have to do is find the story in the InDesign plugin we built and bring it onto the page.

Everything comes onto the page fully formatted, though the digital desk is responsible for writing their own headlines for print. They can do this either on the page or in a module I built for WordPress that provides a WYSIWYG headline-writing interface.

Davis offers a tour of the new system in this screencast:

How many people actually touch the copy before it's published?

William Davis: As is the case in any newsroom, that varies by article. The digital desk editors, in addition to being copy editors, sometimes act as backfield editors, such as on the weekend. Other articles are seen by four or five editors before they're published. In general, though, articles go from reporter to assignment editor to at least one digital desk editor before being published.

How much manual labor is involved?

William Davis: We've managed to do away with pretty much all manual labor. Previously, all stories were written in our print CMS, and the web staff was responsible for copying and pasting the story into our web CMS, finding and adding links, writing a web headline and, quite often, doing that multiple times for the same story after it was updated. The copy editing was all print-centric, so at the end of the night, most of the stories would need to be updated. Now there's no copying and pasting — everything flows from one step to the next.



Related:


  • The line between book and Internet will disappear
  • Metadata isn't a chore, it's a necessity
  • Writing a Book with Google Docs

  • The secret to digital publishing success? Don't start with the book

  • Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
    Could not load more posts
    Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
    Just a second, loading more posts...
    You've reached the end.

    Don't be the product, buy the product!

    Schweinderl