Facilitation I see as the key to effective collaboration. Facilitation is also widely misunderstood. When I talk about facilitation I don’t mean running fall-off-the-table-backwards trust games and group hugs where the only outcome of 3-5 days is a good feeling. I am talking about leading a group through a rapid collaborative process that produces an end-product, a concrete outcome. This kind of facilitation is quite different to the norm. The facilitator has to manage power dynamics and level internal organizational hierarchies, actively facilitate discussion and rapid ideation, draw out participant expertise and generate consensus, while at the same time driving the group through a compressed product development timeline.
I have designed three facilitation methodologies to this end and they have a few things in common:
- they produce concrete end products
- a focus on efficiency and speed – generating radical efficiencies
- they generate deep, immersive, collaboration
Book Sprints
A Book Sprint brings together a group of experts to produce a finished book in 3 to 5 days. No advance preparation by participants is required. The group settles on a shared concept for the book on the first day, mapping out the possible content areas. They then write, review and rewrite each others work, going through a number of steps, gradually refining the content until it starts to forms a unified narrative. The entire process is held together by the facilitator who guides the group and coordinates the remote production team so that the outcome on the last days is a reviewed, edited, illustrated, beautiful book ready to print.
How do you get 10-5 people who might not know each other, to write a book collaboratively in 3-5 days? How does that happen? Enter the facilitator.
The facilitator governs the process, manages the group dynamics, mediates disagreement, and imposes the unalterable deadline for the finished book. The facilitator never takes part in actual writing, nor does he or she weigh in with opinions about the content. Instead, the facilitator enables an environment in which the group can collaborate deeply, creatively and purposefully. The aim is to ensure that all participants collaborate in sharing their ideas and shaping the development of the book. Using a light-touch approach and taking care to accommodate different personalities and styles, the facilitator leads the group through different stages of the book’s development, from conception to production, through to completion.
I started experimenting with processes for rapid content creation when I was running FLOSS Manuals and needed a lot of software documentation written quickly. The first Book Sprint I did was in 2008 and although it didn’t really work at first I became obsessed with the possibility that it could. I chiseled away at the methodology for four years before I felt like I understood it well and could replicate it successfully each time. At that moment I turned my energy to training some more Book Sprint facilitators.
Book Sprints Ltd is now a company with a team of 8 facilitators, book-production professionals, and illustrators. While I developed the original methodology the company has refined it since 2008 through the facilitation of more than 120 Book Sprints.
The company has worked with many clients to produce a wide variety of content, including corporate documentation, government policy, oil industry training materials, textbooks, handbooks, white papers, academic articles, and even fiction! Clients include Cisco, Dell, F5, Google, USAID, UNECA, The World Bank, IDEA, GIZ, Open Oil, Transparency International, Columbia Vale Center, Heinrich Böll Stiftung Nigeria, OpenStack, Free Software Foundation, Mozilla, PLOS, JISC CETIS, BCcampus, Responsible Data, Times Up, and many others. You can see photos from many of these Book Sprints here – https://www.flickr.com/photos/129798087@N03/albums
Cabbage Tree Method
The Cabbage Tree Method (CTM) is a method for designing and building open source software products collaboratively with a diversity of stakeholder inputs. I envision it as an entirely new way to build open source software solutions. In a typical open source software design scenario, products are designed by developers ‘with an itch to scratch’, to use Eric Raymond’s phrase. The developer has an idea or sees a need and they know other developers who have a similar need and thus a community around a particular product grows to build and maintain it.
I call this the developer-centric model. Developers articulate the problem and design and implement the solution. However this does not necessarily result in the best products. Good design rests on a very intimate knowledge of the problems. And when it comes to software, it’s far easier to get someone who knows a problem very well to design software than it is to get someone who knows software very well to understand the problem.
CTM has this principle at its centre. It shifts the power away from the developer and opens up the design process to a larger group including UX and UI specialists, designers, project managers, documentation people and developers. Critically someone plays the role of the “use case specialist”: the person who has the need for a certain software. This role is never played by the developer. The developer is not placed in a role of supreme power but just one of the group, their skillset on a par with what everyone else brings to the table.
Involving a wide range of people with differing perspectives improves the product but collaboration of this kind doesn’t ‘just happen’ hence – the facilitator. The facilitator leads members of the open source community through a process that builds trust, respect for each others perspective, and the product they need. CTM typically begins with a strongly facilitated session with the whole group to articulate the problem and build consensus on what a solution could look like. The group sketches out prototypes for software solutions which the facilitator then takes to the developers together with use-case specialist to start building. The process after that is iterative over time where the group gets to test and influence the continued design process towards an elegant software solution.
There is a theory of change, based on Rogers’ Diffusion of Innovations, underpinning this methodology too. The “use case specialists” immediately become invested in the product they help design, they become the early adopters of the product and then go onto advocate for it in their sector, influencing others to adopt. This is how outside innovations become mainstream. This aspect could be a huge benefit to the open source software movement. Software built this way not only results in better solutions and contributes to internal culture change in the organisations where it’s used; it has the potential to create sector wide change.
I have used this process to open source platforms for the University of California Press, Wormbase, Collabra Psychology Journal, and other (more informal) contexts.
I also wrote about the Cabbage Tree Method.
Workflow Sprints
The most recent facilitation methodology I have developed is being used to help publishers design their ideal production workflow involving all the necessary stakeholders such as editors, proofreaders, designers and reviewers. So far I have only tested it out with publishers but I believe it has a far wider applicability for different sectors and their specific workflows.
The problem in the publishing sector is that publishers have never been given the opportunity to design their workflow. Their workflows are defined by the platforms they use instead of the other way around.
Due to the poor design of these platforms, publishers struggle with slow and impractical workflows. When there is a decision to optimize the workflow, the typical process in the sector goes something like this: someone outside the organisation will be hired, typically a UX person or a developer, they talk to everyone in isolation over 6 months. Then they draw a flow diagram, and suggest to build the technology to support that. Not only is this process slow (I have seen it take as long as 9 months) and expensive, the software emerges with the same kind of problems as before.
Workflow Sprints bring all the stakeholders into one room based on the premise that publishers know their own workflow best and collectively will design something far better than any develop or workflow auditor could. In one day I take them through a process where they are first liberated from the way they have always done things. They are empowered to imagine a new workflow which would best suit the different phases involved in publishing a manuscript or monograph, not the platform they use. They sketch it out and go through multiple iterations, testing it out on each other (only with paper and pens at this stage!) and end up with high-level architecture which can be then used in development.
It has been incredible to work with publishers and see them taking ownership over their workflow. The editors from the University of California Press are incredibly proud of the platform Editoria that they helped create and are also invested in reporting bugs and improving the platform which they use in their day-to-day work.
Workflow Sprints can be used either together with the Cabbage Tree Method as we did when building Editoria or alone, as a way to generate initial designs for a new publishing system, which can then be given to developers. The best thing about the process is that it achieves in a day what would typically take 3-9 months.
I have employed this method with the the European Informatics Institute, Wormbase, the Organisation for Human Brain Mapping , Erudit, ArXiv.org and others.
