With Agile project management techniques being used increasingly beyond their original area of programming and software development, a lot of programming concepts are being adapted and reused in different fields. In this post, I briefly discuss the concept of pair-programming and how it can be applied to the field of content production as pair-writing.

What is pair-writing?

The idea of pair-writing stems from a technique used in software development and coding called pair-programming. While using this technique two coders – or, in the case of pair-writing, two writers – sit side by side and work in a file together. Turns are taken where one person types, the other watches and comments, and they swap roles periodically as progress is made.

These two roles have been referred to as “driver” and “navigator”. If you’re interested in how this might look, you should dip into parts of the hour-long but fun demonstration of how pair-programming actually looks in practice at the YouTube channel FunFunFunction.

In pair-writing, the pairing is often between a dedicated content officer or writer with experience of the medium or channel for which the content needs to be written (for example, the web) and a subject-matter expert who has domain knowledge of the topic of the content. It’s still possible to swap the driver and navigator roles in this situation. But the different experiences and perspectives that each partner brings help to hone the writing.

The traditional approach

At the Agile Content Conf 2016 in London this February, Rebecca Mallon, the BMIS Editor at UK’s Citizens Advice Bureau, gave a talk on her and her colleagues’ experience of using pair-writing.

You can view Rebecca’s useful talk on pair-writing for yourself but I found it useful enough to want to record the main points I took away from it.

Traditionally, as Rebecca described it, when producing content on behalf of a subject-matter expert, there are a few stages:

  • Subject-matter expert would produce a draft
  • The Content Team would edit that draft
  • The content might end up going through a few drafts, going back and forth
  • Misunderstandings would develop, largely by email
  • This would lead to frustration, misunderstandings, even offence, and only rarely to a form of content that both sides were entirely happy with

The benefits of pair-writing

By sitting side by side to write one can immediately see an efficiency in the sense that collaboration is happening in person rather than being lost in the email trail.

Rebecca Mallon described how engaging in pair-writing help both sides immediately realise their different approaches to creating a piece of content, which in itself is useful for communication purposes. What were once assumptions about the “best” way to write a piece are implicitly challenged and a better understanding and relationship is developed.

Rebecca herself said she had encountered differences in the way subject-matter experts related to this approach – she described the contrast between one subject-matter expert who was very much engaged in design and presentation and another who just wanted to talk.

In any case, the activity allows a relationship and trust to develop between both sides.

My own experience

I find it interesting that this technique developed in programming and then content production – or, more precisely, it evolved around the activities of coding and writing both of which are traditionally viewed as solitary, whether that perception is accurate or not.

I actually have more experience of pair-programming than I do pair-writing. One project I worked on years ago had me and a colleague sit in a room together for some eight hours switching between driver and navigator roles to get a product ready for testing. You can actually still access my very old post on the experience of pair-progamming and you can see the eventual product in this short, low-quality video demonstration of the e-portfolio feedback widget we produced. I remember some specific eureka moments that the process led to, and feeling like we were both learning about what it was we were actually producing as we were working on it.

I’ve only used pair-writing very minimally myself and we haven’t embraced it properly yet in the Content Team I work within. We’ve begun to experiment with it on some content with Marketing Business Partners recently. And we have occasionally used it in the more difficult emails we need to write to subject-matter experts.

The experiences described by Rebecca at the beginning of her talk resonate strongly with me as very similar to experiences we’ve had in our Content Team. So I think it’s going to be something we explore a lot more in the near future.

Rebecca’s top tips

Rebecca had three tips to give at the end of her talk:

  1. Make it work for you – don’t get hung up on a “proper” way to pair-write. Rebecca and her colleagues originally ran the practice with more than two people, thus breaking what one might consider a fundamental rule of pair-writing! “Whatever works” is the recommended spirit.
  2. Promote the practice by choosing allies to work with first. Involve your allies in user testing too, to get honest rather than combative responses. Use those experiences to promote the practice to others.
  3. Brief the subject-matter expert to establish ground rules first. Rebecca found that between pair-writing sessions with colleagues, the subject-matter expert might have gone into the Google Docs file they were using and made some changes alone, which then made subsequent meetings more about catching-up and defending positions. Establish what should and shouldn’t be acceptable up-front.

There are also some really useful pointers on getting started with the process in a GatherContent blog post on pair-writing by the Agile Content Conf organiser Jonathan Kahn.

Coming soon…

Since I attended the Agile Content Conf in Febuary, I’ve had some notes stored up for a while, waiting to be turned into blog posts. Watch this space for posts on user stories, user research and my experience of the conference itself.