My thoughts are with people from my community over in London. Reading agile planet yesterday, I was touched by a very eloquently written eye witness report from Mike Roberts (on the bombings two weeks ago).

Curve has been playing my car stereo recently. This quote from Die Like A Dog resonates:

Peace in a world free from religion peace in a world where everyone gets heaven

Keep on rocking', keep on bloggin'. Back to the regular programming.

I'm currently developing a course on agile software development ( eXperience Agile) and a course on pair programming. I've been puzzling on pair programming before, and now seems a good time to pick up this thread.

I stumbled across Flow, stuckness and interruptions over at recycled knowledge:

Stuckness cannot be overcome by will or planning, only by insight, and the arrival of insight is not predictable.

One of the things Pair Programming and regulalry switching pairs helps me with is getting unstuck. Rob Westgeest and I completed the first run of eXperience Agile on monday. As we do with software, we develop the course iteratively. After this first version, we were looking for ways to simplify the code and support scripts we use for the programming case, an online auction system dubbed Agile Auction.

Observing both teams in the course competing, I got the feeling there were just a few too many steps between adding a new feature and having it show up on the auction site. I knew we could remove some, but wasn't exactly sure what. On tuesday, I was pretty exhausted, and was stuck thinking of improvements, so I decided to relax a bit. At night, I drove to Mechelen, Belgium to attend the pair programming party.

I put up some stories for our website acceptanc test framework rintegration. I also had some wishes for Wiki2Go. I wanted to have what I call Rublets - small bits of ruby application embedded in a wiki page. Pascal van Cauwenberghe said:

Funny you should mention that, I was just working on something along those lines...

Pascal wants the registration form for xp day benelux as part of the wiki (we use a wiki as back-end for the conference website), rather than as a separate page. So far, I hadn't delved in to Wiki2Gos sourcecode, as I'm just gladly using it. The funny thing is, that Wiki2Go is like Agile Auction written in Ruby, so that gave me an excellent opportunity to compare and get some fresh ideas.

So, what did I learn from working with Pascal? The Rublets feature was fairly easy to build (if you leave out security issues..), as it basically means opening up the templating system already present. Pascal's way of dealing with requests coming in from a browser was a bit simpler, so that enabled me to remove a step from agile auction on Wednesday. Pascal's approach to integration testing a cgi application is also different, as was the development environment he used. That was interesting to see.

What made it difficult for me to 'drive' while pair programming was the babylonian collection of keyboard layouts we have in Europe - just one hours drive and they're using AZERTY keyboards, which I as a QWERTY touch-typist have a lot of trouble with...

After about one and a half hour Rublets in a basic form were done, and we celebrated with belgian beer and looking around to see what the other pairs had done. Johan Peeters and Christian Neumanns had tried to build a web-proxy to simulate phishing - to see how and if websites can protect themselves against phishing attacks. Sven Gorts and Hans Keppens had worked on brainstorming session for xp day benelux.

Fun to see that agile people everywhere use similar ways of coming up with sessions. Hans and Sven sat around a table with a stack of index cards. They had brainstormed about six sessions, and afterwards they asked what sessions would have the most value - they're also going to ask their colleagues that.

So, at the end of the evening, I drove home with a ton of new ideas, new inspiration and Rublets for Wiki2Go. Beforehand, I wasn't sure how much fun a pair programming party could be, but it was :-) Especially if you start off your evening with belgian food and beer on a sunny terrace... Needless to say, I wasn't stuck anymore.

There has been a lot of debate (and I saw many session proposals around the topic) on Selling Agile. I believe it is best to sell as little as possible; make agile easy to buy by focusing on benefits and specific situations. Focusing on practices and how agile is different from other approaches works less well.

Working on projects, and going to conferences I heard many, many benefits, so the problem is not whether there are benefits, but more how to condense them, and make them specific to a particular audience. Marc Evers suggested storytelling, Nynke Fokma came up with making benefits for a particular role (e.g. an HR manager or executive).

I've just started a mind-map to work out the benefits per role for myself. Here's what I came up with for an HR manager (I've abbreviated HR, as I find applying the word resource to describe people to be old-fashioned).

Some Benefits of Agile for HR managers

• Less sick days
• Higher staff retention
• Easier hiring
• Higher employee satisfaction

Employee satisfaction is what it boils down to, really. People in a well running agile team are happier, because they are more productive, work with less interruptions, have good rapport with customers and management and generally feel they have a place they belong (remember the theme from Cheers?).

This results in less sick days (some people report a fifty percent decrease in sick days). As for hiring and retention, I asked a friend of mine why agile doesn't spread in his organisation, while his group is growing every year. He said:

People don't leave, because they enjoy working here so much, and as they tell others, others come to apply for a spot here as well.

If a team or group functions like that, hiring and retention almost become a non-problem.

The session was very interesting, however I did not get the "aha!" effect during it. The effect came later:

I always had the feeling that it what not possible to improve my communication or management skills. It was possible to improve the technical skills, but not the "soft" skills: one was a communicator or was not. Actually, this is false. It is possible to improve your communication and your management skills: that's what did the Balancing Act for me.

The closest I could come in one word is special. In the closing temperature reading participants appriciated the open atmosphere, where they listened and where heard, as well as respected. Seeing the level of engagement of everybody inside and outside the sessions, we succeeded in creating an open environment, safe for experimentation and risk-taking.

To my pleasant surprise, the conference turned out to be even more self-organizing than I hoped. Before the conference, we weren't exactly sure on how to run the opening session. The main goal of that have all participants to co-create the conference program. One of my biggest fears beforehand was that not everybody would have noticed that Agile Open is an open space conference, where the participants are responsible for the program. In a way, we created a sort of hybrid between an open space and a planned conference, by creating an ideas for sessions space on the conference wiki.

It turned out that my fear was on the mark, as about five people reported they weren't aware of the open space character. Pleasantly enough, they didn't feel this was a problem. It feels natural to start an agile conference with a planning game. They immediately took to the idea and participated actively in selecting the sessions.

Deciding which sessions to vote for is hard...

The way to vote and prepare the program emerged during the opening session. We envisioned this would be the moment to create the program for Friday as well as Saturday. After arranging sessions for the first day on two tables (one table per room) we found that the most popular sessions were scheduled on day one. The participants decided to have another planning game at the beginning of day two, so we could use what we learnt on day one, and choose the sessions we felt most strongly about on that day.

I facilitated the opening session on friday, the temperature reading in the afternoon and co-facilitated a few track sessions. I was quite exhausted after that, and excellent conversation at the bar. As Rachel Davies points out in her weblog we succeeded in moving the usual bar conversation to the sessions. I partook in conversations on music, fashion, philosophy, history and friends that couldn't make it to agile open, amongst others.

On Saturday, I overslept, falling straight back to sleep after switching of the alarm clock. I believe this turned out to be a good thing, as the conference became more self-organizing. I couldn't facilitate the planning session like on day one. On the other hand, I was scheduled to co-facilitate two of the most popular sessions on day two - Balancing Act on thre of the Satir tools and Structured Crystal Ball Gazing, on scenario planning. Vera Peeters phoned me to ask what I wanted to do. Both Nynke Fokma and I didn't have the energy to do a long session, so I asked Vera to put on either one of the sessions.

What happened, was that one session was planned in the final slot, but not decided which one, so we could delay the decision whether to run Crystal Ball Gazing or Balancing Act to the last moment. That was cool. We felt that the playful, experiential and active nature of Balancing Act would fit most at the end of the conference. I'm glad we did that, since it was a lot of fun!

Balancing Act / Structured Crystal Ball gazing session back to back on the lower left

I gained some more experience in facilitating with several Satir tools. On Friday and Saturday we held a temperature reading to appreciate each other and things that were accomplished, as well as to gather information to steer the conference, and the future after it. For me it was a good exercise to facilitate more temperature readings.

half of the circle during the temperature reading. I'm the only one not laughing, on the left. Probably focusing...

In the last block on Saturday afternoon, we ran the Congruent Action part of the Balancing Act session. We had a blast during this session. I had prepared it with Marc Evers and Nynke Fokma, and they asked me to be lead facilitator. Scary. Exhilarating. Rachel Davies agreed to be co-facilitator as well. We were well supplied with facilitators :-) about one in five. And then we had Vera Peeters, who spontaneously performed some skillfull covert facilitation, keeping participants on board who otherwise might have left.

Make no mistake, this was a scary session, since it involved mime acting with strangers. We first let the participants explore coping stances in pairs(blaming, placating, superreasonable, irrelevant and loving / hating) as described by Virginia Satir. The facilitators demonstrated most of the stances, and then we let the other participants experiment.

Trying out the coping stances. Not sure what Rob and Marc are modeling here, but it looks fun

After this round, I was not completely convinced we had everyone on board. That changed after a round of questions. I asked how miming the coping stances felt, and if the participatns experienced a 'favourite' stance - some stances feel more relaxed or natural than others. In the final round, everyone was very much involved, even though it was more difficult. We asked the participants to we split in two groups to model the eXtreme Programming values. Below is a picture of one of the groups modeling an XP value. After twenty minutes rehearsal we let each group perform, and have the other one guess which value was shown. Can you guess which one is shown in the photograph below?

This would look better on film, where you'd see the hands waving...

That was great fun! After this, it was time for the closing. I felt a bit sad that it was over, and at the same time very glad for having co-organised it. Marc is already thinking about follow-on events, and judging the reactions of the other participants, this seems worth wile to do.

In hindsight, creating a repository is quite straightforward. I decided to create a special svn user and group, so svnserve doesn’t have to run as root. With -r we can restrict the places where repositories can be, which also makes it easier for clients to specify urls.

  su -c "svnserve -d -r /var/repositories/"  svn

To access the reposotory remotely was easy,

  svn checkout svn://willemvandenende.com/svn/project

Only problem: the checkout is read only by default. Checking out read-write I wanted to do with authentication. Two things are needed for that:

• add username and password to /var/repositories/svn/paswd
• supply password and username when doing a checkout of the project
  • subversion will (only?) prompt for a username when anonymous access is set to ‘none’
  • the alternative is to supply —username (seen in ‘svn help checkout’ )

so a working checkout looks like this,

  svn checkout svn://willemvandenende.com/svn/project --username willem