Most of the preparation is done individually, by organisers dispersed over several places in The Netherlands, Belgium and France (and sometimes the states). Most of the communication is taking place through e-mail and Internet Relay Chat meetings. It turns out, that often coordination of the work is more work than the work itself... I just put the session descriptions from the website into a document. That took me about twenty minutes, which was much less than deciding who was going to print them ;-). I'm sure we'll find ways to do this more efficiently in the future...

My favourite way of organizing is still doing work co-located, as for instance this picture from a program committee meeting shows:
Nynke Fokma, Peter Schrier and Vera Peeters working on the conference program

Modifying the conference program is quick and easy during a pc-meeting. We take the latest version from our website (yes, the website is conventient for broadcasting the program to participants and session organisers), transfer it to post-its, and juggle around the program on a whiteboard. We then take a photograph of the end-result, and someone (usually Vera) ensures the broadcasted program reflects the one on the whiteboard.

So, I'm almost off to the conference location, to do a last check of the rooms, the internet connection and maybe do some set-up work already. May-be I'll see you tomorrow. I'll put some pictures up somewhere next week.

In a previous entry I already went into Jean Mc Lendon's great session on Satir Systems Coaching, so I won't repeat that here. The sessions below are the ones that stand out in my memory at the moment.

Interviewing with Ease

Most hiring managers in the group were having problems with large amounts of applications for each open position. One has to strike a balance between the amount of time spent interviewing people, and the chance of a 'bad hire'. Hiring someone you later have to fire is very expensive, in terms of both costs and morale in your teams. Having an HR department do screening before you as a manager with more technical and functional knowledge before you can seem efficient, but they can easily put off the best candidates, or fail to see through tricks by not-so-good candidates.

Johanna recommended coducting so called phone screens, with the most important dissatisfiers early in the phone screen. A phone screen is a scripted telephone interview (in the same vein that is used for telemarketing). An example of a dissatisfiers is e.g. 'are you willing to travel 25% of your time' - if that is required for the the job and the applicant says no, you can end the phone screen right away (don't forget to thank the applicant for their time of course). In 5 to 15 minutes you can quickly decide which persons you want to invite for an interview.

We spent some time thinking about (il)legal questions. Surprising to me, the USA is quite highly regulated with respect to questions you can not ask. Whenever I met someone, they would often ask 'where are you from', and 'where are you based'. In a job interview it is illegal to ask about the applicants place of birth apparently, whereas this is a default component of a Curriculum Vitae in The Netherlands. Questions about fluency in certain languages are only permitted if they are essential for the job.

The group then did an exercise on Behavior description questions, these are a special kind of open question, asking the applicant to describe what he or she did in a specific situation in a past project. One can use these questions to find out relevant behaviour to the job in question, without spending too much time explaining about your current situation - job interviews are typically way too short to give both the company and the applicant sufficient time to go deeply into each-others' situation. An example of such a question would be "What did you do last time you disagreed with a team-mate? With a Manager?" or "What did you do when a customer was dissatisfied?".

An interesting trick that came up, is the so called "dirtbag test", to sift out the real assholes from the population.... If you want people in your organisation to respect each other, have a junior assistant call the applicants to verify something on the CV - if the candidate is not respectful towards the assistant, dismiss the application.

Panel interviews may seem efficient ways to conduct interviews, but they are in fact the opposite. See for an amusing story and more details Johanna's blog entries When Candidates Run Interviews and Panel Interviews.

After the workshop I decided to pre-order some copies of Johanna's forthcoming book Hiring Technical People, which looks promising, and useful to me when we decide to expand cq2's software studio beyond our current network.

Firing technical people

or, Managing team membership, who's in and who's out by Becky Winant and Steve Smith. Follow the link to see photos by Steve Smith. The workshop revolved around an exercise having two teams of participants ('team 1' and 'team A') stand on a flipover. With each round, the amount of available paper to stand on halved, leading to acrobatic situations like this:
"Sue and Deirdre on the shoulders of Vadim and others, Esther watching, Becky checking if all feet are completely on the paper."

The image above is of Team 1, my Team A was much less acrobatic, since we decided (it took me some effort to convince the others to do this :-) ) to tear apart the flipover and stand on separate pieces early on. Eventually, it got to the point where there was of course not enough paper for everyone to stand on. So I was the first to check out ("I came here to stand relaxed on a piece of paper, not do acrobatics - I need a beer") and go to the IFEP (Institute For Excluded People) where a bunch of Team 1 members had already gathered.
"I need a beer" - image courtesy of Steve Smith

After we stopped laughing from the game, we shared team exclusion and firing stories. Some of the suggestions that stuck in my mind:

• Have regular person-to person meetings with those who work for you. Don't do performance reviews once a year only.
• Don't delay difficult decisions (one participant reported productivity of his team tripled after he fired a disfunctional team-member) - after you make the decision, it is likely that everyone will be relieved, even the ones you let go.
• Give advance warning, be specific in your performance targets & reviews.
• If you want to be an effective manager, don't be afraid of firing someone - it is part of your job.

Collaborative decision making

I rembember most the three phase model for discussion, liberally translated in my mind as 'diverge, argue, converge'. To come to a decision in the converge phase, one can take a vote, using a continuum from 'veto' 'object but would not veto', '?', 'agree with reservations' to 'fully agree'.

Jim illustrated the importance of divergence with an example from Toyota, where they keep their options for a new car open as long as possible - until a car finally goes into production, they will develop more than one drivetrains, transmission, chassis and engine. This helps them solve problems with production - because not everything designed can be easily produced. If there is a problem with manufacturing, they can choose to one of the other options.

The diverge phase is akin to brainstorming, because we don't want to dismiss too many options.

I am looking forward to reading Jim's literature suggestion, "A facilitator's guide to participatory decision making" by Sam Kaner, as well as the book Jim is currently working on, "Agile Project Management".

Enhancing Your Personal Influence: From Novice to Maestro

The client and consultant were given instructions to this effect before the interview. Contrary to what is usual in this kind of game, the client and consultant were not given adversarial instructions. This didn't help the client I was observing in the above picture... The client kept asking 'are you the best consultant for this', and asked a question about price in the first 2 minutes - this helped setting an adversarial athmosphere... In a sense this meeting between client and consultant was a success, because they quickly discovered they were not a good match.

The next round turned out to be quite hilarious. Since I'm really starting to like roleplaying, I played consultant. In this round, the instructions were a bit different: the consultant had to give the best advice possible and get a fee for his work. When the client arrived, it turned out he wanted a travel consultant, to plan a trip to Maine. I quickly transformed myself into a travel agent, even though I did not know where Maine was :-) . Luckily the client told me he wanted to go there by bus, so I didn't have to suggest it... I also didn't know anything about available hotels and prices, so I stalled the client, asking him for a price bracket and promising to get back to him the following day...

It turned out both client and consultant had screwed each other a bit... The consultant got a price bracket below what the client had spent last year, and the client was working with a clueless travel consultant! Both client and consultant had a fairly good feeling after the meeting

So, I learnt that I've become quite proficient at sales meetings, although venturing too far out in the unkwown can be risky. The observers told me I had been making good eye-contact (which i've been working on in the past year). Next time, I'll ask even more questions.

Closing session

I'm back in the Netherlands, as you can see from the sunset I photographed from the car

What remains now is a few hundred photographs to sort out, cd's with photo's to send to several people and 'compile' all the events and, above all, , above all, to get some sleep. All in all it was a wonderful trip, the AYE conference, museum and historical site visits, and nature visites to Sedona and the Grand Canyon. Summarizing, I saw a lot of interesting sites, and met many interesting people, so the trip was more than worthwile.

Today I slept for about 15 hours, and I'm still tired.... The time difference between Phoenix and Utrecht is about eight hours, and I didn't get much sleep on the way over here, nor was I rested before - conferences and holidays tend to be tiresome with me - I use work periods to relax ;-)

Luckily, I finally bought the cd 'boy with the arab strab' from Belle and Sebastian last week, that got a lot of play during long drives in northern Arizona, so that's with me to keep up the atmosphere. The album is as good as most of the reviews had already told me, so I'm very glad with that.

Unfortunately my brand new digital SLR camera broke down the day I went to the Grand Canyon (Murphy has to appear in my trips somehow), so I took some pictures with my older camera.

I took some pictures in the corridor today.

Here are Dale Emery and Laurent Bossavit, looking at the Birds of a Feather registration board.

This is the Dorset House table, full of wonderful books. I didn't take pictures at the workshops today, because I felt (especially at the Satir workshop), that taking pictures would be too intrusive.

As I write this, I am at a Birds of a Feather session on Blogging (this column is a blog as well), with (from left to right in the picture) Laurent, Esther, Joanna, yours truly, Ron, Dale and Steve Smith taking the picture and Malcolm Currie... ). As a newbie, it is interesting to pick the brains of people who have been doing it for some time.

Laurent asked an interesting question: 'what stood out for you at AYE today?'. To me, it was Jean Mc Lendon's experiential session on Satir Systems Coaching, showing what it is about by coaching one of the workshop participants. Part of the process was a 'sculpt', which is a kind of role-play in mime. The sculpt involved a family situation of the coachee, and a work situation, then both situations were displayed together, and Jean asked 'what is different between those situations', 'what can you do now, that you couldn't do before?'. As she had said in the introduction, private and work life are closely connected.

What I observed about myself in this workshop, was that I'm really starting to like role-playing. I played the brother in the family situation, who didn't have the courage to support his sister, but instead decided to act irrelevantly. John, who played the father, approached me after the workshop, and said I really played the role very well, that maybe the role fitted well with my personality. I told him I wasn't sure about that, I can also be very good at blaming (If I'm playing a process policeman for instance), but maybe at closer introspection he's right...

The other participant's comments are at Johanna Rothman's Blog. A side effect of this BoF session is that my column is now published, since Johanna made a link to it...

 rm javadoc
 rm: remove `javadoc'? y

When you program TestDriven, on-site with the team, there is no need for this kind of documentation, I haven’t used it in years.

If I have to look at an unfamiliar piece of code, I prefer to work with a pair who knows the code. Failing that, the code is precisely documented by Unit Tests. Because the unit tests are always executed before code is checked in to the version management system, they can’t be out of sync with the code, unlike documentation.

• Jakarta’s Ant, a build tool in Java. Cumbersome, because it uses XML to specify its program, and thus clutters the screen with braces, dashes and quotes. More cumbersome, since it is a Java program we use to run other Java programs, so we have to do extra work to keep Ant’s classes out of the classpath of our unit tests and compiler. For others who want to run our builds, setting up a first Ant installation is not so easy, especially with Junit in it.
• Shell scripts for Bash. Easy to write if they are only a few lines without conditional logic. Beyond that, the team considered them to be unreadable.
• Perl scripts. Only one team member is fluent in perl, the others have no desire to learn it, since it is, like bash, not very readable. It is standard on most linux distributions so it requires no extra work for people downloading Itor source.
• Ruby. We recently started using Ruby for acceptance testing purposes. Two developers, including myself, are fairly comfortable with Ruby and the others thinks its’ readable and worth learning.

First up is the build script. We have to enhance it so we can use projects that depend on other projects (e.g. cq2’s Itor that depends on Itor-core). Modifying Ant build scripts took us one to two days for each modification, and there was only one person who understood it (me). Therefore we decided to start afresh with a build script in Ruby, if necessary build from scratch (without special build support). Luckily after the morning standup we found Rake in a google search. Rake is a ruby make replacement, its’ author, Jim Weirich, also dislikes XML and made Rake so that the build script is an ordinary ruby program with some extra support.

That means we can use the techniques we normally use to program: refactor (especially extracting methods), classes (if necessary)in programs, unit tests etc. The extra support comes in the form of a library of useful file-manipulation functions, and a dependency management mechanism in the form of tasks. Unlike in ant, there is little distinction between tasks and targets, so while creating your first build script, everything one has rapidly forms a library of reusable tasks. The dynamic nature of ruby makes the tasks easily readable and very compact (using blocks).

Getting our build to work was still a lot of work, both due to the not-so-simple way Java deals with classes and files and the configuration options of Itor inside the Java code (which are a refactoring target later this week). Programming the script in a pair on a windows box (the Itor server runs on linux) we decided to make the script cross-platform.

Therefore we had to get to know the correct variables in Ruby. The windows box, as usual, took a lot of time, since executables such as mysql and java were not found without adjusting the path etc.

Running the build now only requires that one installs Ruby (which is now standard in most linux distributions, and is installed under Windows with just a few clicks (much easier than ant). We included Rake’s sourcecode in the Itor distribution, so it doesn’t need to be installed separately. Ruby was necessary for the acceptance tests anyway, so it doesn’t add much overhead.

Conclusion

At the end of the day, we had a working compilation and unit test run on windows and linux. Under linux all unitests ran succesfully. On the windows box 24 unit tests still failed, probably due to classpath problems. The build script fitted (after some refactoring and simplification) easily on one screen, whereas before it was very long.

Still missing is sending an e-mail report for nightly builds and handling failures gracefully, but I expect that won’t add more than ten lines.

Two other team-mates looked at the build script and after some explanation (and some more refactoring thanks to their suggestions) it was clear to everyone what was in the build script.