me.andering – Willem van den Ende

Nat Pryce wrote me about the previous entry:

I just read your blog post about the review processes for XP Day Benelux and London. I just want to assure you that all submissions will get feedback. If the review process doesn’t provide feedback to some sessions the programme committee members will write three (or more) reviews for those sessions before deciding the final programme and informing the presenters of acceptance or not.

I’m glad to hear that all sessions will get feedback. In the past, feedback on session descriptions has helped me improve both the session itself and its description. See e.g. the differences in the way we described Balancing Act the first edition written more from an organisers perspective and the second edition more compact and focused on tangible outcomes for the attendees.

How and when to involve the program committee in the review process was/is a puzzle for xp days benelux. This year some of us waited for the other reviewers to get started, and then the committee reviewed the remaining sessions. For next year, we’re toying with the idea on starting first, to encourage other reviewers to also start early.

After a fairly open review process and animated discussion in the program committee, the XP Day Belenux 2005 Program is now online.

The only ‘regret’ I’m having about the program, is that I’m not going to have time to attend many sessions, since I’m co-hosting three fun-filled active sessions myself :

• Gummibears

• Drawing Carousel

• Balancing Act

I’m proud of our more open review process this year, where we invited every session organiser to participate in the review process. We did the reviews on a wiki, so that everyone who bothered to review could see how others were working on reviewing sessions.

We were also happy to have plenty of sessions to fill two days instead of one. I’m hoping the program has a bit more air, and the participants have more time to meet each other (e.g. during the conference dinner on Thursday night).

XP Day London is taking this a step further, they are experimenting with a voting system (everyone who sends in a session gets five votes) and have made reviewing obligatory if you want to have a session accepted. I applaud their courage and am curious to find out how this worked for the program committee.

Sending in and reviewing was fun anyway. The program is not finished yet, reviews have closed yesterday. So far it looks like Balancing Act and The Agility of Domain Specificic Languages seem to stand a good chance of being accepted, since they each attracted five votes. Temperature Reading got three votes so far.

As a session organiser, I see one drawback in the voting approach – the Gummibears session description didn’t attract votes in London. It also didn’t attract any feedback, so it’s difficult to learn something for a possible next description.

Some sessions seem to have attracted feedback without votes, possibly because they are more controversial, or don’t fit well with the theme of the conference.

Anyway, exploring what works and what not in sessions, their descriptions and creating a conference program remains fascinating. I hope to write soon about how Rob Westgeest and I use mini-retrospectives to incrementally improve the eXperience Agile course.

Keith Ray wrote about Scott Berkun’s essays . I am particularly drawn to why smart people defend bad ideas . It describes some common ways of bad idea defenses, and some countermeasures. And it’s fun to read.

I don’t believe there is anything wrong with having bad ideas. I know I’ve had plenty. If you try to have only good ideas, you’ll be blocked. Generating many good and bad ideas, and deferring determination of their goodness or badness is key to

techniques like brainstorming, working in iterations and pair programming.

I believe the key is in defending bad ideas. I know I’ve done that too… Once you find out, through ruminating or feedback from the real world that an idea might be bad, you need to reconsider, or generate new ones. At least you have to be open to the possibility that an idea might be bad.

I’ve also been on the receiving end of other people defending bad ideas. I guess it’s a bit more obvious if you receive the “defense”. Actually the “defending” often feels more like an attack in disguise. It often goes through manipulation. Scott describes several manipulations, some of which I’ve encountered often. I may have used them as well, but I’m not really aware of that – manipulation works best if the one who manipulates isn’t aware of it…

If you’re not convinced about reading it yet, let me offer this quote:

[..] Worse, if they got away with it when they were young (say, because they were smarter than their parents, their friends, and their parent’s friends) they’ve probably built an ego around being right, and will therefore defend their perfect record of invented righteousness to the death. Smart people often fall into the trap of preferring to be right even if it’s based in delusion, or results in them, or their loved ones, becoming miserable.

So, the next time you’re attacked by someone defending a bad idea, have pity on them. It probably hurts them much more than it hurts you.

The next time you feel miserable defending an idea, think again… It may be a real bad idea to defend this one…

The incrementally improved Balancing Act workshop has been accepted for xp day germany. It’s quite likely that it’s also going to run at xp days benelux, as it got a top rating after the first round of reviews.

While reading getting things done I came across this quote, which aptly summarizes the workshop experience:

It is easier to act yourself into a better way of feeling, than to feel yourself into a better way of action. – O.H. Mowrer

The thing I like about the internet, is that it easily cures me from believing to be original. Through Nynke Fokma and Lynne Azpeitia I got this link to

What business can learn from open source and blogging by Paul Graham. I am resonating a lot on this one.

So these, I think, are the three big lessons open source and blogging have to teach business: (1) that people work harder on stuff they like, (2) that the standard office environment is very unproductive, and (3) that bottom-up often works better than top-down.

Ever since reading The Timeless Way of Building, I’ve been looking at many office environments with bewilderment. Usually, they’re not the right place to be creative. Even with all the values and practices of agile software development that can make it more predictable, It takes time to play and reflect to arrive at truly simple solutions. If I want to solve something, or ever write,

I’m usually better off going into the garden for a bit. How many offices do you know that have gardens?

At the end of the piece Paul Graham goes into startup culture (as most startups start out of home). When people ask me what it is like to run your own company, like I do, I usually say (with a smile) ‘don’t try this at home, kids’. But, as Paul Graham writes:

And as the example of open source and blogging suggests, you’ll enjoy it more, even if you fail. You’ll be working on your own thing, instead of going to some office and doing what you’re told. There may be more pain in your own company, but it won’t hurt as much.

I had some pain, it does hurt, but not as much. I ‘ve met people who paid far more ‘learning money’ than I did (so far). If something goes wrong, I’ve got only myself to blame, I can learn, and try again. Recently I find, that I am finding more and more the work I excel at and enjoy. As Lynne says: ‘live the life you imagine’.

I believe that the growing popularity of blogging, open source, wikipedia, Dilbert, agile (software development) and starting your own company is no coincidence. People are looking for better ways to live and work, and many are no longer waiting, like children, for their employer to make this happen.

Do I believe it is possible to achieve this inside companies as well? Yes, if you manage to change slowly, work with proven results, and keep playing the ‘professional’ games necessary to keep you in step with the rest of the company. Many agile teams enjoy more fun and productivity, and other ways of working and more respectful interactions are spreading. For most of us, it’s probably easier to try other ways on our own, or within the confines of a team (but watch out for being too succesful .

Some businesses can change from the inside, many business can change only if there is sufficient outside (e.g. market) pressure. Many more change into non-existance, because they are outcompeted. It’s no coincidence.

With me in this case. The world is also interesting, with many things going on on the energy front at the moment.I just arrived home from the pair programming party in Mechelen. I worked with Pascal van Cauwenberghe on our new project ‘hourensou’ (Japanese for spinach, and for a practice from the Toyota way). We’re building hourensou to help us level out the load for the various events we organize.

The amount of ‘stuff’ we have to do is getting to the level that some pragmatic automation will save us time. We’ve got about six people signed up to help already, as this will also be a fun exercise in making a ruby on rails application.

We also talked a bit about blogging. Pascal suggested making small deadlines for yourself and finishing ‘whatever’ within that deadline. So that is what I did, I made up most of this blog entry (and some more) while I drove back.

Agile Alliance election results

I was eligible as member for the agile alliance board, and I didn’t get elected. A friend asked me about the election results today, apparently they haven’t been made public or sent to the members yet.

Looking at the list of board members on the agile alliance website it hasn’t been updated for at least a year, so I’ll break the news then, this is what Rachel Davies mailed me:

The people who were elected this year are:
Mike Cohn, Rachel Davies, Jutta Eckstein, Ron Jeffries, Ole Jepson, Brian Marick, Angela Martin, Rebecca Wirfs-Brock.

I congratulate the new board, and wish them a lot of fun in a year where the alliance continuously delivers value.

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.

I’m creating a course for programmers and a presentation on agile project management. I’m creating slide decks from scratch, as I want to reflect changes in the field as well as my changed insights. As part of the presentations, I’m starting of with benefits, as in, what can participants do with the material.

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.

Marc Evers made me aware that Bernard Notarianni wrote about Balancing Act in his report on agile open. Nynke Fokma said, that this session would have impact on some participants long after the workshop, perhaps even months. I’m still learning from facilitating it. Apparently, impact came relatively quickly for Bernard:

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.

At agile open, we ran only part of Balancing Act (the part on congruent action, how to actively balance self, other and context ). . I’m working with a group of facilitators to co-market this as a self-contained course. We’re now working on making a description that is more suitable for marketing it. Seeing the feedback we got from the trial run, this seems time well spent.

I’m recovering from two fun, intensive and moving days at Agile Open . During the conference, at one of the temperature readings we held, there was a little discussion about the usefulness of session writeups. Since there were many experiential sessions, it is very hard, or maybe impossible, to put into words how it felt to have been there. The same probably holds for this conference as a whole. I’ll try to give my impressions here, with quoted conference photos kindly collected by Marc Evers.

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.