Oct
11

How does one make an XP Day Program?

The making of the XP Day Benelux program

The XP Day Benelux program has been published. The sessions were chosen (by the chosen few of the “Program Committee”) from the session proposals that were sent in. How does that work? As they say, if you want to enjoy eating sausages, you’d better not look in the factory where they’re made… With this warning, if you want to know how it’s done, read on. Let’s have a look behind the scene…

Software for your headFirst step: perfect session proposals

First, session organizers give each other feedback to improve their proposals. We use the “Perfection Game” format. This helps to get positive, constructive feedback. All the work is done on a wiki, for all session organisers to see.

My impression is that all session descriptions, even from experienced organizers, are better after receiving this feedback. Mine certainly are. I prefer to go through a few iterations, rather that have a “one-shot” at sending in a perfect session proposal. Session proposals are like requirements: those who write and read them have dreams of how this session will look like. Usually, completely different dreams. Asking questions and talking about them, helps create a common understanding. It doesn’t always work, but most of the time it does.

Your mission: design an interesting and balanced program

We have several goals for the program:

  • There should be a good balance in audience background: beginner, practitioner, experienced
  • There should be a mix of different subjects: technical, management, foundations and limits of agile, soft-skills “fluffy bunny” sessions
  • There should be a mix of different session formats: tutorials, games, simulations, workshops, discussions… Everyone has their favourite ways of learning about new things. Some people just want to hear how it’s done; others don’t “get it” unless they’ve experienced it.
  • There should be a good mix between local presenters and “international jet-setting gurus” who travel from agile conference to agile conference, like a rock act. 🙂
  • It must all fit in two days, with enough time for breaks, food and rest. Sustainable pace, you know.
  • We should not break any physical constraints: a presenter can’t present two sessions at the same time. Presenters who have more than one session should have some breathing room between sessions, so that they can relax and go to other sessions.

It’s not easy to solve a system with so many constraints. How do we do it? As with any question you ask an agilist, the answer is…

Index cards!

We put each session on an index card and try to lay them out on a big sheet of paper that represents the program. We can encode a lot of dimensions on a single card:

  • The name of the session is on the card, so that we know which session we’re talking about
  • The name(s) of the presenter(s) is there, so that we can spot conflicts
  • The size of the card indicates how long the session takes. The sheet of paper indicates how long the conference is. We can’t put in too many sessions.
  • The color of the card indicates the type of subject matter. It’s easy to see if the subjects are balanced.
  • Green dots on the card indicate how much experience with agile software development is expected of participants to the session. It’s easy to see if we cater to participants with different levels of experience.
  • Red dots on the card indicate how much the participants are involved in the session. It’s easy to see that we cater to the different learning modalities.
  • We have four tracks. Each track has a certain theme or subject, to help balance the program. For example, there is an “Introduction Track”, so that we know that about 1/4 sessions is geared to people new to agile.

From then on, it’s easy: we take the sessions in order. First the sessions that got the best feedback in the perfection game, the sessions that we think will appeal to a large audience, the sessions that we think will be the most interesting. We quickly put them on the schedule, just checking that we don’t create obvious conflicts. When the schedule is full, we resolve conflicts and imbalances by exchanging pairs of sessions, until we’re happy. The system is very similar to the one we used in the army to fill in duty rosters. Or as they say in “The Toyota Way“: Visual Control.

You can see the result. Do you think we succeeded? Or not? Let us know.

If you want to know more, I’ll describe the sessions in the program and explain why I like each of them.

1 comment to How does one make an XP Day Program?

  • […] One thing I liked was the heavy use of 1-minute presentations. In the morning, the presenters got to present their own stuff in a minute, to help you decide which presentation to follow. At the end of the day, there was a one-minute debriefing given by someone in the audience, about each presentation. Pascal’s blog contains much other interesting notes about the process of selecting and then refining the presentations. […]