Practical tips and/or guidelines
Open Access

Agile Writing for Busy Clinical Educators

David Topps[1], Rachel Ellaway[1], Janet Corral[2]

Institution: 1. University of Calgary, 2. University of Colorado Denver - Anschutz Medical Campus
Corresponding Author: Dr David Topps ([email protected])
Categories: Scholarship/Publishing, Continuing Professional Development
Published Date: 20/06/2019


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.


Keywords: collaborative writing


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.


Writing never has to stop ...

In order to have a doi and for most publishing processes, we have had to create a snapshot of where this document is at a certain point in time. The principles of the Digital Object Identifier (doi) are that the source no longer changes. And yet, this is also counterproductive to the Agile Writing process. So, while the version that you are likely reading now is such a snapshot, if you would like to see how the document continues to evolve, we invite you to check out the evolving version here:


If you would like to contribute to this process, see An evolving document section below.



Academic writing has been transformed almost beyond recognition in less than a generation. The late Umberto Eco’s wonderful 1977 text on writing a thesis (Eco, Mongiat Farina and Farina, 1977) is based on a world bounded by card indexes and typewritten manuscripts. Copies could not be edited except by Typex-ing out and typing over or by retyping whole pages or sections. There was no automatic spelling and grammar checking, no autoformatting, no track changes, no backups, very limited version control. Writing was primarily a solitary activity, although a professional typist may have been engaged to type up a handwritten draft. See Figure 1.


Figure 1: original page from the final version of my father’s PhD thesis, showing hand corrections, and paper so thin that the pages below show through. (Topps, J. H. (1956). Studies on the Fungicidal Activity of Certain Naturally Occurring and Synthetic Compounds. University of London.)


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 ( 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.


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 (, 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, consider this developer oriented article on Quora, a comparison to the traditional waterfall approach to programming.


Agile, as its name suggests, is more nimble and flexible, yet more resistant to being pushed off course. See  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:, 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.


Figure 2: the writing cycle

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 control -
    • which 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 ( 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)


Figure 3: screenshot from Google Doc showing Suggestions

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.


The downside to this approach is that the document can become pretty messy and hard to read. In Google Docs, you can flip to Viewing mode to temporarily hide Comments and Suggestions. In Microsoft Word, you can flip to viewing the Final document. However, we encourage authors to clean up their text droppings. Accept previous 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 spell-checking 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, 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, is easier to read than -- 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 -- more on the use of WebCite in a moment.


The other option is to use a URL shortening service. We quite like -- this is not as well known as, and others. But it has two advantages - you can easily create the custom URL you need e.g. points to the above ephemeral article. And you can edit the location that the shortened link points to, if you need to change it later.


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:

  1. Networked/online shareable database of citations
  2. Tagging - easy to use descriptive metadata about articles, that is searchable
  3. Cite-while-you-write -- from EndNote but most ref managers have something similar
  4. Markup/annotation that is robust across different markup formats, not just DOCX
  5. Easy capture from common sources such as Google Scholar, PubMed.
  6. Useful annotation of documents

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 cross-checking 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
  • 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 ( - 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. 

Notes On Contributors

David Topps, ORCiD:, Medical Director, Office of Health & Medical Education Scholarship (OHMES),, Professor in Family Medicine

Rachel Ellaway, ORCiD:, Office of Health & Medical Education Scholarship, Professor in Medical Education

Janet Corral, ORCiD:, University of Colorado Denver - Anschutz Medical Campus, Associate Professor in eLearning


Figure 1 is a public domain document, CC0, from my father's PhD thesis. 

Figures 2, 3 and 4 were generated by the lead author and are released under Creative Commons, BY-NC-SA. 

Figure 5 is from the cartoon series, xkcd at, by Randall Munroe, licensed under Creative Commons, BY-NC


Callahan, S. D. and Jonhson, B. D. (1996) ‘Dataset publishing–a means to motivate metadata entry’, in First IEEE Metadata Conference, p. 9. Available at:


Clapton, J. (2010) ‘Library and information science practitioners writing for publication: motivations, barriers and supports’, Library and Information Research, 34(106), pp. 7–21.


Eco, U., Mongiat Farina, C. and Farina, G. (1977) How to write a thesis. MIT Press. Available at: (Accessed: 1 May 2019).


Fallon, H. (2009) ‘A writing support programme for Irish academic librarians’, Library Review, 58(6), pp. 414–422.


Hawkey, M. (2001) ‘Joys, frustrations and concerns of a journal peer reviewer’, Journal of Nursing Management. John Wiley & Sons, Ltd (10.1111), 9(2), pp. 65–66.


Jones, J., Calvo, R. A., Yacef, K., Reimann, P., et al. (2011) ‘Collaborative Writing Support Tools on the Cloud’, IEEE Transactions on Learning Technologies, 4(1), pp. 88–97.


Li, Y. (2006) ‘A doctoral student of physics writing for publication: A sociopolitically-oriented case study’, English for Specific Purposes. Pergamon, 25(4), pp. 456–478.


Lowry, P. B., Curtis, A. and Lowry, M. R. (2004) ‘Building a Taxonomy and Nomenclature of Collaborative Writing to Improve Interdisciplinary Research and Practice’, Journal of Business Communication. SAGE Publications, 41(1), pp. 66–99.


Massy, W. F. and Wilger, A. K. (1995) ‘Improving Productivity: What Faculty Think About It—And It’s Effect on Quality’, Change: The Magazine of Higher Learning. Taylor & Francis Group, 27(4), pp. 10–20.


Newton, M. P., Cunningham, E. T. and O’Connell, K. (2014) ‘Counting the Cost: A Report on APC-Supported Open Access Publishing in a Research Library’, Journal of Librarianship and Scholarly Communication, p. eP1184.


Penn, J. (2013) How To Write More And Create A Daily Writing Habit | The Creative Penn, The Creative Penn. Available at: (Accessed: 1 May 2019).


Pepe, A., Cantiello, M. and Nicholson, J. (2017) ‘The {arXiv} of the future will not look like the {arXiv}’. Authorea, Inc.


Raymond, E. (2001) The Cathedral and the Bazaar. O’Reilly Media. Available at: (Accessed: 15 June 2017).


Roberts, R. (2013) Collaborative writing activities | elt-resourceful, elt-Resourceful blog. Available at: (Accessed: 1 May 2019).


Royal, K. D. and Lybarger, M. (2017) ‘On Algorithms, `Big Data’ and the Future of Psychometrics’.


Shenton, A. (2007) ‘Library and information research.’, Library and Information Research. Library and Information Research Group, 32(101), pp. 15–22. Available at: (Accessed: 18 June 2017).


Toolan, M. (2005) ‘Graded Expectations: On the Textual and Structural. Shaping of Readers’ Narrative Experience’, in Pier, J. (ed.) The Dynamics of Narrative Form: Studies in Anglo-American Narratology. de Gruyter, p. 272. Available at: (Accessed: 1 May 2019).




There are no conflicts of interest.
This has been published under Creative Commons "CC BY-SA 4.0" (

Ethics Statement

No study subjects. Ethics not required by our local IRB.

External Funding

This article has not had any External Funding


Please Login or Register an Account before submitting a Review

Ken Masters - (15/10/2019) Panel Member Icon
An interesting paper on “Agile writing” for busy clinical educators, dealing with technical tools to assist with collaborative writing.

The authors rather cleverly begin with a demonstrations of one of the main problems or dilemmas of modern academic writing – on the one hand, we need to have a single set document to which we can refer (and we currently do so through a DOI), but, on the other hand, good writing never stops, and one of the strengths of the electronic world is that writing can be improved and updated on the fly, so we also require document fluidity.

The authors base their notion of “Agile writing” on “agile programming” (or, perhaps more correctly, “agile software development”)

Some issues that need addressing:
• The concept and terminology of Agile writing need to be explained. I realise that the authors place links to various sources, but it is not fair to expect the reader to have to consult those sources in order to understand the basics of the paper. Consequently, terms like Scrum and Sprints (in this context) need to be clearly defined before they can be used. The value of the paper lies in its novelty, but this very novelty requires the authors to lay out a very careful explanatory path, or else the reader is quickly lost. For this, it would be useful if the authors could have their paper commented upon by someone unfamiliar with the concepts, to determine the level of understanding.

• Similarly, side references to sites requiring knowledge not normally associated with medical education should either be avoided or explained in more detail. A statement like “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.)” leaves most users no more the wiser and asking questions like “What is GitHub, and what does it have to do with medical education and medical writing?” This reliance on expertise outside medical education continues throughout most of the paper, but I shall not labour the point – again, I would urge the authors to have a medical educator not acquainted with the terminology to read the paper, and then allow for a revision and explanation of the terminology.

• Some statements need support: “While Microsoft Word has some excellent tools for collaborative markup and authoring, very few academic writers make good use of these.” This is a very generalised statement (what is “very few”) and where is the evidence for this statement? Similarly, claims like “many collaborative writing tools are not effective at handling this dual process, as are many authors” might be based on the authors’ personal experience, but may not actually be widely correct. It would be useful if the authors could go through their paper and look for other similar statements, ensuring that they are well-supported.

• “Is this something where the Github paradigm…” I think this is supposed to be “This is..”

Overall, I think that the authors have a wonderful idea, and have found value in using a range of tools, and their experience is invaluable for medical (and other) writers. Unfortunately, however, the paper is written in such a way that much of the message is impenetrable, and I would imagine most readers’ eyes glazing over in a fog of confusion. The authors really need to consider their audience: if they are assuming high expertise, then the paper has little value because all of this is known; if they are assuming less expertise, then the paper has little value because it cannot be understood. My low score for this version of the paper is not based on the information in the paper, but rather on the manner of presentation, and the resultant negative impact on its value to medical educators who could benefit most from using these tools. I really would like to see a Version 2 of this paper in which the authors err on the side of simplicity (ELI5) rather than assume so much from their readership.

Possible Conflict of Interest:

For transparency, I am an Associate Editor of MedEdPublish. However I have posted this review as a member of the review panel with relevant expertise and so this review represents a personal, not institutional, opinion. I have also collaborated with some of the authors on previous projects.

Kieran Walsh - (04/07/2019) Panel Member Icon
This is an excellent article on a topic that is traditionally ignored. Educators and researchers are usually just assumed to be able to write and rarely get any guidance on how to write – as an individual or as a team member. I think that the team who wrote this piece could have added more on the types of articles that this type of writing might work for and the types that it might not work for. I think that it would work well for a “12 tips” type of article – where each team member can work on different tips. But I am less convinced that it would work for a research study or a systematic review or a meta-analysis. These latter papers are more complex to write and sometimes need to be written sequentially. For example, in the case of a research study, you can’t write the discussion until the rest of the paper has been written. I think that the task will sometimes drive the required behaviour of the team. A relay team must have different skills to a rugby team. Some types of paper need to be handed sequentially from one author to the next.
Alexander Woywodt - (28/06/2019)
Topps and colleagues write for an audience of academic leaders and faculty in education. They point out that most publications in medical education are constructed in a very traditional way. They also note that only a generation back publications were often written by one person and typed on paper. I really like their figure 1 which illustrates this beautifully. More recently collaborative writing has evolved in many other fields of science and also in the corporate world with collaborative writing of software as a prime example but most authors in medical education haven’t really acknowledged this trend. They may therefore make their own life and in particular writing publications more difficult and time consuming than it needs to be. I think the main strength of this paper is their original idea and the fact that it provides food for thought for busy educators who want to publish. Some of the main text however I thought was a bit complicated, wordy and difficult to understand such as the paragraph on hypertext and figure 5. I wonder how accessible this paper is for less tech-savvy colleagues or older faculty, I think sometimes a bit more basic explanation would help. Finally I also wonder how useful this will be in the real world: For most of my publications the team would typically split the work into chapters assigned to authors with some form of agreed hierarchy ie the first author brings it all together and the senior author gives it direction and drive, works on an amalgamated draft and resolves conflict and disagreement among the authors. I was struck by the authors admission that their approach will work well only if the authors essentially trust each other and I can see how it work really well for a group of authors who know each other very well. In any case I thought this was an interesting and thought provoking paper and worth reading for educationalists who publish regularly.
Prerna Agarwal - (20/06/2019)
It is an interesting and useful piece of writing. It provides practical tips on collaborative writing: summarising the different ways in which authoring could be done by a team. Just a little reservation of it appearing somwwhat wordy while reading.