Corporate collaborative authoring

At FLOSS Manuals, we have been using a method called a Book Sprint –  collaborative authoring, one week at a time. In fact, Google’s “Summer  of Code” project has sponsored two of these sprints. The latest was  just this month for a completely open source video format called Ogg Theora. The sprint got a mention on slashdot last month.

The idea of a Book Sprint is that you can get lots of documentation written in a focused amount of time with the right team and some amount of content already in place. Gathering people in the same room when possible is extremely helpful and motivating as well. I like to think of it as using two wiki patterns – the Scaffold pattern first followed closely by the Barnraising pattern.

I often get questions about the viability and value of a book sprint in a corporate environment. Here are a couple of ideas for running a book sprint at a company.

Agile software development

In an Agile environment, the term “sprint” means a timeboxed iteration – a time period could be two weeks, or it could be three or four. You plan out the “sprint” based on the number of people you have and by correctly sizing the documentation goals for the sprint.

The term Book Sprint seems appropriate in an Agile environment. For example, plan the sprint to have the team focus entirely on doc for that iteration. That’s one company-type application.

Scenario-based documentation by Subject Matter Experts

Another company method of focused authoring that I know of is the one that IBM employs to write Red Books. A document coordinator brings in  the subject matter experts, they outline the RedBook in a day, then assign chapters to each Subject Matter Expert (SME). The SMEs usually go off and write for a while, then the RedBook comes back together with the document coordinator (I think this is accurate, but please do feel free to offer more detail by commenting).

Chris Almond gave a presentation at Central Texas DITA User Group meeting last year about using wikis for RedBook authoring – his slideshow is available on

Writer’s luxury accomodations – seclusion and focus with collaboration

For Book Sprints, what we do is try to get a good group of people a great place to stay for a week and write. There’s at least 4-6 weeks  of pre-planning of the outline and possible content that already exists so that the sprint itself goes smoothly. Getting people to agree to audience and scope ahead of time is crucial. A book sprint  basically forces documentation decisions and priorities under pressure of one week’s time – so you want to get lots of questions out of the way before the actual sprint.

We also make them fun and offer food and “after hours” activities. The fun is crucial!

I just joined the Writer’s League of  Texas, and they actually charge people for writing retreats that sound  an awful lot like a book sprint, except that they’re not collaborative, they’re for solo writers to get writing done in a nice, supportive environment. It’s basically a nice location with some fun planned in as well.

We have case studies and lots of planning in a Book Sprint book hosted on FLOSS Manuals at Also,  the free sample chapter from my book talks about Book Sprints at length, see, and shows how much funding we needed for a book sprint last August that produced about 300 pages of printed PDFs and online HTML-based help.


  • September 24, 2009 - 12:13 pm | Permalink

    Google is also sponsoring another one. We will do the Google Summer of Code mentoring Guide next month 🙂


  • September 25, 2009 - 8:15 am | Permalink

    Thanks, Anne, for a practical and useful summary of how collaborative authoring can work in the corporate world.

    Having worked on several IBM projects, I believe that your description of the RedBook process is accurate. The total time to produce a book varies, with six weeks being typical. (While the document coordinator is dedicated to the project, the SMEs are still doing their day jobs.)

  • September 25, 2009 - 8:20 am | Permalink

    Fantastic, Adam – I think that Guide will be very helpful.

  • September 25, 2009 - 8:22 am | Permalink

    Ok, thanks for confirming Larry! I had talked with a document coordinator a while back (Chris Almond) and thought I had an accurate picture of it. It’s good to know the length of the overall process. I wonder if there’s much post-production work on the deliverable? Then again, I doubt it because IBM has a lot of business processes in place that get those ducks in a row early on. 🙂

  • Pingback:   Weekly links roundup by Communications from DMN

  • Leave a Reply