Month: May 2017

The following is an outline on some new tools for the Cabbage Tree method. These proposals are designed to:

1. Explore how the Cabbage Tree Method (which is largely about facilitated product design and places the user, as a use-case specialist, at the center of the solutions model) can scale its processes
2. Generate some learnings to help iterate towards a Cabbage Tree model that can also build community

After taking this to the Shuttleworth Gathering, and then unpacking early thoughts at the PubSweet Global Meet, I proposed that we experiment in a series of iterations to extend the Cabbage Tree Method and generate new ideas. Everyone was open to it and so we will try a first experiment, and then reflect on it and iterate forward.

Background

So, a brief framing.
Current Open Source community driven solutions models look something like this:

Developer ------------------------> User

In this scenario, the User is slightly parasitic and the naming is right. The user uses the product of the developers.

In the Cabbage Tree Method, we have re-positioned the ‘user’ as a use-case specialist. They reside at the beginning of the process.

User ------------------------> Developer + UX expert

The user (use-case specialist) designs the product and then the developers and UX people improve the design, and build the product.

What has been pointed out to me (in Athens), is that the developer is featured in the Cabbage Tree Method (CTM) at the beginning by me -since I am the facilitator of the design process and I have some technical knowledge. So the Cabbage Tree Method was born already with a model that isn’t as purely user-centric as it proposes. I’m grateful to the PubSweet Global think tank for helping me understand this. A consequence of this observation is the need to understand that the developer (as expert) can play a very interesting role in designing the product. The developer essentially keeps the design ‘on the rails’ and within the boundaries of the possible and the doable. This is very important, since CTM is about efficient processes as much as it is about good design and good software.

Cross Functional Collaborative Groups

So, the next iteration will bring the developer (code specialist) and the UX specialist to the beginning of the process with the user. This will be the basis for a cross-disciplinary collaborative group that will design the product together.

User + Developer + UX expert ------------------------> Product

The core players, and some of their challenges, are as follows:

1. Use Case Specialist – the primary voice in the design process. They must say what they want but listen to the advice or thoughts of the UX and code specialists as to what is possible and doable.
2. Code Specialist – must play a mentoring role in the design process. Keeping an open mind to approaches they haven’t considered before. One of the big challenges is for the code specialists to accept what the user wants even though they disagree.
3. UX specialist – they must help make the product look and ‘work’ better than expected by everyone else involved! Care must be taken not to override the users’ requests. This role, like that of the code specialist, is very much a mentoring/guiding role and the UX specialist might very well know where the user is heading with a design but must allow the user to get their at their own pace.
4. Facilitator – for all this to work, a facilitator must be present at all design meetings. The facilitator is there to moderate human dynamics and ensure everything proceeds on an even keel. The facilitator should not play a role in design.

In previous iterations of the CTM, I played the role of the facilitator and a bit of the ‘code specialist’ (really a technical domain expert). In the next iterations, we disambiguate this. This will also hopefully allow the model to be more easily replicated.

Remote Working

In the current CTM, all design process take place in real space. However, this does not scale. We need to find more effective ways to enable small teams, rather than one big team, to break off chunks of the problem and work together. To do this we will bite the bullet and try working through remote technologies. In this way, our UX specialist (Julien) in France, can attend alongside our code experts (Slovenia, Kenya, UK, Athens), alongside the use case specialists (mostly in California) with me facilitating from where ever I am! In simple terms, we have to make this work.

So we will look to use Jitsi for open source video conferencing, and ahn open source collaborative online whiteboard (there are plenty). Remote participation loses a lot of nuance but I am hopeful we can make this work with a small team if we are disciplined about the process (this is where facilitation kicks in).

Iterations on CTM

So the first step is to try this out. We have started work on a Journal platform so we will try one meeting like this and see how it goes. I think the balance will be something like:

2 x code specialists

1 x UX

4 x use case specialists

1 x facilitator

… probably we start this in June. Then we will reflect on it and tweak the process as we go. I’m not convinced this will reveal the secrets to how to build open source products as a community,  but it is one step further in that direction. I am sure we will design good products this way, but working out how to make CTM scale and how to open it up so it can become a self-replicating community is going to take some time. Still…I feel we are on the right path (and an interesting one!).

Stay tuned!