Yesterday Claudia Rosu and I organized the first autumn Bucharest agile meetup. We had decided to organize it with an open space format, but  it ended up to be half about organizing an open space and half actually practicing the format.

What is Open Space?

The story of open space starts with Harrison Owen. He wanted to organize the best conference ever, and after going through all the trouble of doing it, he was surprised by the attendees’ feedback: “you know, everything was great, but the coffee breaks were the best”. He then realized that a conference that is only a coffee break might be better. Therefore, he defined the open space format:

• a conference with no predefined agenda (later named ‘unconference’)
• anyone can contribute to the agenda by proposing a session
• you can attend any session you want for as much as you want and move freely between sessions (due to the so-called “The law of two feet”)

There are a lot more you can read about the mechanics and logistics of an open space, so I won’t repeat that information here. See: wikipedia or these blog posts.

Personal View: Why Open Space?

I see open space as an event format for adults. I see traditional conferences where speakers speak and attendees listen very much like going to school where you hear someone spreading knowledge. Open space allows me to influence and build the agenda of the event according to my needs. I’m not only a passive listener; what I take from the event is my responsibility and I have the opportunity to exercise it.

Of course, this doesn’t mean a traditional conference can’t be interesting (TED comes to mind). To bring the same value to me, it would have to offer a lot of experienced speakers and plenty of opportunities to interact with them and with the other participants.

The Topics

After an introduction on the concepts and mechanics of open space, we decided to actually practice it. Due to the low number of people, we ended up having only two sessions one after the other. Of course, this didn’t prevent me to use the law of two feet from time to time 🙂 and move out of the session when the discussions were less interesting. That didn’t last long though.

The two sessions each worth a blog post, but I will quickly summarize a few conclusions

Session #1: Story points related to time

Should the estimation in story points be done with the time estimation in mind? Should we estimate tasks in time?

Story points mean the complexity of the story. The actual time duration of a story depends on a few factors: definition of done, number of people working on the story, how many stories are in progress at a certain point etc. The story point estimation is a relative one because most people are better at doing relative estimations (is your colleague John taller than your colleague Andrew) than doing absolute estimation (what is the height of your colleague John in cm?). The equivalent idea in story point estimation is to pick the simplest story as 1 story point and compare all the next with the already estimated stories. Easier to do than explain :).

Estimating tasks in time can be useful in the first sprints after a Scrum adoption, for one and only one reason: to be more certain that the stories planned for the sprint can be finalized until the end of the sprint. The reason is that in the first sprints, the team has no idea what the velocity can be, so they don’t know how many story points to plan. There are alternative ways for doing this: estimating velocity or just take an arbitrary number of stories and adjust in the next sprints. The velocity usually stabilizes after three sprints, and then the average velocity of the past 3 sprints can be used for the same reason as task estimation.

One of the side effects of using time estimations is that the burndown chart becomes useless. The shape of the burndown chart gives useful information about how much has been done and how to improve your process. This deserves a blog post by itself, so I won’t go into more details.

Session #2: Wall board vs. Online board

Should we use a wall board? Should we use an online board? Why?

The quick answer is: both. Physical boards are very useful for building engagement, visibility and flexibility. Not to mention that they can look very pretty, especially when set up on a window. Online boards are very useful for reporting and remote collaboration. While you could do reporting with the physical board as well, remote collaboration is more difficult.

If you’re just starting with Visual Management, it’s best to use the physical board first and designate someone (Scrum Master or the Kanban facilitator) to create the reports.

The Surprise

Despite being used with the format after attending 10+ open spaces, I was in for a big surprise. I’ve never been in an open space with less than 10 people and with less than two tracks, so I wasn’t expecting much. I still got two very useful insights:

Insight #1: Place the board on the way to the toilets, kitchen or coffee machine if you can. This might help team members update it more often.

Insight #2: If you’re doing Kanban, try removing a column from your board for a while to check if it’s really useful.

What’s Next?

The next meetup is already set. We’ll be trying a new format to practice story slicing, inspired from the software craftsmanship idea of ‘code kata’: “Story slicing kata”.