Agile Writing for Busy Clinical Educators

Writing has long been a team sport – the concept of collaborative writing is not new but remains fraught with frustrations, poor processes and could learn from the software world. Not only are there now better tools and platforms to support collaborative writing, there are also lessons to be learned from other collaborative, creative processes such as software design. This paper explores some of the pitfalls of current practice and provides tips, based on our experiences as collaborative writers.


Introduction
Contemporary scholarship requires both collaboration with co-authors and time efficiency given multiple competing demands. This article explores agile writing as a way for busy clinician educators to participate in scholarly writing that doesn't require large blocks of time to be set aside for writing. Illustrated with concrete examples, we explore different approaches and tools, as well as ways to manage the writing process to ensure it is ethical and compliant with ICJME authorship guidelines.
Not only are there more and more tools to support academic writing, writing has become a team sport with many hands working on many drafts. Microsoft Word's tracked changes (and other variations in similar tools) are an essential part of writing. Indeed, many types of writing now demand a team approach: grant writing; report writing; presentation drafts. Despite the many tools available to authors, many of us still follow the round-robin approach of emailing a draft to our co-authors, then wondering who it will be who will be the next to edit. This can make writing a process fraught with delays and redundancies, not to mention clashing versions and the time it takes to resolve them and the frustration this creates. While publishing systems like ScholarOne (https://clarivate.com/products/scholarone) assist in the final steps of the writing journey, we still need to improve the writing process in the earlier stages of the authoring process. This paper reports on the challenges of collaborative writing and presents tools and approaches that have proved useful in facilitating the collaborative writing process.

Background
There are many interesting examples out there of how online collaboration has radically changed the writing process. Wikipedia and the wiki approach is now the most well-known example of group writing on a massive scale. The open source approach, so effective in the software world, has also been adopted in collaborative writing. One of the early and notable examples of this was 'The Cathedral and the Bazaar' by Eric Raymond. (Raymond, 2001) Interestingly, Raymond used the open-source process to collaboratively author this guide on how to make best use of the open-source process (http://www.catb.org/esr/), a lovely example of eating one's own dog food.
Clinician educators often have little dedicated time for writing. Committing large chunks of time to partners on a team can act as a demotivator. (Callahan and Jonhson, 1996) Most books and articles about being a more academically productive writer exhort you to simply commit some time to writing on a regular basis. (Penn, 2013) Once you get into it, without being critical of what the quality of that day is, it becomes easier to generate useful output of one kind or another. But this does not always work well for those who are trying to embed these activities into clinical work, which usually takes priority.
Some have explored the influence of virtual support groups -the importance of being able to collaborate remotely; in comparison, there is less likelihood of having authors with similar interests within the small local pool. We note the advice from Fallon with the Irish librarians and running courses (Fallon, 2009) -but this is not practical for many groups, especially in Canada where we are so distributed.
By setting up an environment where incremental contributions are possible, we are exploring how the writing process might be improved in efficiency and output.

Agile Writing
During the summer of 2015, our authoring group was working together on some rapid document and outline creation, using a variety of these tools, in real-time. As we crafted these documents back and forth, it became apparent that our writing process was somewhat similar to the process of Agile Programming.
The Agile method is more effective in programming -but then errors in programming are so destructive -whereas in collaborative writing, they are less so, or may even be contributory to the discussion. For those who are interested, Agile, as its name suggests, is more nimble and flexible, yet more resistant to being pushed off course. See https://blog.udemy.com/agile-vs-waterfall/ for more description of the factors for each approach. In this piece, the author does specifically comment on using the Agile process for technical writing -there are some useful points there.
There is even an Agile Writers club: http://agilewriters.org/, which may have already developed a similar approach to what we are describing, but they are less oriented towards the technical/developer aspects of writing. This is specifically aimed at novel writing, and does not seem to borrow many techniques from Agile programming.
Agile is more successful, faster but can be intensely time consuming in its Scrum phase. Sprints last one to four weeks, usually two weeks, and are not extended -what's done is done. Agile is more flexible but is also more susceptible to a programmer leaving the team. This would also be true of Agile Writing.
Just as with Agile Programming, there will be some debate as to whether the Agile Writing process is more efficient. We have not come across any comparative analysis of this. And it may be hard to generalize much from such an analysis, since it will all be highly context dependent.
In our experience, most academic groups follow a cycle similar to this when writing drafts of a paper or proposal. See Figure 2. This made sense when word processors and email were the predominant tools of the workforce. But now that we have so many other options, this may not be the best approach.

Downsides of the traditional cycle:
Version controlwhich is the latest draft? Conflicting edits and changes, which was huge in the software world, prior to good version control systems. (GitHub is now the predominant tool in this area.) The tedious task for the lead author of wrangling these changes Conflicting annotation styles While Microsoft Word has some excellent tools for collaborative markup and authoring, very few academic writers make good use of these. Separating the process from the content: many collaborative writing tools are not effective at handling this dual process, as are many authors. Embedding process commentary within the text narrative simply makes the process of text clean-up more burdensome. A transfer of energy demand from the lazy contributor to the overburdened editor/collator -this is not conducive to team effectiveness.

Version Control
Do you need scalable access control lists? Is this something where the Github paradigm for version control becomes useful. Note that Authorea (https://www.authorea.com) takes this path -however, while promising as an approach, with some very interesting pieces (Newton, Cunningham and O'Connell, 2014;Pepe, Cantiello and Nicholson, 2017;Royal and Lybarger, 2017) about this on the Authorea web site, there are quite a few limitations to this tool. This is worth keeping an eye on, but is still quite clunky to use.
How important are features like Track Changes? While it is nice to see what has been changed, it is also very time consuming to manage these changes across document versions, especially when documents get out of sync. In the interests of efficiency, we should be less concerned with Track Changes, given the time needed to recompile out of sync versions, and instead, make use of approaches that encourage the use of a single shared document, such as in Google Docs.
For some editing teams, it can be quite time consuming going through the back & forth of agreeing on every change, when generally these are of little consequence. Inter-author trust is a big factor here (see above).
A feature of Google Docs that is useful for collaborative writing is that it keeps track of the revision history. This is intrinsic to the software and does not have to be enabled. You can easily go back and review previous versions or even restore them. You can see the changes made with each revision. This saves the old problem of having to keep multiple copies of a document with different, and sometimes conflicting, version numbers, or even to have to devise a version numbering system that all authors will stick to.
Having a stable namespace also makes it easier to link to such articles from external sites, although Google Drive has circumvented this problem by making the reference URL and the document name independent.
So many academic authors are dreadful at using Microsoft Word's team writing tools properly. See our notes at ResearchGate --we find it surprising that, for the amount of time that they spend on collaborative writing, so few have taken the time to familiarize themselves with the most commonly used toolset.

Edits, suggestions, comments and tasks
To be efficient and effective, an agile writing team needs to establish some ground rules about how to write collaboratively. This is partly dependent on the toolset used: Microsoft Word's tools enforce a different approach from, say, Google Docs.
We did also perform some usability testing on OneNote -for those who are interested, we have some field notes at: 'Simultaneous edit test' (Web view) on OneNote. There were some potential advantages. Simultaneous editing does not seem to be a problem, except that it was more sensitive to network speed than Google Docs. But the big draw of simultaneous audio recording did not work well for Mac users.
Since, at present, Google Drive and its associated apps are becoming the most popular toolset in collaborative writing, we will focus primarily on this.
As noted above, having all changes and versions within a single document in the Google Docs paradigm does save a lot of time and hassle with version control. But it also takes a change in mindset -not everyone is happy to directly edit an existing document, and is more tentative in their suggestions. Remember that Google Docs has a built-in Revision History. Any author can at any point go back to see what was in there previously, rollback to a previous version, or retrieve deleted pearls. This flexibility is a game changer. You can all become more adventurous in changing the "master" document. (Figure 3)  The default mode in a Google Doc is straight editing, just as with any text editor. In a manner similar to Microsoft Word's Track Changes, you can change the editing mode in Google Docs to Suggestions -suggested text appears in a different color; the newly added text appears in the right sidebar, to be accepted or rejected or discussed.
Note that we had to create a separate screenshot of the above Suggestion and associated Comment, as they are not visible to anyone other than authors of the document. Now, here is where it sometimes comes down to trust and confidence in team members. Some authors happily overwrite each other's contributions. Some use Suggestions liberally. Some only use Comments. But do remember that it can be annoying for the primary author to have comments such as "This is ugly. Rephrase this…" -sure, we agree… so why don't you take a crack at it and see if you can improve upon it? Don't just be the critic.
Having participated in many different writing teams, this is easier said than done. Not all contributors may feel confident about what they are suggesting. Or they may feel adequate to critique but not to improve. We suggest that it is up to the team to generate such a participatory atmosphere, possibly in early team meetings. The primary author, particularly if they are a well-known authority in the area, should be encouraging to contributors to actually make changes.
It is also very helpful if the agile writing team agrees upon and is consistent in the manner in which they markup the document. This is what the Comments tool in both Google Docs and Microsoft Word is for. This is better than inserting notes and instructions directly into the body text. It is embarrassing to have reviewers ask for clarification on items such as "this argument makes no sense -we should change it" that sneak into a submitted article. Yet it happens all the time, and is even more embarrassing when everyone misses it and it appears in publication. With the gradual disappearance of copy editors from many journals, especially open access journals, this is going to be an increasing problem.
When you use embedded Comments, you can see if some still remain in the right side column. It is also easier to remove them with a single click, rather than having to perform the multiple clicks of cleaning up highlighting and text inserted into the narrative. We have commented on this elsewhere. changes before embarking on a new round of drafting. In Microsoft Word, you can accept all Tracked Changes at once. In Google Docs, you need to do this one at a time.
Some Comments generally will remain in place until late in the writing process. For example, we have found that it is generally a good idea to have a single person managing the references. (See Reference Management.) This can mean that your draft is cluttered with Comments containing references, which makes it harder to spot other outstanding items. We have not yet found a tool that helps to automate this process. We do suggest that the team agrees on some method of indicating which Comments still require attention at any given round of drafting.
In our own efforts, we have tried the following approach of combined colored highlighting and tagged Comments. For small groups and simple documents, this will be overkill, but it can save work in the mid-term: (see Figure 4)

Figure 4: coloured highlighting for action items
Now the downside to colored highlighting that is added on top of Comments is that it is a multi-step process to resolve, instead of a single click. We welcome other suggestions from groups who have found a more effective approach.

When is Agile Writing not a good idea?
If team members have a low level of mutual trust.
If the customer has a fixed idea of output and process/contract.
For some articles, having a consistent style is important. (We have had this criticism on two recent open access journal articles, with only two writers.) This would be more noticeable when the styles are more contrasting.
Efficiencies -it might seem at first glance to be less efficient (or anti-synergistic ( 1 + 1 = 1.5)) for two people to be writing side by side but this is not the case. (Roberts, 2013) Consider how much time is spent in collaborative writing on deleting paragraphs/sentences written by the other person. Much has been written in the software programming world on this debate, although there are few solid comparisons.
Part of team efficiency will come down to dividing up skills effectively (some will be better at looking up references or source materials; some will be better at crafting ideas on paper. Also cross-checking of work, intelligent spellchecking on the fly. See Building a writing team. We find it sometimes easier to talk and not write at same time; then take it in turns -as one is expounding/extrapolating/expositing etc, the other can filter these ideas down by scribing on the fly. This helps to avoid that phenomenon where somebody describes a great idea or concept then the other person says "can you write that down?" -sometimes the interruption in flow makes the idea or the spontaneously creative wording dry up. Another tool that would be helpful in such a regard, when the brainstorming is particularly intense, would be to use something like Microsoft OneNote and its ability (at least in the Windows desktop version) to record audio and timestamp/link the annotations to the audio track. Google Docs cannot do that. For now, the online simultaneous writing works well with simultaneously visible editing.

Hypertext
Hypertext, as in the original concept by Vannevar Bush, has become very commonplace now, such that we rarely think of its power. It is an incredibly useful tool, not just for cross-referencing to other materials, but also to allow various branches and sidebars to the main narrative. It has become so integrated with how we use online materials that it has changed the structure of the narrative completely.
Its free-ranging structure has become very popular but it also has the effect that it can be distracting, as summarized by Randall Munroe. (Figure 5)

Figure 5: the distractions of free ranging hypertext
The narrative pathway, and to what degree it should be constrained, is now the topic of some discussions and some excellent texts. (Toolan, 2005) Indeed, for some writers, there are a bunch of new and complex tools which afford greater power in hypertext narratives. E.g. Mark Bernstein's Tinderbox --this is a very powerful tool --too powerful for most writers but with much depth, which has created an intense group of devotees.
However, in its more basic form, the simple principle of hypertext allows us far more flexibility in document construction. It also brings some new challenges.

Linking with other documents
For the solitary writer, when referring to other documents on a single machine, it can be quite a straightforward process to hyperlink to another document or bookmark within a document. As soon as you have more than one machine, problems arise. Indeed, in some operating systems such as Microsoft Windows, even this simple concept presents problems. The file/folder structure in Windows assumes a static position so that, if a file is moved or renamed, the links break.
With the advent of the Web, we are now used to Uniform Resource Locators (URLs), but even these are not as uniform as they used to be. Indeed, it is a significant problem that many resource URLs are now generated on-the-fly by underlying content management systems and their databases, which creates one facet of the Deep Web. When you are going to publish a document that you expect to be referenced from elsewhere, we strongly suggest the use of PURLs (persistent URLs) whenever possible.
The good news is that cloud-based file systems and content management systems now generally provide PURLs. Google Drive, OneDrive and Dropbox do this with their shared links. Most systems are robust enough that these PURLs do not change, even if you move or rename a file. We strongly suggest that you do NOT link to a URL that is not persistent.
Linking to a file or entire document is commonplace. It can be harder to link to a specific location within a file. This is a basic premise of HTML, which has had anchors or bookmarks since the beginning. Microsoft Word and Google Docs both provide internal bookmarks that you can link to. We find it surprising how often this is lacking in other application software.
This is an important premise when linking into a document from elsewhere. Traditionally, many of us are used to saving multiple versions of a file, each with a different name, as we move through different drafts to a final publication. But this creates problems with external hyperlinks into our document -it should remain in a fixed location. Indeed, this is the very premise of the Digital Object Identifier (doi) system. Using the method described in the section on Version Control, where your document manages changes internally and remains in the same place, will help this.
Many of these hyperlinks can be long and complex. For some purposes, we do suggest that you consider humanizing these. You can use Pretty Links, a WordPress term for URLs that have been changed to something that approaches human readability. For example, http://crawwla.space/the-ephemeral-world-of-online-publishing/ is easier to read than http://crawwla.space/wp-admin/post.php?post=56&action=edit --and the irony of that particular link is that the day after writing, this web site is likely to die, leaving us with only the archived version at http://www.webcitation.org/6rrFG7GOW --more on the use of WebCite in a moment.
The other option is to use a URL shortening service. We quite like tiny.cc --this is not as well known as tinyurl.com, bit.ly and others. But it has two advantages -you can easily create the custom URL you need e.g. http://tiny.cc/ephemPub points to the above ephemeral article. And you can edit the location that the shortened link In the rapidly changing world of online publishing, it can be quite frustrating to find a location where you can post your materials and still have them available in months and years to come. And the corollary to this is that it is also difficult to refer to materials that you find on the web because, by the time your own article is published, the URL may no longer apply. The rather tepid workaround to this taken by most publishers is to cite the date when the author accessed this URL.
We recommend the use of an online web archiving service such as WebCite --this excellent service creates a PURL for your reference, but more importantly, it stores an archival copy of the content on their servers so that readers can see what the original URL pointed to. Some journals such as PLoS One now insist on such an archiving service.

Reference Management
One thing that would be helpful in this regard would be reference manager software that a team can use that has the following features: Networked/online shareable database of citations 1.
Tagging -easy to use descriptive metadata about articles, that is searchable 2.
Cite-while-you-write --from EndNote but most ref managers have something similar 3.
Markup/annotation that is robust across different markup formats, not just DOCX 4.
Easy capture from common sources such as Google Scholar, PubMed.
We have tried multiple reference management tools but none do all of these functions well. EndNote is commonly used but badly behaved and poorly designed. Mendeley has some of these functions. Zotero is cheap and browser friendly but not very robust. We have also found that authors tend to be quite loyal to the tool they use, no matter how faulty, so agreement within the team on this is not a given.
At present, with the plethora of reference management tools in play, and with how poorly they work together, it is usually better to (a) agree on a common method of annotation to mark where a citation is needed and what citation to refer to; (b) agree on a common method of annotation regarding the use of Embedded Comments or plain text highlighting or citation markup points that are inserted by the text editor itself; (c) assign the role of reference writer to one person only and send all references to him/her; (d) leave citation formatting and bibliography generation to late in the writing process, once all major writing and editing has been completed.

Building a writing team
What sort of members could you have on a team? This depends to some extent on the target document/activity. Academic papers will typically have a dominant author -consider to what extent does the declining power-of-two effect predominate (50%, 25%, 12%, 6%, 3% etc of the work)? Some documents like proposals need more crosschecking for detail accuracy in things like budgets.
Some documents, like proposals, have greater dependencies between components eg. it is hard to do a budget when the scope of work is not defined. However, in this regard, with grants, the budget is effectively pre-defined and therefore you are really budgeting to get the most product for the amount of funding available.

Roles and functions on a team:
It may be worth considering these and allocating these functions to those team members who are strong with that skill or are at least willing to take it on.

Lead author
Let's be honest. Most of the hard work is usually done by one person. It is helpful to have a single pilot at the helm Most journals require a single corresponding author Citations Send all references to this one person to collate Actual reference formatting is left to late in the process Truncator All drafts exceed their word limit (http://openlabyrinth.ca/the-topps-epigram-for-word-limi/ ) Some authors are better than others at whittling down the prose Plain Englishman This might be alien to some, especially in New York, but academic writing has a terrible tendency to drift into dense styling, sesquiconstructive obfuscation, passive voice and overly complex sentencing. Prize the person on your team who is good at making plain English sentences. Illustrator Great to have someone artistic on the team, but more often this entails a team member who can find relevant illustrations or create infographics. This function could also include checking copyright and licensing of source materials. Copy editor Role traditionally performed by staff at a journal Increasingly delegated to the writing team Cureus (http://www.cureus.com/) -this is now a requirement. Lead authors must certify that the manuscript meets quite exacting standards of formatting Citation formatting Decide whether this is performed by the Copy Editor or the Citations editor The use of reference management software makes it easier to change the citation style when needed but the writing is smoother if you consider this ahead of time.
How to format online materials. An increasing number of journals insist on the use of WebCite. Highly recommended but this does require some extra secretarial work If you don't use some sort of archiving service, your online citations will be at risk for future use.
Some of these functions can be delegated to research administrative staff. To make best use of such staff members, it is important to train both them, and the authors who have access to them, so they are not working at cross purposes. It also helps to have a core set of target journals and repositories that are generally used by your group so that the admin team knows what is generally expected.

Technical Tools for Agile Writing
See our notes at 'Tools to support Agile Writing' for more about these software applications. There is also an interesting report by Jones et al about iWrite, which has some quite advanced features. (Jones et al., 2011)

Barriers to productive writing
We would be interested in your thoughts on what gets in the way of being more productive as a writer, particularly from those who are involved in medical education scholarship.
If you have a spare 5 minutes, check out our survey and contribute to the process.
We checked to see if this has been done before -there are a few general papers on the writing process, but no survey that we can see. (Massy and Wilger, 1995;Hawkey, 2001;Li, 2006;Shenton, 2007;Fallon, 2009;Clapton, 2010) All seems to be based on expert opinion.
One of the odd behavioural effects that became apparent in our collaborative writing efforts is that the time pressure to contribute is lessened. You might think that this is a good thing, that you would be able to contribute when you have time/energy/inspiration rather than being pressured because the ball is in your court. However, the opposite effect has been noticed by many writing groups. Without the pass-the-parcel effect, then it is all too easy for the ball to be dropped (mixed metaphor alert). It seems that many of us need the pressure of a deadline or peer pressure when it is our turn. Otherwise, "more important" or pressing tasks take precedence.
There is a workaround to this called Sequential Writing (Lowry, Curtis and Lowry, 2004), where each person gets a defined time slot in which to contribute. If they miss this slot, the process moves on regardless and their contribution is missed. In some writing platforms, such as iWrite, this can be partly automated. (Jones et al., 2011) An evolving document As we noted in our sidebar above, this will continue to be an evolving document, with ongoing contributions from an agile team. You can view the latest version here.
If you would like to be part of the author team that is maintaining this document, and associated materials, please contact us here.

Take Home Messages
Collaborative writing can be hugely productive but can also be a mess if you don't organize your processes.
Software tools can help manage collaboration but it is more important to organize your team and your processes.