How to fail an Open Space session

And the answer is: when you try to change the format until it’s not really an open space session any more.

Since 2011 I’ve been running and facilitating dozens of open space sessions in many conferences across various countries: at the Software Craftsmanship Meetup in Paris, in Socrates Germany, Socrates France, in Bucharest’s ITAKE, Agile France and so forth. It always worked fine, except twice. Precisely the two times I tried to mix the open space format with a more structured one.

A word on Open Space technology

Open Space technology is a beautiful format. Basically it’s all about people interested in a common topic joining to discuss it together, usually with a flip chart. It comes with rules that actually remind participants that they are the actors of what is going to happen, and these rules shape the expectations:

  • Whoever comes is the right people
  • Whenever it starts is the right time
  • Wherever it is, is the right place
  • Whatever happens is the only thing that could have, be prepared to be surprised!
  • When it’s over, it’s over (within this session)

And there’s the most important rule : the “Law of two feet”:

If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet, go someplace else.

Note that there is no moderator role, just a facilitator role to remind the rules and organize the very basics like time and space. Anyone can hijack a session, and the law of two feet is supposed to counter-balance that from happening.

The form does not promise much and there’s no guarantee you’ll be happy, but because it’s fully interactive you can do the steering yourself by suggesting, reacting, asking questions or answering directly. In practice this means you’re quite likely to be happy at the end. Except when you take risks and try to change the format.

A Tale of Two Disasters

At Socrates Germany 2014 I had explained monoids to many attendees. At the same Socrates the next year in Soltau I proposed a session to go further, which I called the ”Monoid Safari”. It was supposed to be a collective exploration to identify more examples of monoids in the business domains of the attendees.

I came prepared with a large slide deck “just in case”. I had it ready just in case I had to remind people of what a monoid is, or to show some of the examples of monoids I had already collected and described in the past. I wanted an open space session, but I had a full content for a talk as a backup. It should have been safe.

This one wasn’t really a disaster, but was not a success either. Most attendees had no idea what a monoid was, and they came to learn that. I quickly found out that my plan was not working, so I tried to explain monoids quickly to carry on to the safari. But still questions were coming: “do you have examples?”. “Oh yes I have some, here they are”. And I jump to the most appropriate slides to show some the examples, quickly. And still hoping to come back to the safari right after.

A few attendees got it fast and suggested interesting examples, but not much. At the end of the session, I was disappointed of the safari, while the overall feeling of the audience was that I could have explained better the concept of monoids. #fail

More recently, at DDD Europe in Brussels I had proposed an ambitious session called ”Bounded Contexts: the Illustrated Bestiary”. I consider myself knowledgeable in DDD and Bounded Contexts, which also means I have open questions on the edge of this topic. I thought this conference dedicated to DDD was the best place to find knowledgeable peers to discuss that and try to answer some of the puzzles. So I proposed this session, precisely because I do not have all the definitive answers.

There was an abstract, which was not meant for everyone:

From one entry in the Blue Book, Bounded Contexts have since evolved into a bestiary of mythical creatures like Bubble Context, Interchange Context or even “Uber-Context”, each with different rationales that somehow challenge their initial definition. We now have recurring relationships between them like in the Collaborative Construction pattern. We now know that Bounded Contexts are a solution thing, not a problem thing, but some confusion remains, and we can make the matter even more confusing with crazy questions like ”Can Bounded Contexts be nested?”, ”Are Aggregates mini Bounded Contexts?’ or ”Is it useful to say that legacy UI and DB layers are their own Bounded Contexts?”.

During this semi-structured Open-Space session, every attendee can contribute examples or feedbacks, ask questions and share their ideas and opinions on this topic. Contributions in any form (slides, pictures, code…) are also welcome prior to the session and will be be credited.

Given the topic is very abstract I had in mind to run for 1 hour, no more. And I was expecting just a few attendees. But the program generously planned two hours, and more than 40 people came in early, sitting in a very large circle!

20160128-IMG_7641
Again I came prepared with a slide deck covering each example and concept mentioned in the abstract, “just in case”. From the start it appeared that many attendees did not clearly know what a Bounded Context was, and they came to learn that more in-depth. So I started to explain quickly. As I felt tied by the abstract, I tried to cover all the questions, quickly. It was uncomfortable switching from lecture-style and then back to open space style, and again quickly, every 5mn. At this pace I was also speaking too fast, which combined to my French accent is a recipe for disaster. And it was a disaster!

The feedback from the attendees was quite harsh, and illustrates how the expectations were not clear, it was not a talk, and it was not an open space either:

  • “Even for an open session it could have been beter structured. At the end, I do not know if I learned something.”
  • “Although it was open space, it seemed like the speaker didn’t prepare anything. The crowd was waiting for some definitions, explanations to open the discussions, but these never came…”
  • “Speaker clearly did not master the topic. Also, the open space form was unknown to most of the participants, it was bland”
  • “The speaker wanted to organise a structured open space, but this approach had three problems: the speaker was not very understandable,  did not reign in the discussion, and he let loud-mouth participants walk all over him”
  • “Due to the fact, that there were no experts, no questions were answered. Instead I left with more questions than before. The content was with e.g. “bubble context” very specific and it was hard to discuss with the others without having knowledge about this.”

Some did appreciate, but still a disaster:

  • “Very interesting topic. However, the group was way too big to have a useful conversation. Left the session after 30 minutes.”

Some offered suggestions:

  • “be a bit more clear on what the format of the open space is”
  • “I dont think it was the problem of the speaker. But he expected a MUCH higher level of the audience. Wasnt really prepared to give a lecture about bounded contexts. A warning sign “only for experienced attendees” on the schedule would have help immensively.”
  • “Split the group into multiple small groups to discuss the topics”

It’s called a training?

Thinking about it, the format I was looking for exists and I know it well, it’s just called a training, not open space. And that’s funny since that’s already the way I do trainings! Although it may look like conversational, it remains actively directed by the trainer. In the ideal situation, the trainer does not have to talk that much, as the learning happen thanks to exercises, discussions and coding. But still, this is not open space.

However a training assumes that the trainer knows the topic completely. So how do we do when we want to create opportunities to discuss topics precisely to clarify open questions and to explore the boundaries of our knowledge? When there’s a pre-requisite level of knowledge to even listen and follow what’s happening? So far the best opportunities I’ve met were in conferences hallways, during random discussions with speakers and attendees, unfortunately always too short and usually without taking notes. Advanced topics can be discussed during open spaces of course, as it regularly happens in various Socrates un-conferences, but it’s usually between small groups, the topics are broadly defined, e.g. “Combinators in FP”, and the answers usually exist in the literature.

I’ll try again, but without pretending it’s open space when it’s not really. Or as a pure open space, hence without any commitment or hard promise, to relax the expectations. I’ll probably put myself in danger again from time to time though :)

 

 

Read More

Øredev 2013 – What you probably missed

Øredev 2013 was last week, and it was fantastic!

Sharing knowledge

Øredev is in Malmö, Sweden. It’s very close to Copenhagen, so you can fly to there and then take a 20mn train to arrive in Malmö.

It’s a fantastic conference, totally vendor-neutral (that’s very important). It’s big yet friendly, with a mix of well established topics and more experimental ideas. This year the theme was “The Arts”, and as a result it was deliberately provoking or weird in some aspects, and that is a good thing!

For me the highlights of the conference were the radical ideas brought by two guys with some experience in the business: Woody Zuill and Fred George (I’ll come to it in a minute). I also enjoyed a lot how Jessica Kerr @jessitron manages to make alternative ways of thinking more accessible and attractive for developer using mainstream languages like Java or C#. Unfortunately I missed @Bodil talks because the room was too packed to be even able to open the door…

Before the conference you can attend 1-day trainings, and I decided to attend the Value-Driven Product Developmentcourse by JB Rainsberger @jbrains. It’s a very good course, more advanced and probably not for beginners. I knew a lot about BDD and has attended other courses already, yet I still learnt a lot during this workshop. I missed other talks from JB, but I want to watch the videos since I had very good feedbacks from other attendees.

It was interesting to listen to experience reports (New Frontiers For In-House Legal Practice by Kate Sullivan, Data @ King – How we are able analyze 100M DAU by Mats-Olov Eriksson, Curiosity killed the cat, but what kills curiosity?by Ann-Marie Charrett @charrett, Less is more! – when it comes to art and software, by @JimmyNilsson) with anecdotes and honest accounts of successes, failures and evolutions of mindset.

Radical Ideas

The Øredev program committee likes to take risks and challenge the way we think about software, as demonstrated by Woody and Fred talks, but also through the talk Code as a crime scene by Adam Petersen Tornhill @AdamTornhill?. Adam tries to reuse forensic methods used for crime investigations to help on large legacy code bases. He built the tool CodeMaat to visualize likely aggressions on the code base based on these ideas.

More radically, Woody Zuill @WoodyZuill talked about the Mob Programming approach his team has been practicing for some time now. He does not claim you should do the same, and he explains that this approach is just the result of doing more of the good things as found during retrospectives. His team found that working together on one task at a time on one single machine at a time was good, so they decided to do that all the time. You must watch his talks: Mob Programming, A Whole Team Approach (Roy “Woody” Zuill). It includes a time-lapse video and is very interesting. It also challenges the way we think about work. What if what the actual “work” was actually what’s between what we usually call “work”?

Very radical too, Fred Georges @fgeorge52 talked about his approach of Programmer Anarchy, “because that’s what it is”. He’s now replicated the experiment at two different companies including a rather traditional one (the Daily Mail newspaper), and is starting again in yet another. Again he does not claim you should do the same, just that it works for them. Again using the power of retrospectives, they got rid of every role except just the customer and the programmer roles. They don’t use the usual software craftsmanship practices like testing and refactoring. However they take great care of the business domain, just like a trader and a developer working closely together can end up giving suggestions to each other, in both ways. As Fred says: “Power to the programmer!”.

This approach works thanks to the use of Micro-Services. This style of architecture in itself is also a bit radical, with a “rapid”, an ordered bus of all the events of the whole system, and a lot of very small, cohesive, disposable micro-services that listen and publish to the bus. You can copy-paste a service to create another, you can rewrite a service rather than make changes, you can plug your new service directly into production! It may sound chaotic but in my opinion this style is disciplined indeed.

Woody gave another talk No Estimates: Let’s explore the possibilities (Roy “Woody” Zuill). It’s really a beautiful talk thanks to the beautiful illustrations from his wife Andrea. Woody does a great job at making us question our need for estimates, what it really means and how it can harm. More importantly, he suggests that estimates are an obstacle against delivering something truly wonderful!

I was lucky to spend some time talking with Woody and Fred, and what they do is very exciting. It’s a paradox, but both still really follow agile values, despite taking huge liberties with respect to the usual principles and practices. Both Fred and Woody also know a lot about object oriented principles and made sure their teams was skilled in that too. However in each case the experiments are also biased because of the very presence of outstanding developers like Fred or Woody!

Testing is not just checking

Software development requires a mix of many different skills. Some of the important skills revolve around testing. At Øredev you could listen and talk to some of the most notable representatives of the testing community: Heuristics of Testability (James Bach) @jamesmarcusbach, Regression Obsession (Michael Bolton) @michaelbolton, Balancing ATDD, GUI Automation and Exploratory Testing (Michael Larsen) @mkltesthead?, (Curiosity killed the cat, but what kills curiosity? by Ann-Marie Charrett @charrett). Other talks (The Beauty of Minimizing Effort and Maximizing Creativity While Integrating Performance Throughout the Lifecycle by Scott Barber and The Psychology of Testing, by M isko Hevery) were also about testing.

I realized that testing is much much more than just checking facts. There is a whole universe of testing practices that you are probably not even aware of, and most of this universe cannot and should not be automated.

Software development is a creative job!

As part of the theme “The Arts” some talks were not about software development. I really loved the talk Shakespeare in Dev (Thomas Q Brady) and the opening keynote of the second day “The Creativity (R)Evolution” by Denise Jacobs @DeniseJacobs. Denise managed to trigger the desire to write, talk and share insights from many attendees in the room during her keynote!

My talk

I was excited to talk at Øredev on Friday after lunch: Refactor your specs! (Cyrille Martraire) The room was almost full, which may suggest that the topic is of interest for many. As a speaker I loved the professionalism of the staff doing the video, sound and organization all around so that everything runs smooth for everyone. Thanks a lot to you all! Overall my talk was well received and I had many good questions and very good feedback’s. As I said, this talk is just the beginning of a conversation that will go on, so feel free to contribute.

All the Øredev videos are available on this page: http://oredev.org/2013/videos (still not complete at the time of writing), so have fun and enjoy them all! Also have a look at the #oredev hashtag on Twitter for more quotes, and don’t forget to follow me at @cyriux on Twitter!

20131115-200133.jpg

20131115-200223.jpg

20131115-200244.jpg

20131115-200255.jpg

20131115-200340.jpg

Read More