Other ideas (e.g. for non-session activities) will remain welcome until the end of the conference. This conference is what the participants make it, the co-organisers provide the container that makes events possible.

So far, we've had a lot of positive reactions, also from people who won't be able to attend - some want to register for 2006 :-) . I'll keep you posted on the feedback I get and other stuff that's newsworthy.

I'm looking forward to Agile Open a lot. It is so cool to see something like this grow.

There are people who never learn from their driving experience in snow or ice. Every year, they're surprised by the snow or the ice, and they drive too fast (or too slow). These people may have plenty of years of driving experience, but it's the same year repeated over and over again.

Unfortunately, they did not seemed to have learnt to work better as a team. At first, I was relieved that we didn't have that many meetings, and I could 'just do my job (programming)' ( I'm different these days....). Until after a few months it dawned on me, that the team was chasing the same defects over and over.

This was easy to trace, as the group had nailed down several practices quite well. Every night an extensive suite of integration tests was run, and defects were collected in a defect tracking system (do you notice how I refuse to use the magical word 'bug' here?). Defects were closed and then later on re-opened. Sort of teh same defect repeated over and over again. In the end, the company was taken over, and this particular product was never released, because the new parent company preferred their own version of the product (how strange).

The group was very good at what they thought was their task - programming C with some ++. That is how they recruited new team members as well. I remember a conversation with my boss about a job interview. One of the things they did was see if the applicant understood certain language constructs. My manager exclaimed in surprise to me, 'this guy did'nt even understand ... (some obscure use of the C union construct)'. The uninon construct had at that time been made entirely obsolete by classes in C++. I was smart enough to keep my mouth shut, as I had never used the union construct much, and did not know about this particular use of it either. My manager was very happy about my performance nevertheless....

Years of experience had given her detailed understaning of the C union construct. What the team needed was detailed understanding of team working. Despite the groups individuals being highly intelligent (individuals had MsC's, PhD's, patents granted, creative testing skills), the group as a whole had years of experience of the same thing and did not function as a team.

What this group needed was not a new recruit intimate with language details... People can pick up details or entire languages quickly from working closely with teammates.

I enjoy experiencing the development of Agile Open. We try to keep involvement in organising the event as open as possible. So we now have more goals and start to have preliminary ideas for sessions on the wiki and the mailing list now has a lively discussion on what the schedule can be like. Even though we do not plan the sessions, we do plan to create a container around it. So far, we have an opening session, with an explanation of the process and announcement and selection of sessions. At the end of the first day, there is likely to be a temperature reading so the conference can be modified while it is running followed by a conference banquet of some sort, and there will be a short re-opening session and a closing session on saturday.

We will not select sessions before the conference, as that is done by the participants at the first morning of the conference. I want to make that extra clear, as we are having difficulty getting the way the conference works across, especially for those who have not yet attended an open space conference. It is not two days of unstructured chatting, nor is it a pre-defined conference (as the IdeasForSessions page suggested to an Open Space veteran). So it is both possible to have fun with creating sessions beforehand, as it is to propose a 'in the flow' spur-of- the-moment session on the morning the conference starts.

For your information, I post the full text of the invitation below:

Agile Open 2005
1st Internatonal Open Space Conference on Agile Software Development
29 and 30 April 2005, Mechelen (Belgium)

http://www.agileopen.net

Movements really rise or fall on the strength of on-going social occasions - XP user group meetings, XP Days, Agile Seminars, XP and Agile conferences, and the Agile Open Conference are the epicenters of the agile movement.

The Agile Open conference is an international OpenSpace conference intended for software development and business people from all walks of life, taking place on 29 and 30 April 2005, in Mechelen, Belgium ... we invite you to an amazingly open, warm and lively community space where people spark new insights in and relationships for collaborative (software) development and doing business together.

Agile Open is for participants, by participants: we determine the actual program together at the start of the conference. We do not expect people to invent all the sessions on the spot, so we encourage you to put ideas for sessions on the conference wiki. Any ideas for sessions you would like to experience, or hear and see happen, as well as ideas for sessions you would like to organize and facilitate are welcome. Equally, this page gives an impression of the variety of sessions you can expect at the conference:

http://www.agileopen.net/Conference/IdeasForSessions.html

Location

The conference will take place at Elewijt Center, in Mechelen (Belgium): http://www.elewijtcenter.be The center is near an international airport and train station (Brussels). The Elewijt offers a limited number of rooms. We offer our help in making reservations and encourage hotel room sharing.

Fees and Registration

We have limited the number of participants to 60, on a first paid, first served basis. Until April 8th, the conference fee is 180 Euro (exclusive of 21% VAT); from April 9th, the fee is 230 Euro (excl. VAT). The fee includes conference access, lunches, drinks, one dinner, and closing reception.

Registration is possible through http://www.agileopen.net/Conference/Registration.html . On-site registration is not possible.

Organization

Agile Open is organized on a non-profit basis by Agile Systems vzw (http://www.agilesystems.org), a non-profit organisation with the purpose of collecting and disseminating knowledge and experience about agile software development and systems thinking. The conference organizers are:

Marc Evers (NIWI-KNAW), Willem van den Ende (Living Software), Nynke Fokma (Moebius), Pascal Van Cauwenberghe (Nayima), Vera Peeters (Tryx), Marko van der Puil (Brains4All)

Idleness as a waste of time is a damaging notion put about by its spiritually vacant enemies. Introspection could lead to that terrible thing: a vision of the truth, a clear image of the horror of our fractured, dissonant world.

I have gotten some of my most disruptive ideas when forced to stay in bed for days because of illness. For instance, the decision to become an independent consultant came to me, when I was admitted to hospital for over a week, back in 2001. I was striving hard to get various things of the ground (and working hard to that effect as well). When I was admitted to the hospital by surprise (so the neurologist could run a lot of tests in a short time) I was, so to say, stopped dead in my tracks.

Having nothing to do for most of the day besides a little reading, I pondered what things I could do to increase my effectiveness. After a few days of lying in bed, I realized I was not getting anywhere. This was disruptive, because until then I was living under the assumption I had found my dream job. I realized it was time to do something else.

After a week at the hospital, I became an outpatient. I stayed at home another week. Because of the heavy antibiotics I got, I was too tired to do much, so I spent most of my time just sitting in the garden (yes, summer can be an excellent time to be ill). Spending this idle time, with some reflections on life which hospital visits seem to bring inevitably, was a major factor in my decision to explore independent consulting as an option.

It is not guaranteed to work - not every time I get lay in bed ill, I get disruptive ideas. Introspection remains scary. There have been times I was scared to go on holiday, in case I might get those disruptive ideas. Especially, since at first, I have only an idea of what is wrong, not what could be done to remedy the situation. I'm trying to spend more idle time now.

When I started my independent consulting, I imagined I would have more time like when I was in university - just visiting people, hanging out, chatting on the couch. Instead, I have worked more hours than ever before... So recently, I'm making more time to travel and hang out with friends and colleagues.

through a post by William Pietri in the XP mailinglist I came across The 6 Myths Of Creativity By Bill Breen in Fast Company magazine. If you believe Creativity Comes From Creative Types or Time Pressure Fuels Creativity, I recommend you read this article. If you don't believe it, and need proof, read it too :-). Other myths: Money Is a Creativity Motivator, Fear Forces Breakthroughs, Competition Beats Collaboration and A Streamlined Organisation is a Creative Organisation.

Creativity suffers greatly during a downsizing. But it's even worse than many of us realized. We studied a 6,000-person division in a global electronics company during the entire course of a 25% downsizing, which took an incredibly agonising 18 months. Every single one of the stimulants to creativity in the work environment went down significantly. Anticipation of the downsizing was even worse than the downsizing itself -- people's fear of the unknown led them to basically disengage from the work. More troubling was the fact that even five months after the downsizing, creativity was still down significantly.

In one organisation, middle management is unsure what is going to happen, so they try to shape up their department so it looks as good as possible. They try to stimulate creativity by fear (e.g. 'if we don't do such-and-such we will look bad in the review, and our department - i.e. your job - won't make it'), they put on pressure and try to bypass the formal planning process.

This might work for a weak or two, but over a longer period, quality of the software developed and systems running in this department is decreasing ever so slightly - making it more and more likely users will start to complain, and make the department look bad in the review. With all the time-pressure and task-switching the team is more likely to make errors, because they have less time to communicate with one another, and stop the line to identify and solve root causes behind problems. Mmmm. sounds like a Diagram of Effects in the making. If you happen to have one about this problem lying around, please let me know!

On a related note, Nynke Fokma has just made a Diagram Of Effects of short and long term effects of Cooperation versus Competition based on the Prisoners Dillemma. showing that in some cases (for two parties), competition might seem to benefit one party, but in the end each can only gain by collaborating. One thing that seems obvious to me, is that both parties spend a lot of time computing trust. Time they might better spend in coming up with a creative solution...

When reorganisations last too long and people are uncertain, I see competion for jobs not only between departments, but also between individuals. The backstabbing, lying and manouvering is not pretty. That might explain why it takes so long after a reorganisation for creativity to return - people simply don't trust their coworkers anymore. To paraphrase a Dutch anti-alcoholism ad:

Een reorganisatie maakt meer kapot dan je lief is..

(rough translation: A reorganisation wrecks more than you'd like).

Every now and then, someone else will ask me questions about the past, since I don't rehash voluntarily anymore. I prefer to work on the future. Marko van der Puil asks me how I reconcile that with facilitating retrospectives.

To me, retrospectives are as much about the future as they are about the past. We collectively investigate a set period in the past, to achieve closure on the past, and determine concrete actions for our future. If a retrospective doesn't turn up personal and collective actions for positive change, we might as well have skipped it altogether.

Luckily, I read the paper before going to the workshop - that left some room in my head to fill some of the gaps in my understanding the paper had left me with, rather than being overloaded (as most of the workshops' participants seemed to be. It made quite an impression). By the way, the reason I read the paper was that I was wondering if paying to attend this workshop was worthwile. Since after reading I still had many puzzles, I thought it would be, and it was. I'm still ruminating over these ideas.

One of the ideas that resonated most with me was the Cynefin Domains model. It is sort of a two-dimensional matrix. The paper has a nice graphical depection that makes it clear that the boundaries between the domains are semi-permeable. One way I understand this model, that an organisation can move from one domain to another by making sene of where it is now - and seeing if the paradigm it currently applies for e.g. decision making is appropriate. I've transcribed the four domains into a table:

To give one illustration (more in the paper mentioned above) Systems Thinking and Scenario Planning fit into the Knowable domain. Someone at XP Days London asked me if I didn't find it annoying that Dave Snowden sort of mowed the grass before my feet; Marc Evers and I were hosting a Systems Thinking workshop at XP Day London the next day.

I responded that I was very glad for the context setting Dave Snowden had done - we used the Cynefin Domains model in the introduction of our workshop, as we are constantly looking for a better way to briefly introduce Systems Thinking at the start of a workshop. I am not Systems Thinking :) it is one of the techniques I use to make sense of the world around me, if and when appropriate.

So how do I believe this model relates to appropriate forms of setting up an organisation? I immediately related this to Gerald Weinberg's Cultural Patterns (aka Shooting and Aiming Stances) for organisations, so I came up with this mapping:

The Congruent cultural pattern would be equivalent to sensemaking: taking self, other and context into account, and choosing (and changing, if the domain shifts) a cultural pattern that is appropriate. When I was reading the wiki page on Cultural Patterns I realized I forgot Oblivious. Thinking about it now, I find it hard to place. Maybe the oblivious cultural pattern is not realizing where you are, and not making any choice for an organisational form.

The connection was somewhat natural, since with a group of systems thinkers we've been thinking about how to move from one cultural pattern to another. In the workshop and paper, Dave Snowden says they've identified a number (27 if I remember correctly) of specific choreographies to move from one domain to another.

For instance, working iteratively is a way of moving from Known to Knowable and back, and moving from Knowable to Complex can be done by Exploration (to move in the opposite direction, use Just-In-Time Transfer).

Dave Snowden talked about the relation with eXtreme Programming. At first sight, I would place XP at the Known/Knowable boundary, because of the Iterative aspect. He seemed to place it in the Complex domain which left me a bit puzzled.

The way I could place it there, is that XP also has an exploratory component (e.g. doing spikes), and the extremely short iterations make it possible to investigate multiple alternative solutions (relating to what Snowden calls probes, exploration and to Set Based Development). Another component to XP/Agile is delaying (design) decisions as long as possible, which relates to just-in-time transfer.

I just noticed I'm using a lot of emphasis in this post. It seems to have a high jargon density. I'm looking forward to the article collection promised at cynefin.net, so I could upgrade some of the emphasized words to hyperlinks. In the meantime, I recommend you read the paper if these ideas interest you. I'm also interested in any comments you may have on this blog entry, as I'm busy understanding the Cynefin paper.