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

def testUser
	result = `exim4 -bt user@domain.com`
	assert(result.include?('user@domain.com -> /home/user/Maildir/'))
end

Please note I changed the username actually used to a fake value, to not attract even more spam. The test above verifies the correct routing by checkng the final delivery to the users mail directory. I've got similar tests for wildcards and a mailing list, because these required adjustments to the configuration in order to work. I didn't add tests for spam yet, if anyone has some feel free to contact me :-).

These tests are not fully end to end, as they test only the routing on exim itself. Especially for the mailinglist software, these tests only check that exim delivers mail to the mailinglist, not what the mailinglist does after that. Therefore, I added two other tests, that use the smtp module provided by ruby , one for an ordindary user, and one for a mailinglist.

For the mailing list test, I set up a special test list, with only one subscriber on it. Letting the mailing list test fail for the first time was interesting, as it fell into the mailinglists error handling. I try to specify as little information as possible in the test mail, so the first one was rejected because it contained an implicit destination - in e-mail, the To: field is optional, so I had left it out for the plain e-mail test I adapted the mailinglist test from. So now I am sure asserting that the body of the message is present is the right thing to test for - the error message from mailman does not contain the message body, only some of the headers.

The mailinglist test (names have been changed, to protect the innocent) looks like this:

def testMailinglist
	`rm /home/user/Maildir/new/*`
	require 'net/smtp'
	msg = ["Subject: Test\n", "To: some_list@domain.com", "\n", "Now is the time for a mailinglist\n"]
	Net::SMTP.start('domain.com') do | smtp |
		smtp.sendmail(msg, 'user@domain.com', ['some_list@domain.com'])
	end
	
	sleep 5 #wait for delivery
	
	dir = Dir["/home/user/Maildir/new/*"]
	assert_equal(1, dir.size)
	filename = dir.first
	contents = IO.readlines(filename)
	assert(contents.include?("Now is the time for a mailinglist\n"), contents)
 end

Note the sleep in the middle - the test has to wait a few seconds for smtp, exim and mailman to do their job and deliver the mail to the directory of the test user.

I'm quite happy with the automated tests - the testscript also auto-generates the exim configuration file for me, so it functions as a sort of automated build for the mailserver configuration. There is nothing as reassuring as

7 tests, 9 assertions, 0 failures, 0 errors

If you'd like to have the full source code for the testcases, contact me directly, as I don't feel like search-and-replacing the e-mail addresses etc. in the test. Feedback on the way I set this up is also very welcome.