First Global PubSweet Conference

I just finished a 3 day meet in Athens with the PubSweet team.

No event is complete without a t-shirt!

It was a fantastic meeting and we covered a huge amount of interesting ground. Most importantly we discussed:

  • the remaining features for a PubSweet 1.0 (due end of June)
  • some future ideas for PubSweet 2.0 (possible GraphQL Apollo integration)
  • a demo and discussion around the latest Editoria (looks amazing!)
  • a workshop on how to think through Journal workflows with our decoupled approach
  • and a great discussion on how we could start growing a community model around Cabbage Tree Method principles (moving towards Cabbage Tree 2.0!)

We also looked at the new Athens office, and meet with Vasilis who is managing the production servers for the forthcoming UCP Editoria tests…

Now off to New Zealand! It was a really fantastic week!

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.

Book Chapter on Facilitation

The below is an excerpt from a chapter on facilitation for the forthcoming book on the Cabbage Tree Method (collaborative product design). The image is by the wonderful Pepper Curry.



Facilitation is a key ingredient for the Design Sessions. In fact, no group should attempt to use the Cabbage Tree Method or run a Design Session without a facilitator.

The facilitator is part of your open source team and should not be part of (if possible) the user group that needs the solution. This neutrality frees the facilitator, as best as possible, from existing ideas, and organisational politics and dynamics. In turn, this enables the facilitator to read the group clearly and interact freely.

You will need post-it notes, a large whiteboard and markers (or large pieces of paper).


Facilitation is both an art and a science. It’s difficult to master both aspects of facilitation. If you’re new to facilitation then it’s best, if possible, to watch experienced facilitators in action and try some small experiments first. I strongly advise against learning facilitation from a book. There’s no substitute for experience.

Having said that, here are some things to remember when facilitating Design Sessions. They’re intended to help you formulate an approach to this process. They’re not intended as a facilitation ‘how to’:

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’re taking away from the process and reducing the likelihood of success. You must put building trust, working with what people say and towards what people want, ahead of building the product. Trust that the product, and a commitment to it, will emerge from this process, and it will be better for it. I am thankful to Allen Gunn for this wisdom made very kindly to me many years ago.

Change is cultural, not technical – Too often people propose technology as the mechanism for change. Technology doesn’t create change. People create change, with the assistance of technology. Make sure the group is not seeing technology as a magic wand. The group must be committed to changing what they do. The what they do shouldn’t be posited as a function of technology. It’s their behavior that will always need to change, regardless of whether there is a change in the technology they use. Behavioral 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. This also means that they must commit to using the solutions you design together.

Even the best solutions have problems – Understand and embrace that even the best solutions, including the one you’re representing, will have problems. There is no perfect solution. If there is then, inevitably, time will make it imperfect.

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

Give up your solution before you enter the room – If you’re part of a product team, it’s a mistake to enter into a  Design Session and advocate or direct the group towards your product or your vision for a solution. If the group chooses a technology or path you don’t have a stake in, then that’s fine. The likelihood is that they’ll choose your technology or approach, otherwise you wouldn’t be asked to be in the same room with the group. However, if you facilitate the process and drive them to your solution you’ll be reading the group wrong and they’ll feel coerced. You must free yourself from this constraint and be prepared to propose, advocate, or accept a solution that’s not yours or which you didn’t 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 the group chooses your solution, and chances are they will, then they’ll trust it because they chose it and that reflects their trust in you and the process. If they don’t choose it, but you have done a good job, then they’ll trust you and come back another time when they’re ready for what you have to offer. They’ll also advocate you to others.

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, as doing that 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 you’ll need for the steps to come. Be prepared to adjust your timelines if necessary, and to return to earlier unresolved issues if need be.

Ask many questions, get clarifying answers, ask dumb questions, the dumber the better – Try not to ask leading questions. Keep asking questions until you get clear, simple answers. Break down compound answers, where necessary, into fragments and drill down until you have the clarity you need. Dumb questions are often the most valuable questions. Asking a dumb question often unpacks important issues or reveals hidden and unchallenged assumptions. It’s very surprising how fundamental some of these assumptions can be, so be brave on this point.

Reduce, reduce, reduce – The clearest points are simple ones.

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

Document it all – Get it down in simple terms on whiteboards or using whatever tools you have available. At the end of sessions, commit what you’ve documented to digital, shareable media.

Summarise your journey and where you are now – At the end of a session, it’s always necessary to summarise in clear terms the journey you have taken and the point at which you’ve arrived. Get consensus on this. It’s also useful at various points throughout the session to do this as a way of 1) illustrating you’re all on the same journey, and 2) reminding people what the session is all about. In the summary, make sure to illustrate that you understand the key points. 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 those points if you’re doing your job well! Doing that lets the group know you’re embedded with them and not merely guiding them towards your own predesigned end game.

Use their semantics – Use the group’s terminology to describe the problem and the solution. Don’t impose your own semantics. Remember, they are the experts. Use their language. If, instead, you use your terms in the process then inevitably people will become confused. If a term doesn’t exist for something, ask them to define it.

Remember, facilitation is an art of invention – At the very least, facilitation is an act of translating known patterns into a new context and tweaking those patterns to fit that context. But the reality is that much of the what a facilitator does involves making things up. Instinct and the fear of failure force the on-the-fly invention of methods, but a good facilitator makes it appear that the method has existed for a hundred years and has never been known to fail. When it does fail, a really good facilitator will ensure that no one notices and that the outcomes were the ones you were after.