Topic sprints
The fastest way to deep dive into a topic
Written by
A method to get from vaguely outlined topic to a full-fledged report or even a book in just a day or two: Sounds too good to be true? Good news. This method exists. It’s called a topic sprint, and it’s a terrific way to learn, too.
So what exactly is a topic sprint? Think of it as a blended learning technique that’s part workshop, part collaborative writing exercise, part shared learning experience. Combined with a strong bias towards “shipping” — a term from the software development word meaning output, or just “getting stuff out the door” — topic sprints favor publishing over planning, producing copy over drafting outlines, peer review over control through external established publishers.
Before proceeding, why should you trust me? I’ve co-written two pieces through topic sprints: a collaborative report on health technology as well as a handbook for independent conference organizers. Importantly, other groups have written much more significant books this way:
- Labcraft, “How labs cultivate change through innovation and collaboration.”
- O’Reilly published their OpenStack Operations Guide, written through a book sprint.
- Social activists in Nigeria wrote a book about the country they know and love, Nameless.
- Cisco have written multiple manual using the techniques.
On one hand, topic sprints are a great way to create content quickly. One the other hand, they are a powerful peer-learning technique where the co-authors learn from each other by absorbing, editing and contributing to their peers’ area of expertise.
Understanding the topic sprint
To understand the world of topic sprints, consider their origin. Under the name of book sprints, this technique was pioneered by Adam Hyde to help software development teams produce documentation — traditionally the most boring part of the process of programming, and hence often done too rudimentarily to fulfill its job. Through a strictly moderated process that could run anywhere from a couple of days to a week, a team of software people (from programmers to product managers) would gather and, using a special open source collaborative writing software, produce a full-fledged software manual. By the end of the book sprint, a click of a button would be all it takes to publish the finished book online or export it to an on-demand publishing service.
The topic sprints we talk about today are variations of the book sprint technique: slightly less strictly moderated and independent of the original writing software that might or might not be the best fit for any particular sprint group.
Strengths & limits
Sprints have strengths and limits: they can be great tools, but aren’t fit for every context. There are some inherent principles that favor certain types of outcomes over others. Within this framework, it’s relatively easy to fine-tune the process to match various needs.
These unshakable pillars of the sprint are:
- A bias towards shipping. “Done is better than perfect,” as the saying goes. By the end of the sprint, the result is going to be published, no matter what. (Or handed over to a copy editor for final polishing, if that’s more your thing — but no more work should happen on the core content.)
- Strong focus on collaboration. This is a team exercise that lives on collaboration, sharing, and open exchange. Where there is too much ego at play, a sprint will not fulfill its full potential.
- Credit where credit is due. In a highly collaborative environment it is hard to give credit for any given word, sentence or paragraph. However, everyone working on the sprint or any of its chapters should be visibly credited.
- Peer review. No matter who’s the leading expert of the group for any given topic, chances are that others can add value and refine, both in substance and in style. Peer review and co-editing are at the very heart of the sprint process.
Now, within this framework we can move freely and adapt the sprint as it fits the group’s needs: is a day enough, or might it take a few days? Can everybody be in the same room or does someone contribute remotely? Which tools are easy to use for everyone so no time is wasted on learning new tools? This is something that should be determined before the sprint so the group can hit the ground running.
Then, on sprint day, take some time in the morning for quick introductions and drafting an outline with the whole group: which chapters are needed, how do they related to each other? Assign one “lead author” for every chapter / part. This should be the person with the most in depth knowledge of the topic covered as the sprint does not leave a lot of time for research. The lead “owns” the chapter for now, and will write the better part of it. This setup phase may take up about 15%-20% of the time. Getting the table of content right upfront is critical.
Then the writing begins: for a few hours, each author tackles their own chapter until the chapters get swapped from one author to another. The moderator should let everyone the remaining time — in the frenzy of writing under time pressure it’s easy to forget the time — then the chapters switch to new authors for adding, editing, polishing. Throughout the day it’s perfectly fine, and even encouraged, to ask others for input, to share thoughts. This gives the group an ambient feeling of what’s going on. A topic sprint is not the place for isolated, silent writing. Switching chapters also means that the overall text goes into the second iteration: by now, the basics should be covered. The experts had a chance to funnel their knowledge into one chapter, as short as it might be.
The next author reads their newly assigned chapter and starts adding. This is where the knowledge transfer starts getting intense: by engaging with the other authors’ parts of the text and adding more substance to them, the work grows — both in length and quality.
Then, finally, a third switch. Everyone takes a look at the larger picture, the whole text, adds and edits on the fly, rearranges. This is highly collaborative and can be a moment of intense discussions. In the end, the result will be much more consistent than intuition might suggest.
By the end of the day — or at the last day, in multi-day sprints — the final text is ready to export and publish.
Your sprint is over. And without even noticing, every author has gotten a high-speed, intense infusion of the other authors’ knowledge. Time for a drink and a healthy dinner.
The sprint format tends to seem somewhat chaotic. A good moderator can help keep it in check. Also, the open, sharing-oriented nature means authors are getting a lot of themselves out there: it can be an emotionally intense experience, especially for people who don’t often write collaboratively: embrace the creative chaos and everything that comes with it.
For a final polish, experience shows it can help to handing the final results over to a copy editor who is likely to still find some typos and maybe a redundant passage or two. Technically, that’s cheating a little, but that’s OK — as long as we all come out of the process with a solid piece of text and lots of new insights.
Originally published at mag.e-180.com on September 2, 2015.
e180 is a social business from Montreal that seeks to unlock human greatness by helping people learn from each other. We are the inventors of braindates — intentional knowledge sharing conversations between people, face-to-face. Since 2011, e180 has helped thousands of humans in harnessing the potential of the people around them, and we won’t stop until we reach millions.
