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.


Drawing your process. Backwards.

Draw me a process

Rob and I made a small, but useful change to the “I’m not a Bottleneck! I’m a free man!” session at Agile North. During the second half of the session, we ask the participants to draw their process. Many participants have difficulty doing this. Where do you begin? Where do you end? Where are the boundaries? What to include, what to exclude?

At least now we know where to start…

Start at the end

My idea of funWe now tell the participants to start with the customer. Our work only generates “throughput” (value to the company) when the customer pays us in some way for something of value we give them. So, start by drawing the customer.

From the customer, work backwards. What does the customer receive, that they value? A piece of running software? Where does that come from? And so on, up the value stream. We noticed that the participants didn’t get stuck drawing their process. It did take some effort to get started. We are so used to thinking forward. It may take a while before you switch from “The customer gives requirements” to “The customer receives running, valuable features”.

The idea comes from the practice of Lean consultants to walk and map the value stream backwards, from the customer to the source materials. This helps you keep the customer perspective and see opportunities for “Pull” scheduling.

In Will Self’s novel “My idea of fun“, the main character and his evil guru (“The Fat Controller”) take a mental voyage from a cotton shirt they bought, all the way back to the cotton pickers near the Nile. Will Self invented the term “Retroscending” for this exercise. Next time, you think about your software process, try to retroscend.