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:
http://ausserhofer.net/2013/02/the-method-of-book-sprints/

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 😉

Notes on Collaborative Product Development

So, during the Shuttleworth Gathering this week I facilitated a session about CPD and asked for feedback. I got some great information, most of which is targeted at what people would need to know in order to understand the process better. I am currently writing a ‘book’ about the methodology so this feedback will help shape that. Starting with:

  • challenges on the name and if there is something better
  • timescales need to be illustrated and discussed
  • implementation phase needs to be unpacked and described
  • testing cycles
  • bring out the fact that the product must be adaptable
  • explain how this will change ‘your’ organisation
  • importance of institutional buy-in
  • case studies and stories
  • maybe a hardware case study?
  • with this method some change is cultural
  • how would you measure cultural change?
  • how do you better ensure cultural change?
  • case studies would be very useful
  • simple illustrations of why this method is better
  • front load the political critique of Open Source
  • with the front loading highlight that most ‘client centered’ solutions are actually developer-centric solutions hidden behind a paywall

Also an interesting idea to make a current workflow image into a poster ‘this is what we are trying to avoid’

Arthur Attwell came up with this lovely way to describe the advantages of collaborative design:

footpath-oraSolution designed by the city council

footpath2-oraActual traffic

Here  you can see the dissonance pretty clearly.

I think I will structure the book something like this:

  • what is Collaborative Product Design
  • What does a hosting organisation need to think about
  • the basics
  • the setup
  • the design session
  • facilitation
  • the build
  • implementation