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
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 make sure 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
I developed a second methodology for the design and development of open source software. This facilitated, and collaborative, methodology is called the ‘Cabbage Tree Method’ (CTM) and it means facilitating your community to develop a product in a series of facilitated Design Sessions. In these sessions the use case specialists (‘users’) articulate the problems they face, and then design the solution.
A diversity of stakeholder input makes for better products. This is not a new idea in the world of product development since Ikujiro Nonaka wrote about the ‘new new product development game’ in the 1980s. However, this kind of diversity and ‘use case specialist’ focus has been largely absent from the open source sector.
CTM is sensitive to open source culture, while helping those projects shift away from technocratic meritocracy that ‘deliver users a solution’ and towards building solutions designed by the ‘users’. CTM is also designed to include all stakeholders in the process in an equally valued way – users, production staff, higher management, graphic designers, user experience designers, developers and others that are involved in producing the solution.
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.
I have used this process to open source platforms for the University of California Press, Wormbase, Collabra Psychology Journal, and other (more informal) contexts.
The latest facilitation methodology I have developed brings much of what I have learned about systems design, technical workflows and facilitated collaboration through Book Sprints to my recent work in publishing (at this moment this process is tested only with publishing staff, but I believe it has far wider applicability).
Many publishers are struggling with slow and impractical workflows and they want to use technology to improve them. However the typical way a publisher would go about redesigning a workflow would be to employ someone external, or re-deploy internal staff, to do a workflow audit – interviewing all parties, create a report with flow diagrams, and then use this as a basis for the developers to imagine a better way of doing things.
It is a very linear and disconnected process, and it takes a very long time. I’ve seen it take 3-9 months. Workflow Sprints starts with the premise that the people who know best about the workflow and how it needs to change are the publishing staff. So a workflow sprint gathers the relevant staff in a room for a day to redesign the workflow together. This process effectively reduces the time required for the initial designs for a publishing system down from 3-9 months, to 1 day.
I have employed this method with the the European Informatics Institute, Wormbase, the Organisation for Human Brain Mapping , Erudit, ArXiv.org and others.