me.andering – Willem van den Ende

We had a programme committee meeting for XP Day Benelux 2005 this week. Ideas from Agile Open are already cross-pollinating into the XP2005 workshop selection process, as well as (even more strongly) XP Day Benelux 2005.

For XP Day Benelux 2005 we are working on a more agile session selection process. So far, we had a semi-traditional process, where we put a lot of thought in the text of the call for sessions, made sure the candidate sessions received adequate feedback on the description as well as the supposed working of the session. The selection itself was BDUF (Big Design Up Front).

You could send in a session (I’m looking for a different word than ‘submit’ which suggests submission to the conference organisers – we are slowly and surely coming down from our mountain ), and then you’d wait for a month or two and hear wether your session was accepted or not (with an indication of why and why not). After that, we shepherded the accepted sessions.

Now we are trying to come up with a more SDUF-like process. The S can stand for Small as well as Strategic. We want to start shepherding long before the session deadline, and we want to open up the review and shepherding process, so session organisers don’t feel they are judged by an invisible elite. Last year we invited quite a number of people from outside the program committee. This year, we’re taking this one step further, by inviting everyone who sends in a session to be a reviewer as well. So we have four roles per session , three of which can be assumed by anyone involved: one or more organisers, a shepherd and three reviewers.

There is but one restriction: anyone can fulfil only one of these roles per session at the same time. Shepherds will announce their availability, interests and skills on a wiki somewhere (location to be defined yet). Session organisers are free to ask any shepherd they want – as long as the shepherd agrees. Reviewers can choose any sessions they wish to review – as long as there is no conflict of interest.

The fourth role is that of program committee member. Since the determination of quality has already been made in the review process prior to session selection, the program committee can focus on creating a balanced program. The program committee is semi-open. We’ve accepted a few new members this year after they asked to participate.

In a way, we are open sourcing the workshop creation pipeline we’ve been having with the people from Agile Systems. For a few years we’ve been collaborating on each others’ sessions. It is happening this weekend again, as the deadline for XP2005 workshops and tutorials is approaching. I can hardly explain how great it is to work with like-minded people on workshops, e.g. recently with Rob Westgeest on Rightsizing your unittests and Marc Evers on a series of Systems thinking workshops. This weekend I’m co-working on a session on congruent communication and interactions with Nynke Fokma and Marc Evers, as well as a session on value stream mapping with Marc. I may tag along on some other sessions as well. I hope we can scale this up through Agile Open and the new XP Days session generation process, so more people can experience it, and we get an even greater diversity of workshop and training material.

What we envision for the process itself is to start ten weeks before the final acceptance deadline. In these ten weeks, we offer session organisers the possibility to organise three iterations around their sessions. We are going to recommend organisers take a period of three weeks, and do all the iterations in this period. Such a short timespan enables the organisers to focus on their session, and not have to swap thoughts about the session too much. Three iterations is in my opinion a good amount. If it doesn’t work after three iterations it is probably best to leave it and try out another idea – not all ideas translate well into sessions. If the idea does work, after three iterations the organiser, shepherd, reviewers and program committee can have a sufficient idea of how it will work. Fleshing out the session further can be done between acceptance and running the actual session.

At the end of the first three weeks, we’ll already have some sessions in the conference pipeline, and the session organisers already have some idea if their session stands a chance or not, since it is already reviewed. At the end of ten weeks, we hope to have more than enough sessions for the programme. We’ll find other venues for the high quality sessions we can’t fit in the programme (e.g. we moved a session to an Agile Seminar last year). That is the end of the pipeline – finished, high quality sessions come out, and only scheduling remains.

I’m curious to see how this will develop. Worse comes to worst, we can always revert to old big up-front session acceptance. Something tells me we’re not going to have to – as the new process involves everyone much more.

I recently stumbled across Good Software Takes Ten Years from Joel Spolsky’s Blog. In this article, he recites from his own experiance and the brief history of software development a number of stories and common pitfalls of succesful commercial software products. Granted, these applications might not be my favourites to use (Lotus Notes and Microsoft Word), but they were succesful in the sense that they are used by millions of people.

Lotus Notes for instance, was released five years after development, and it took another six years before the user base started to really grow. As an example from my own experience, we’re using Linux on our laptops and servers, an open source variant of Unix. Unix exists since at least the 70′s. In the first twenty years of its’ existence, high-priced unix workstations and servers were mainly to be found in universities and corporate research and development environments. Now, after over thirty years, through Linux (and to a lesser extent, FreeBSD and its’ derivative, MacOS-X) it is spreading to a much larger user-base.

Starting last December, I am programming on the e-laborateproject. Not exactly a long-running project. It is, however, based on i-tor, open-source software that has developed through several projects starting January 2002. So, I-tor is now in its third year. Having been involved as a coach and programmer, I can recognize several of the pitfalls Joel Spolsky managed in the project.

Having been there, I can say, that it is possible to survive those pitfalls, even if you’ve stepped right in them.