Production Facilitation

I had an interesting chat with Dirk Slater from Fabriders yesterday. It was a live online interview/discussion about the work I’ve done since FLOSS Manuals which I started 10 years ago.

Here are a few points I want to distill out from my experience evolving the Book Sprints, the Cabbage Tree Method, Workflow Sprints and others…

  1. Production Oriented Facilitation is not the same as ‘unconf’ Facilitation
    I like to differentiate facilitation of processes that produce products over a fixed timeline (books, software, workflow designs) from the typical kind of facilitation related to unconfs (etc). They are not the same thing, the former employs some of the tools of the later but also has tools of its own. Importantly, if you bring a (dare I call it ‘too respectful’) unconf tone to a production processes, you won’t get anything done. So don’t expect because you can do unconfs, that you have the tools and right approach to facilitate production processes. Mistaking one for the other is a category mistake.
  2. Remote Facilitation doesn’t work
    Facilitation of production events of the type that enjoys radical efficiencies like Book Sprints is not something you want to do remotely. You can’t get the same attention and commitment. Nor can you get the ‘full spectrum’ communication between all members of the group that you need if you are working remotely. At Book Sprints we believe this so much to be the case we don’t like to have even one person working remote.
  3. Not everyone is a facilitator
    Facilitation is one of those skills that people think they can ‘just do’. Doesn’t need any ramp-up time or experience, its just someone telling everyone else what to do in a ‘nice way’ right?… I have seen this time and time again. If you think like this, thinking you can facilitate with no experience, then you are at a bad starting point because it is clear you don’t know what facilitation is. Don’t experiment on your friends, family, or colleagues if this sounds like you.
  4. Good facilitation can only be learned by experience
    Experience is the only way to learn to be a facilitator. You can’t learn it from a book. So how do you learn? By apprenticeship. Find a mentor that can take you through the process in situ. It is the only way. Don’t expect it to be a quick process.
  5. Technology is not the answer
    So many times I have people ask me what tools Book Sprints uses. What is the software? It is not asked from the position of trying to make sense of the ecology of items that are needed as tools, it is asked in the Silicon Valley sense of ‘software solves everything’. Book Sprints is not about the software. Its about the methodology and the facilitation. We could do Book Sprints without the tech we use (and we have in the past). But if you believe you just need to install the software and stand back and watch the magic happen, then you are wasting your time. Sure the software helps us run things smoothly, but it does not automagically ‘provide’ a Book Sprint.
  6. Don’t put people in a room and expect it to work
    In the case of Book Sprints I have seen many orgs try and emulate it by just putting a whole bunch of people in the same room and expecting the magic to happen. If you have tried this, I know you have failed. It doesn’t work and you are missing the point. It’s all about the facilitation.
  7. A method is a compass, not a religion
    Facilitation methodologies are not religious texts that must be followed to the letter. Unfortunately that is how too many book-learning facilitation courses approach facilitation. It’s very sad to see.  Methods are instead merely navigational instruments. However, they are useless in the hands of someone that does not know how to use them. You need to be an experienced facilitator, with experience of that particular method, for everything to work. A facilitator who is experienced with a particular method and knows how to use it will not only be amazingly good, they will also know when the method doesn’t give them what they need, and how to improvise towards true north.

And as a last coda, a note on who makes a good facilitator… I do believe some people, through a combination of nature and nurture, will make excellent facilitators, while others should really not even attempt it. I must say that this is a very hard thing to determine before training someone. I have some clues as to what qualities may contribute to being a great facilitator but it’s still largely a mystery to me. You never really know it until you see it, which is why I prefer to train people with the option of stopping if I can see it won’t work out.

I will say however, that I have found that most unconf facilitators do not make good ‘production’ facilitators. My best attempt to understand this hasn’t got me very far, although I’d say it has something to do with the two processes looking like they overlap a great deal, but in reality they overlap less than you imagine. Consequently the internal rationale and ’emotional position’ you take, as well as the facilitation tools and tricks, don’t actually transfer, and, worse, will probably lead you in entirely the wrong direction. You need to be rewired, and I haven’t seen this work (yet). This my best take on it and is purely anecdotal – garnered from training several people who knew how to facilitate unconfs only to abandon the effort to facilitate production part way through. I can’t entirely explain it, but there you are – take it for what it’s worth.

Mapping Workflows

One of the things I do a lot, is help people think through their workflows and how to optimise them. We do this for all kinds of projects – book workflows, journals, micropubs, pre-print services etc prior to developing a software with them that will help them do what they do better, enable efficiencies, while leaving the door open for continual optimisation of how they work and for possible future transformations of how they work. Drawing from my 10 or so years of facilitation experience I facilitate these processes, and Kristen, drawing from her 20+ years in publishing, is ’embedded’ in the group to be part of the conversation and foster discussion and ideas from ‘within’ the group. We make a pretty good combo.

To do this we must help people ‘think in web-based workflows’. While most journal platforms out there are accessible via the browser they are not what I would call ‘web-based’. They take no advantage of what a networked digital environment can enable. Instead, the web is used as a common way to access what are, primarily, cumbersome database ‘ledger’ systems where workflow is tracked more than it is enabled. Books are even more interesting in that book production staff primarily work directly on the file system with MS Word files. There is little proof the web exists in many publisher’s book production workflows except that they use the network to email collections of files to each other.

So, how do we get people whose primary work environment is anything but the web, to start thinking about how they might work in the web? Well, we essentially follow 3 stages:

  1. document the current workflow
  2. discuss an ‘optimum’ workflow
  3. map this workflow into browser views (we call them ‘collaborative spaces’ or, more commonly, ‘spaces’)

Each of these steps takes several hours. We allow minimum one day for the entire process detailed below. 1.5 – days would make it more comfortable.

Document the Current Workflow

It is important to start the process with all major stakeholders in the same room. Clear out a few hours, or a day, and bring along a lot of paper, post-its, pens and, preferably, some large whiteboards.

Talking through the Journal of Creative Technologies workflow (Auckland, NZ)
Talking through the Journal of Creative Technologies workflow (Auckland, NZ)

It is important to make sure all the major stakeholders are there (or representatives if some groups are large) because when you go through the current workflow you will discover that no one in the room knows the whole story. It is also often true that the organisers of the event have some fundamental assumptions about the workflow that are wrong, and that most people do not understand the knock-on effect of their actions on a co-worker’s job. All this is important to reveal through discussion, while ignoring the claim that ‘we all know what each other does’ – I haven’t ever found this to be the case so far.

This discussion should start right at the very beginning of the workflow. In the case of a Journal Manuscript Submission System, for example, the process usually starts with an author with a manuscript that they wish to submit. That is your starting point. Make sure you really do identify where it all starts as most people will tend to suggest that the early stages are known and understood and simple and consequently they may try to skip this part or deal with it superficially. But your job is to have a discussion that covers the entire workflow and get exact details of what happens, by whom, and when. So keep asking really annoying pedantic questions to get to the clarity you need. Don’t let assumptions leave anything uncovered – I have often found that items everyone assumes are understood reveal hidden, not widely understood, processes when the right, very straightforward, clarifying questions are asked. For this process, you will have to get over your fear of looking stupid! Ask as many pedantic clarifying questions as possible.

Work through the workflow step by step from start to finish. As you do this, document it clearly – a shared large space (eg whiteboard) is best. As you draw it, ask for affirmations that it is correct. Work through all the eddies and conditional forks in the workflow to their conclusion and document them. In the end, make sure you summarise this in one simple document. Theexample below is a document from the Journal of Creative Technologies workflow discussion.


This is a useful process for exposing the actual (vs assumed) workflow to all players, stimulating ideas on how things could be better, and creating a ‘source of truth’ for the current workflow (people often forget details down the road).

While this part of the process is good for raising ideas on how things could be better, don’t let the group get stuck in the future weeds. Planning an optimum workflow comes next and if you let them stray too far into future thinking, they will either not finish documenting the current workflow, or they will confuse how things are now with how they want things to be. But don’t entirely kill these ‘future thinking’ moments either – let them be aired but if it looks like they are going to evolve into deep, nuanced, discussion of one part of the workflow and how it could be improved, then move discussion along. Also, make sure that all people are paying attention through this entire process. Don’t allow side conversations as these take those participants out of the wider discussion as well as distracting everyone else.

Discuss an Optimum Workflow

Next, we lead the group through an open-ended ‘pie in the sky’ discussion about possible utopian workflow futures. We start this discussion very broad – asking anyone to jump in with an idea. The discussion starts broad and we allow it to roam around a little. Often throughout this process, we are taking note of where there is agreement or ‘energy’ around a given idea or approach.

Sometimes people whiteboard ideas but most of the time it is pure discussion.

Discussing workflow possibilities with Collabra Pyschology Jourmal

After a while, perhaps 30 mins, maybe more than an hour, we start bringing back some of the ideas into the discussion that we know the group was interested in and ask them to expand it together. Sometimes we drop in small hints that a particular idea might be a good one but is technically unfeasible – this starts to give the group a sense of what is possible, or what might be technically achievable in the short, medium, or long term. It’s important not to squash ideas as soon as they emerge but to ‘sober them up’ if they get too fantastical. A little bit of realism doesn’t hurt at this stage but, more importantly, you want to get the ideas flowing. Nothing is nailed down or committed to at this point, it’s just exploration and discussion.


Now we get to mapping these ideas onto a web-based platform. The group is going to engage in systems design without knowing they are doing so. We do this by first explaining a little about the web – some of the things that are possible. We might show some examples of sophisticated web-based editors like Wax, or in-browser pagination using Vivliostyle. Perhaps we might look at Trello/wekan or kanban examples of workflow management. We might look at Stencil.a or any number of examples of interesting platforms and approaches the web can offer.

We also talk about the efficiences of the web and how that is enabled – mostly this comes down to unpacking why a single-sourced content environment is so powerful, why ‘everyone working on the same object’ is important, how collaboration and concurrency can change the way we do things. As well as preparing them for the idea of designing a new system that is native to the web, we are introducing some new ideas that might reshape how they think about how they work. Why, for example, do we email MS Word files around when we can simply all see the same document, at the same time, in the browser?…these ideas will mean different things to different groups and how they play with them depends on how ready they are to explore new possibilities, combined with how much of their ‘old ways’ they are prepared to let go, plus how much they understand about the web. So it is important to let this conversation go at its own pace across whatever topics the group feels they need to explore. It is important that the discussion evolves of its own accord from the ideas introduced. We ‘shape’ the conversation, point it in a certain direction and signpost with certain interesting examples, rather than provide a soliloquy or monologue about how we would like things to be done. This is important, because unless the group internalises these ideas, they won’t end up exploring them when it comes to design time.

Next, we give a little rundown about ‘thinking in collaborative spaces’. Basically what we are trying to do is to take some of the ideas that emerged in the ‘optimal workflow’ discussion and start prompting them to think how this might be realised ‘inside the browser’. Most commonly we can do this by talking about very concrete things like browser windows, which everyone knows, and asking ‘how could this part of the workflow happen in a browser window?’ For example, in a journal system, we might ask ‘how might submission happen for an author in a browser window’? As a starter example, we could discuss this and draw a box on a whiteboard and draw some basic ‘UI’ elements in that box. This makes everything very very concrete. You are reducing systems design to something they understand without them realising that they are about to start designing a system.

The next step can take several directions, but the most common is that we split the group into smaller groups. 4 or 5 to a group is usually a good number. We then give them large sheets of paper and a bunch of thick pens, and send them to acoustically separated spaces to draw up proposals for ‘several spaces’ that would represent the workflow in the browser. The time we give them depends on the time at hand. You want more than 15 mins, but 45 is probably too long. Sometimes we might also ask them just to focus one one part of the workflow, usually the first part (however you design this is up to you).

Erich van Rijn (UCPress) pitching some ideas to the group while Dan Morgan (Collabra) documents, and Paul Shannon (eLife), and Yannis Barlas (Coko) listen.

It is very important when you send them away to do this that you ask them to draw the interfaces. One big page of paper, for example, per ‘space’ (browser window). If you don’t do this some groups, especially those used to writing requirements docs, will write lists. The problem with that is that these lists don’t tend to be scoped or connected very well. They just turn into a list with as many items relevant to (for example) ‘submission’ as you can imagine. Better is if they draw the spaces as if it was a browser window, putting in UI elements with basic drawing.

Oliver Buchtala ( holding up his group’s proposal at Erudit, Montreal.

No one has to be an artist, it just needs to be a rough proposal of what that space would enable, and one most people will understand if they were just to look at it.

John Chodacki (CDL) puts some finishing touches on a proposal he designed together with Andrew Smeall (Hindawi), and Jure Triglav (Coko).

We circle around and make sure everyone is getting on with the task and in good time. At the end, we bring everyone back into the room and ask them to present their proposals to the rest of the group.

Lia Schiff (CDL) presenting a proposal to the rest of the group.

We give them a short amount of time to make the presentations. Perhaps 10 mins, more if the scope of the workflow is larger.


What you will be surprised at, I can guarantee it, is that all the proposals are *great* AND they will all be very similar. We have done this many times and the results of each group are rarely very far apart. When they are far apart, it’s usually because a group has locked onto one idea or another as a starting point and designed everything around that. These ideas usually have something very worthwhile that can be combined with the other proposals to improve them.

As each group finishes presenting a space or group of spaces we ask the group for questions or comments. We don’t let this go too deep into the weeds as time is tight at this point, but some discussion is always useful.

Another proposal at the Erudit workshop.

Then at the end, you discuss these approaches and agree on a common approach. We call this an ‘architecture’ which it is to an extent. It is the bird’s-eye view of how their new workflow will fit snugly into a browser based workflow. The following being an early ‘architecture’ or high-level systems view of a journal platform for Collabra.


Handily each of these new spaces can then be built as a PubSweet component! The following is the architecture showing the components we need to design and build – this diagram was the result from early sessions with the staff from UCP I facilitated to produce the Editoria monograph production platform.


This process is a very specific description of the first part of the Cabbage Tree Method. The second part of the Cabbage Tree Method involves facilitating the design of each of these components.

Thoughts on Facilitation

I’ve been sitting on the beach trying to not think about work, which means of course I thought about work…. but in the way where clearing the mind brings up new insights almost ‘out of the blue’. It happens to me a lot when I get away, which is why I sometimes do my best thinking on trains, or at the beach.

I have been pondering facilitation. So here are a few thoughts. The following is very much a sort of scratch pad of ideas / stream of consciousness. I’ll put structure to it and flesh it out later.

First, I have been pondering what makes a good facilitator. How do you know when someone might be good at this. I think there are 2 personal characteristics that might seem contradictory but are essential:

  1. they are very open
  2. they are very controlling

The second one sounds bad I know. I will work out a better way to state this. But in my experience every good facilitator I know is in some way a bit of a control freak. They are also very (very) open. That might seem like a difficult mix to get right – it is! Which is why I’m kinda leaning towards this theory because I have trained several facilitators and the ones that don’t make it don’t strongly represent simultaneously in these 2 categories.

Second, pretentiousness or a ‘high minded’ attitude *does not cut it*. I say this because you can have the above two characteristics right but I’ve seen this attached to a much removed holier than thou attitude and that is the worst. No good facilitator is above the fray in this way.

Ok.. I was about to break out in a rant there… phew…


Next the facilitator’s role – what is the facilitators job? I see it as this. The facilitator’s role is to maintain process and to pass decisions to the participants over substance.

Sounds simple. But in no way is this simple. To maintain process the facilitator needs to find ways for the group to invest in an artificial culture that is born on the spot. The rules of that culture are almost completely evoked and maintained by the facilitator. This small little bubble, or micro universe with its own rationale and rules, is what the facilitator instantiates and maintains. It more or less comes down to these two things:

  1. methodology (more important than you think, but also not nearly as important as you think).
  2. shaping human dynamics

In other words, your job is to manage what is done (methodology eg. the Book Sprint Methodology), and how it gets done (shaping the internal behaviors).

I think number two is the hardest to master since you can’t be good at any methodology unless you know how to shape human dynamics. And this is all about who you are and finding your own voice as a facilitator. There are so many tricks and techniques here I don’t even know where to start. Maybe a subject for other posts. But what I’d like to point out is that these two things put together equal process. Facilitators manage process so the participants can focus on the substance of what it is they are deciding/creating etc.

I say this because sitting on the beach has made me aware of one of the biggest issues with facilitation that I have experienced. When I used to facilitate Book Sprints I used to ponder why it was that Humanities academics and facilitators were the hardest people to facilitate. Also, in other Book Sprints, staff documentation writers would often prove difficult when I did Book Sprints that focused on documentation. Ponder ponder… now I think I sorta see it. It is because these groups have a strong opinion on process. Academics are experienced in writing books, so they believe they know how books are written. You come at them with something else, another way of doing it, and many of them just flatly freak out. I had one academic who literally said “you can’t just make up how you make books”. That was a pretty extreme example. I was able to bring her round but it was hard work. Facilitators also think they know facilitation process, so you involve them in something new and they almost always think they can see better ways to do it. They are almost always wrong (mainly because no path works the same for any two facilitators because of the need for each and every facilitator, in themselves, to be the instantiation for a temporary, micro, but very real culture). . Same with documentation  writers… involve them in a doc sprint and you might very well be asking for trouble.

It is the facilitator’s job to bring the process to the people. If the people are domain experts (ie. know a lot about the topic) then no sweat, they will usually get in there quickly and invest in the mini culture you lay down. But if the participants have opinions on the process you get into all sorts of trouble.

So, that means there are two categories of people that need to be kept in mind:

  1. domain experts – good to go, you should be able to get them inside of the bubble no problems
  2. process experTs – spelled with a capital T for Trouble 🙂

Ok…. so I want to say one last thing before I go practice falling off a surf board inelegantly. There is a group of people that are also difficult to keep inside this bubble. They are, for want of a better word, the ‘power retainers’. These are people that either hold sway with the group because of their massive cultural capital (eg the elder states-person in a sector, or they are the boss), or they have such big egos they think they know whats best (usually they also don’t know when to shut up).

There are three possible ways these people can go:

  1. they give the power away – they step back and let other people in, are careful not to dominate, they get in there shoulder to shoulder with others, really listen, go with the flow
  2. you coach the power away – this can be exhausting, but it works more often than not and when it does it can be dramatic. I’ve seen people swing around from being destructively blocking to being the biggest advocates of the process within a day.
  3. they don’t give it up – i have rarely seen this. Interestingly the two examples that come to mind have been Ministers (I won’t name the country or position!). The way they avoided ‘being one of the people’ was just to disappear from the process entirely. Maybe that’s their job – professional avoiders (hoho). Sigh.

I have to say, when I see people migrate from 2 -> 1 (above) they do nothing but earn my utmost respect. That is humility and human connectedness at its best right there.

But if someone is stuck on 3… that is really trouble and you might need to ask them outside for a talking to. In the past I have threatened to remove them from the process. That’s a tough tough call right there, but you have to get the rest of the group to where they need to be in the time they have. If you don’t make these tough calls you won’t make it. I have, by the way, only had to sideline people for a while. I’ve never had to remove anyone and I even had one elder statesman front up the next day and apologize to me and recognise why things had to flow the way they had to flow. That dude earned a place in my heart forever.

Anyways…back to the beach 🙂  ….

The invisible skill

I do a lot of facilitation and I’m very good at it. I don’t know how I came to be a facilitator exactly, it’s not the sort of thing I think you go to school to learn. It just somehow comes out of you bit by bit on a road to achieving something else entirely. In my case, I think it came about while trying to build FLOSS Manuals (a community that produces free manuals about free software). FLOSS Manuals (FM) needed content, and I realised that it was not going to happen at the scale needed if I wrote it all myself. So I had to learn to build community and building community requires facilitation (even if you don’t know it at the time).


Anyway, long story short, I became a facilitator the hard way – by not knowing that it was facilitation that I was doing. I had no context. ‘How you get things done’ in the world seemed to be all about the doing of those things. If you want to write software manuals, for example, you wrote manuals. That is what publishers and author, editors etc did. Who ever heard of facilitation in the context? No one that I could find.

So it took me a while to even realise that facilitation could play a role in making manuals (books) and I only had that realisation after I first tried it the publishing industry’s way and failed. It’s even fair to say that I had no understanding that facilitation could have a role in helping people to make books until I had been facilitating people to make books for many years. I was that blind to the idea. Instead, I had this strange, slowly evolving awareness that somehow when I got people in a room and I was there also, then books resulted. It seemed like it was the participants that ‘were doing it’ and, bizarrely, every time we did it, it worked, every time we did it it was better than the last time, and I happened to be there to witness it.


It took me some time to work out that this result was because of the role I played. It took a very very long time – I would say, possibly, 2-3 years. The awareness didn’t come in one shot either. I first thought it must be the process that made it work. So I started trying some stuff out. I remember very strongly thinking that there was this process that actually existed, like publishing processes exist, and that it was concrete and tangible, but it was just that it was unknown.  As seriously kooky as that might sound, that’s how I thought of it at the time. I felt I was discovering something that pre-existed, some process that just needed to be revealed.

Then, slowly, after Book Sprints were really kicking ass and producing remarkable books I’d have thoughts like ‘I wonder how important this process is?’ I wonder if it might actually be me that is the most important ingredient. Not me in an egoist way, like Adam Hyde is the only person that can do this (interestingly, other people thought this might be the case!), but maybe that it is not so much the process but what I am doing that is making this work.


So comes the understanding of the extremely interesting and tangled relationship between facilitation and method. I spent many years untangling it and now I think I have a 1.0 understanding. Like, at the school of facilitation if you get this idea, then you are actually allowed to call yourself a facilitator…. it is that basic, and that central to what facilitation is. My un-battle-hardened synopsis is this series of truths might seem a little contradictory: a good facilitator is better with a good methodology. A good methodology is nothing without a good facilitator. And a good methodology to a good facilitator is nothing but an interesting yet weak navigational instrument.

Anyhow. My sum of this is that I often get people telling me they would be a good facilitator for this or that, or that they would be if they had the opportunity. I also see a world where methodology is seen as king, you just need to read it and follow it to the letter and you’ll be sweet! I can’t blame people for this. How could I when it took me so long to understand that facilitation was a thing? I can’t blame people when they think it’s something anyone can do. But of course, I do find it frustrating. I’m no saint! But after many many years of practice and experimentation, pondering, trying things out when I was terrified they would fail, failing, succeeding, mentoring others to do it well, exploring the weird psychology of it all, seeing others do it so very badly – I can now say I know what facilitation is and how special it is to be able to do well this invisible skill that so many do not know even exists.


What is the Cabbage Tree Method

Another chapter from the forthcoming book


Imagine a bunch of people in a room, all sitting around a table. There are some whiteboards in the room, and coffee, sticky notes, and maybe even a data projector, litter a table. All of those people, except one, share a common problem and they want to create new software to solve it.

But where do they start? There are no developers here … what’s going on? One of them, the facilitator, steps up and initiates a short period of introductions and then asks the question “What is the problem?”

From this, a process unfolds where the people who need this new software (let’s call them the use case specialists) explain all their frustrations with the ways things are done now and what could be better. It is a wide-ranging discussion and everyone is involved. At the facilitator’s prompting, someone jumps up and draws a straggly diagram of a workflow on one of the whiteboards to get their point across. Another pipes up to add nuance to one part of the diagram because they fear the point wasn’t adequately understood. There are some quiet moments, some discussion, lots of laughter, a break for lunch. Plenty of coffee.

Throughout the day, the group somehow (the facilitator knows exactly how) evolves their discussion from big picture problems and ideas to a moment where they are ready to start designing some solution proposals. The facilitator breaks them into small groups and each group has 45 minutes to come up with a solution. When they come back, each group presents their ideas. Some of the ideas are very conceptual, almost poetic. Other ideas are very concrete and diagrammatic. Everyone thinks carefully about the merits of each proposal and what it is trying to say. Discussion ensues. Members of the group ask clarifying questions. After all the proposals are made, they decide on an approach.

In a short time, they have agreed on a set of requirements for software that they have consensus on and all believe will solve (at least some of) their problems. They take photos of all the whiteboard diagrams and document the design agreements thoroughly, creating a Design Brief. At the end of the day, they walk out the door and the design session is over.

The next day the Build Team, featuring user interface (UI), user experience (UX), and code specialists, looks over the documentation with the facilitator through remote conferencing. They discuss the brief, what is clearly defined and what is still to be defined. They work through the issues together, jamming out approaches to open-ended questions which are both technical and feature-focused. The session is not long, perhaps two hours. It’s a lot of fun. From this session, the Design Brief is updated with the decisions. Many technical solutions are left wide open for the code specialists to think through and solve over the next weeks. However, the code specialists can, and do, start work immediately, though the UI/UX specialists add mockups to the documents over the next days. The team works things out on the fly where necessary and gets onto it. Over the next weeks, a few questions to the use case specialists surface – these are either asked directly or through the facilitator.

The use case specialists reconvene six weeks later with the facilitator and are presented with the working code that has been created by the build team over that period. Everyone is amazed. It’s just as they imagined, only better! After seeing the working code, they each have further, exciting, insights into how this problem might be solved. The facilitator steps up and they go through it all again to design the next part of the solution. Everyone is bursting to have their say.

The design-build cycle is repeated until they are done and the software is in production.

This is the Cabbage Tree Method.

The Cabbage Tree Method (CTM, for short) is a new way to create open source software products. With CTM, the people who will use the software drive its design and development under the guidance of a facilitator. It’s a strongly-facilitated method that generates and requires immersive collaboration.

You can think of CTM as a new branch on the Systems Development Life Cycle (SDLC for short) tree. Some popular SDLC methods include Spiral, Joint Application Design, Xtreme Programming, and Scrum (some of which conform to the values of the Agile Manifesto – see for details).

Unlike the various SDLC methods, CTM is specifically aimed at the free software/open source sector. In that sector, the cultural rules are quite different from environments where teams are employed to work within a more formal business or corporate structure. However, CTM differs from open source processes that have embraced developer-centric solution models, thanks to its focus on users designing the software with a facilitator as an enabling agent.

What also sets CTM apart from other methods of developing software, is that it doesn’t have:

  • personas
  • avatars
  • User Validations
  • user stories
  • empathy boards (etc)
  • ‘experts’ designing the solution for the user

This process isn’t about development procedures that represent the user at a distance. It’s about communicating and collaborating with the user at the center of the process. It’s not a question of profiling a so-called user, or turning them into an avatar or proposition, or trying to generate empathy with them from afar. Rather, a core requirement of CTM is to directly involve in the design process everyone who will use the system. The idea is that if you want to know what the user wants, don’t imagine their response. Ask them.



Like most modern SDLC methods, CTM is iterative and has clear cycles. Each cycle consists of a Design Session followed immediately by a Build Period. These cycles repeat (design, build, design, build, design, build etc) until the solution is complete.


The specialists most in demand for the Design Sessions are the use case specialists – the users themselves. The Design Sessions are always in person – they don’t work well with remote participation. Each design session can be as short as two hours, or as long as one day.

The general principle of the Design Sessions is that all users affected by the software must be present at the appropriate moment – either in total or as a representative group. Without their presence, a solution cannot be developed. A fundamental rule of CTM is that no one speaks for the users other than the users themselves.

From each Design Session, a short brief is created that describes what has been agreed to, what is absolutely required to be done in the following build period, and what is left to be solved during the build period.


The Build Period takes place immediately after the Design Sessions. The build period can occur remotely and may take two to eight weeks, perhaps longer. Building is the job of the UI/UX and code specialists and it is here they can both be creative and exercise their User Interface (UI for short), User Experience (UX), and programming skills. Use case specialists don’t participate in the Build Period but may be consulted for clarification during this period.

Before the Build Period begins, each of the build team members receives for consideration the initial brief that was created during the Design Session. The Build Period then begins with a meeting where the code and UI specialists discuss the brief, decide on an approach, and together develop solutions for any outstanding issues. This may include solving some complex feature, technical, and usability problems – essentially working out how to achieve everything the users have already decided, plus designing what is left over. Then briefs are written and agreed upon, mocks done where necessary, and building begins.

On creating a methodology

The first 'real' Book Sprint. Inkscape, Paris, 2008.
The first ‘real’ Book Sprint. Inkscape, Paris, 2008.

Some years ago, I developed the Book Sprints methodology. It’s now pretty well defined and is being used very successfully to develop many books for all types of organisations. I am now working on another methodology – Collaborative Product Development. So, this time round, it’s sooo much easier and I thought perhaps I should write down some of the journey from zero to methodology. It will certainly help me to do so and maybe someone else out there will find it useful.

First of all, methodologies are odd things. Book Sprints is a methodology but, at the same time, I often wonder exactly what this means? I mean…you can’t just take a written template and turn it into a successful facilitated process. It just doesn’t work. The reason is because facilitation is a little, if you pardon the strange analogy, like administering the law. The law exists on paper but every time it is administered by a judge it is new. The context requires the law to be interpreted to enable it to be applied.

I think facilitation is like this. You can take a method and apply it but the context is everything. You must always make the application of the method new each time it is applied. Further, you need to extend it and break it when necessary and you have to do it effectively, other wise you break the process and, in the facilitation game, process is everything.

So…you must first be a facilitator to apply a facilitation methodology. Even then you can still screw it up. For example Book Sprints, and Collaborative Product Design, employ all the same skills that you need for ‘unconference’ facilitation plus more. The more is specifically the skills required to drive people effectively along a finite timeline to completion of the thing you are making. The need to drive product in this manner often freaks unconference purists out because you wield a lot of ‘do it now’ power else you will never get there. ‘Do it now’ power is only subtly used in unconferences, in product-driven facilitation you use it like a hammer.

Anyways… the point being that a methodology on paper is nothing. You need to define it, so out comes the pen and paper.

Defining a methodology is actually pretty strange and, in my experience, the newer the ideas in the methodology are to you, the longer it takes to define. Book Sprints, for example, took me about 4 years to work out and I only really knew it had a definition when I had to train someone else. CPD, on the other hand, took me a day to outline on paper. I’m still refining it but that’s normal, the body of CPD came into existence in one day-long session. What’s more, it appears to be working. The bits that are taking the longest to work out are the bits I haven’t experienced before. We haven’t taken a full product to market with CPD, so, consequently, the production implementation phase still needs to be tested and refined. The rest of it, however, seems pretty well constructed.

It took a long time for me to work out a method for Book Sprints. I was really just trying stuff completely blind. It didn’t start that way, as it happens. I first went to people in the publishing industry and asked them how I should do it. I figured they knew how to make books and surely they would have some ideas on how to make it faster. Hah. Was I ever wrong. My experience was that publishing people screwed up the process with their own process. Too much process. So I had to, finally, after a long period of angst, decide I was going to have to work this thing out myself. I didn’t want to do it. I didn’t even know what it was I was trying to do. So, sigh, I relented and proceeded to slug it out.

It was like slugging it out too. I mean, I had no experience in making books. I didn’t want to do anything I considered ‘publishing’. I have an aversion to cathedrals – which is what publishers looked like to me. A deeply institutionalised sect. So I had to actually learn to trust myself and do it my way. It was quite scary at first. I mean, I was inviting a bunch of people to come to some place to work for a week to develop a book using a methodology that actually didn’t exist. I didn’t have much idea what it might look like either. Geez… I must actually be pretty stubborn when I look back on it.

So I went about inviting people to Book Sprints and I challenged myself to trust myself. To listen to myself and observe. I came to understand that the only thing that could enable or prevent a successful Book Sprint was me. There was no other factor. That was pretty frightening at times. I spent many nights during Book Sprints completely terrified that I was about to send this nice group of people into an unproductive deep abyss. They might return from that dark hole but I was pretty sure I wouldn’t.

On this journey, however I had some starting points. I don’t know what triggered it but very early I came to understand that rapid book development of the kind that Book Sprints represents could not be about publishing processes – it was about unconference processes. Luckily I had a mentor, who had, for reasons unknown to me, taken me under his wing. At the time I didn’t know how lucky I was. That was Allen Gunn (Gunner). I had seen him in action many times as a facilitator and I had a few clues to a process. It wasn’t much but it was a start.

So I tried my hand at facilitation. I would, at the time, tell myself that Book Sprints were more about facilitation of people than the production of a book. To say so out loud sounded odd. It didn’t sound true. It sounded like I just made it up. But I kept saying it and trusting it. I kept challenging myself to trust myself. It wasn’t easy but as I became used to it, the process became easier.

Anyway, I still couldn’t call this thing a methodology. All I knew was that I was trying things out and formulating some kind of Book Sprints worldview. I think it’s fair to say the worldview was nothing I could articulate. I worked through gut and felt that everything was instinctual. However, I was learning useful tricks. For example, I remember Gunner saying he tried something new each time he facilitated an event. So I tried something new each time. I learned that if you failed with the something new, the trick was to make out like it was a success and, further, an expected success. This way I created a fallback framework that would allow me to experiment, to try and fail, to learn on the job and to get away with it.

So, I iterated forward. Rather slowly really. I mean, I had to convince people that this non-existent Book Sprint thing was not only possible, but they should do it, while I had little to point to as proof. Yeesh. Talk about a hard sell. But some people saw the possibilities and tried it out. I am forever grateful to Leslie Hawthorn who was working at Google Open Source Programs Office at the time. Leslie (introduced to me by Gunner) backed me and sponsored the first 3 Book Sprints. Amazing. I got something I could start with and that was critical. Later, with a few under my belt, it became easier to convince others.

So I did this for many years and felt I something taking shape. It was actually working. The books were getting better which seemed to indicate I was improving the process. I was starting to construct an embedded framework and the things I did were tested against it. It was filling out and becoming more consistent. I could finally start becoming a little more playful with the process. Still, when I started to talk about it as a method it was a query more than a statement. I wasn’t even sure what a methodology was. I wasn’t sure if Book Sprints was a method or even a stable set of practices. Others also said they same thing. David Berry and Michael Dieter, two good friends and critical theorists, would ask me what I thought it was. I had no idea how to articulate it. I asserted at time that it was a methodology but I wasn’t even sure I convinced myself.

A critical break through came when David and Michael (who had both been to 2 Book Sprints by this time) wrote a post about the process:

I was amazed. They saw things that I didn’t. It was stunning to me. They had given me my own framework. From this point I started to construct a much better understanding of what I was doing.

The next step that finally defined the process was when I actually had to train someone to do it. I had other work offered to me (designing platforms) and I had a Book Sprints client base to keep happy. So I needed to scale. I needed me times 2. So I brought in Barbara Rühling (as introduced to me by Zara Rahman). It was at this moment, during a Book Sprint in Malta, and Barbaras first training session, that I started to make up a language to explain what a Book Sprint was. It flowed out of me like I knew it all along. I was very lucky in that Barbara trusted my narrative. It allowed me to expand notions as they came out of my mouth. I could define and refine a language and process as I spoke. It was fantastic and it was the final moment in the long process of defining a method. Hard won experiences were suddenly made salient and coherent though in situ explanation.

Now when I look at Book Sprints it appears pretty concrete. I laugh when people talk about it as if its a ‘known thing’. How can it be? I just made it up! 🙂 Of course, I didn’t just make it up. It is the result of a lot of trial and error and observation, risk, stress, unbelievable elation when things worked out, and the inability to give up. I still don’t know why I didn’t give up. I like to think if I did it again I’d give up. It might be a better way to live my life 😉

Collaborative Product Design v0.9 Ch4 Facilitation

Facilitation is a key ingredient for Collaborative Design Sessions. No group should attempt this process without a facilitator. Some important things to get right going into the event include:

The facilitator is not a Benevolent Dictator
The facilitator here is not the Benevolent Dictator For Life, cat herder, or Community Manager (or other models) commonly found in open source, rather the model is closer to an unconference-style facilitator. Don’t confuse these very different approaches!

Organisational neutrality
The facilitator should not be part of the organisation that is in need of the solution. This frees the facilitator from internal politics and dynamics and enables them to read the group clearly and interact freely.

Domain Knowledge is not necessary but useful
A facilitator may be entirely neutral or, in the case where an organisation is working already with an open source product in mind, be part of the open source product development team or community. The facilitator of these sessions may or may not have domain or product knowledge. If there is no domain knowledge it is recommended product and domain experts be present. This helps a great deal to keep the process anchored to ‘product reality’.

However…there are some gotchas. If the facilitator is part of the org with ‘the solution’ (eg an open source product) then make sure someone else from your team is present. Facilitation is about trust and you can’t be both a facilitator and a product advocate. You need someone else present to advocate for the product. The second gotcha is that it is generally better for the facilitator to be neutral to all parties, however, in this case, I believe there is value in the facilitator knowing the proposed product-solution intimately (with some knowledge of how it could apply to the use case being confronted), but you will need to work extra hard to maintain your trusted neutrality (you might have to work out in advance how to manage your feelings if the group starts advocating that they don’t use your product, for example).

You may wish to have tools such as post-its etc, but generally, a large whiteboard and markers (or large pieces of paper) will take care of it. Most shared objects are documentation but it may be necessary at times to use other facilitation tools and tricks to move a group process along.


Facilitation Tips
Here are some things to remember when facilitating Collaborative Design Sessions:
Build trust before products

As a facilitator, your job is to build trust in you, the process, the group, and the outcomes. Each time you make a move that diminishes trust you are taking away from the process and reducing the likelihood of success. For this reason, you must put building trust, working with what people say and towards what people want, ahead of building ‘your’ product. Trust that the product and a commitment to it, will emerge from this process, and it will be better for it.

Change is cultural, not technical
Too often technology is proposed as the mechanism for change. Technology does not create change. People create change, with the assistance of technology. Make sure the group is not seeing technology as the magic wand. Change is not magically ‘embedded’ in the technology. Improvement, optimisation, or radical reworking of workflows requires people to do things differently. The group must be committed to changing what they do. The ‘what they do’ should not be posited as a function of technology, it is their behaviour that will always need to change regardless of whether there is a technology change. Behavioural and cultural change is a necessity, not something that ‘might happen’. The group needs to recognise this and be committed to changing how they work.

Focus on problems and solutions not technology
As mentioned above, cultural change is necessary and many behavioural changes can occur that will produce positive results without the need for a technology change. It is important that you and the group can identify these issues and bring them into a focused discussion. For this reason, it is very important that the initial sessions focus on what the problems are, irrespective of whether they are born of technology or workplace process. If you can accomplish this then the group may very well propose changes that have nothing to do with technology. This is a very good outcome, as the end goal is to improve how things are done. If technology change is not always (or ever) part of the solution that is also success for the process.


Even the best solutions have problems
Own that even the best solutions, including the one you are representing, will have problems. There is no perfect solution, and if there is then time will inevitably make it imperfect.

Leave your know-it-all at the door
If you are part of a product team then you may be expected to be somewhat of a domain and / or product expert. Leaving that at the door is not possible of course, but you should be careful that you do not use this knowledge as heavy handed doctrine. Instead, it should manifest itself in signposts, salient points, and inspiring examples at the right moments. These points should add to the conversation not override it. Don’t overplay your product knowledge and vision, you will lose people if you do.

Give up your solution before you enter the room
If you are part of a product team it is a mistake to enter into a Collaborative Design Session and advocate or direct the group towards your solution. If the group chooses a technology or path you do not have a stakeholding in, then that is fine. The point is, however, that the likelihood is that they will choose ‘your’ technology, otherwise, you would not be asked to be in the same room with them. However, if you facilitate the process and drive them to your solution you will be reading the group wrong and they will feel coerced. You must free yourself from this constraint and be prepared to propose, advocate, or accept a solution that is not ‘yours’ or you did not have in mind when you entered the room. This will not only free you up to drive people to the solution they want, but it will earn you trust. When they do they choose your solution, and chances are they will, then they will trust it because they trust you and trust the process. If they don’t choose it, they will trust you and come back another time when they are ready for what you have to offer and, additionally, they will advocate your skills to others.

Involve a broad set of stakeholders
The sessions should involve as diverse a range of stakeholders as possible. This will not only improve the product but increase stakeholder ownership of the solution and that in turn will help the organisation implement it. If people feel they own the solution, they will work towards seeing it implemented. Stakeholders in this context can apply to the organisation you are working with (to solve their problem) or other projects that might play a part in solving the problem. Inviting the later to the events will greatly enhance the final product and produce valuable collaborations.

Move one step at a time
Move through each step slowly. The time it takes to move through a step is the time it takes to move through a step. There is no sense in hurrying the process, this will not lead to better results or faster agreements. It will in all likelihood move towards shallow agreements that don’t stick and ill-thought out solutions that don’t properly address the problem. The time it takes to move through a step will also give you a good indication of the time needed for the steps yet to come. Be prepared to re-scale your timelines at any time and to return to earlier unresolved issues if need be.

Ask many questions, get clarifying answers, ask dumb questions, the dumber the better
Ask many many questions. Try not to make them leading (note: sometimes leading questions are necessary for points of clarification or illustrating an issue). Keep asking questions until you get clear simple answers. Breakdown compound answers where necessary into fragments and drill down until you have the clarity you need. Dumb questions are often the most valuable. Asking a dumb question often unpacks important issues or reveals hidden and unchallenged assumptions. It is very surprising how fundamental some of these assumptions can be, so be brave on this point. If necessary feign humbleness and stupidity for asking an obvious question.


Own stupid problems, laugh about them!
Every workplace culture knows they do some stupid things. When you find these, call them out, and, if possible, laugh about them. Providing a context where people can bring forward and own ‘stupid’ processes in an easy way is going to help identify the problems and move towards solving them. It also sometimes gives people an opportunity to question things that they never felt made sense and this may, in turn, help others question the ways things are done – this is very valuable and is not always possible in the everyday workplace environment. Bringing these issues out can be very revealing, it gets people on the same page, and is often cathartic.

Reduce, reduce, reduce
The strongest point is a simple one.

Get agreements as you go
Double check that everyone is on the same page as you go. Get explicit agreement even on seemingly obvious agreements. Total consensus is not always necessary but general agreement is.

Document it all
Get it down in simple terms on whiteboards or whatever you have available. At the end of sessions commit this to digital, shareable, media.

Summarise your journey and where you are now
At the end of a session, it is always necessary to summarise in clear terms the journey you have taken and where you have arrived. Get consensus on this. It is also useful at various points throughout the session to do this as a way of illustrating you are all on the same journey and reminding people what this is all about. When doing this it is very useful to make points in this summary that illustrate that you understand them – bring out points that may have taken a while to get clarity on or that you may have initially misunderstood (there will be many of them if you are doing your job well!) so the group knows that you are embedded with them and not merely massaging them towards your own pre-designed end game.

State your willingness to discard your own product
Nothing builds trust more than statements to show that you are invested in helping them achieve what they need over what you want. Your investment in this, as with all your actions and statements, must be genuine. For this reason, too, you should accept conclusions that propose cultural solutions over technical, and other people’s products over yours. This also implies you need some fair understanding of products competitive in your space and you should not make denigrating comments about them, but instead recognise when they have value. The assumption is however that since they invited you here, and if you are doing a good job, people will choose your product anyway – but you must let them make that choice. It’s OK to highlight this dilemma and probably helps things if you do and do so in a light-hearted way.

All solutions must be implemented incrementally
Do not design and then build the final solution all at once. Solutions must be deployed incrementally and learnings folded back into the proposed solution. Build to a minimum proposition, try it, learn, redesign, repeat.

Bring in the competition
During CDS it is sometimes a good idea to have complementary or competing technology providers at the session. You will probably find that his leads to great collaborations, each contributing what they excel at.

Use their semantics
Use terminology to describe the problem and solution that come from the group. Don’t impose your own semantics.

Facilitation is an art of invention
While this section has not been about how to facilitate it is important to make a note about invention before the next section in the hope that no one just reads the below as an instruction manual. There are processes and methods that you can use ‘off the shelf’ as a facilitator but none of them will translate from paper to reality in a one-to-one mapping. People are too weird and contexts too variable to ever allow facilitators the luxury to do it by numbers. At the very least facilitation is an act of translating known patterns into a new context and tweaking it to fit. But the reality is that much of the what a facilitator does is to make things up. Instinct and the fear of failure force on-the-fly invention of methods, but each time a good facilitator makes it appear that the method has existed for a hundred years and never been known to fail. When it does fail, a really good facilitator will ensure no one notices and that the outcomes were the typical, expected, ones you were after.