me.andering – Willem van den Ende

Agile seems to become mainstream enough to regularly do open enrollment training courses. Rob Westgeest and I just finished setting one up, aimed at software developers who want to experience agile software development firsthand.

We mainly market it through our customers. In a way, the course is marketing itself – since the idea for Rob and me to do this together came from a customer. I hope to write more about how we created this course later.

In a three day hands-on course, Rob Westgeest and I introduce planning, test driven development and analysis skills that enable programmers to more effectively contribute to a thriving business. We combine explanation from our experience with immersive exercises and a multi-day case, resulting in a working system. You can find the course description, organiser bios and dates (all in Dutch – the course can be in English if desired) on the eXperience Agile website.

Today I had a really bright idea…. not. I wanted to safeguard my blog better, by putting my blog and website in subversion, a version control system. I was unaware that subversion does not maintain file modification dates of files after importing. For my website it doesn’t matter, but this weblog depends on the modification dates of the files to sequence the blog entries.

While I was at it, I overwrote my backup and the released version on the webserver. I noticed only afterwards the blog was out of whack. Some aggregators are also affected (i noticed agileplanet was). I re-dated as many files as possible, and those that couldn’t got an old date, so aggregators are not affected too much – in a few days the entries disappear from aggregators anyway.

It’s probably better to start versioning work right from the start, but its’ annoying subversion does not maintain the original dates on import nevertheless. I haven’t even found an option that makes it possible.

Registrations for Agile Open are trickling in – there’s a nice variety of people registering. I noticed several new ideas for sessions have been posted this week (agile

security, XpGame, DrawingCaroussel). Also, the conference schedule is taking shape, thanks to active participation

of various people.

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.

I’d like to point you to a blog entry by Johanna Rothman, What’s a Year of Experience? that clearly articulates a piece of a puzzle I’ve been having for several years. In recruitment and contracting, often a lot of emphasis is placed on how many years of experience a candidate has with X, where X is often a technology (less often a skill). Johanna gives the example of driving:

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.

I once worked in a group that had many years of experience programming C and C++. As I was a relative rookie at the time, I felt impressed at first. Until I found out that it was the same year over and over again… Yes, they were very familiar with the ins and outs of the language (those ins and outs haven’t changed in the eight years sicne that project, I was surprised to find out recently).

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.

After we opened the wiki and mailinglist the next thing to open up at Agile Open is the Registration.

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)

Through Evelyn Rodriguez I stumbled across The virtue of idleness by Tom Hodgkinson.

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.

Marc Evers Just points me to this blog entry by Erik Meade about XP values and XP in the large. Erik points to an interesting article in computerworld Sabre takes extreme measures. Large scale deployment of XP practices has enabled Sabre to achieve a 42 % productivity increase. Within such an environment (as in many) the XP practices and values indicate what to strive for. Even if, while striving, you don’t get to have all levers up to a 100%, you can still achieve a dramatic increase in productivity. A quote from the computerworld piece:

For example, fewer than 10 bugs surfaced in Release 10 of its Profit Manager software in the two months after it began shipping to airlines in December 2002. Now, 16 months later, just 100 defects have been found. Release 10 was written in Java, while Release 8 was written in C and C++. But Sabre says it was XP, not Java, that produced the dramatic quality improvements.

I used to believe choice of programming language to be very important to productivity. I now believe close customer collaboration and test driven development deliver much more value, as the Sabre example shows as well. Although, as Sabre moved from C++ to Java, they also were likelely to profit from automatic garbage collection (so programmers have to worry much less about allocating memory, a common source of defects in C and C++ programs).

If you want to find out more about agile/XP software development in large projects, I recommend Jutta Eckstein’s book Agile Software Development in the Large.

If you’re reading this, it means I managed to get wireless LAN working somewhere. I’m sitting at the airport in Denver, Colorado waiting for a very local flight to a place called Gunnison. I’m going to attend Consultants Camp, a one week open space conference. I have been to the smaller european offshoot of this event. I’m curious about the one here.

It takes place in Crested Butte, Colorado, which is located at an altitude of 3 km. Anyway, if you would like to meet up with me while I’m in the USA, send me an e-mail at willem – cq2 – nl (replace dashes with an @ and a . respectively). I’ll be in Crested Butte until September 13th, the week after that I’ll be in Palo Alto, California. I’ll be back in the Netherlands on the twentieth.

While doing a search for systems thinking related sites, I stumbled across an article Dancing with Systems by the late Donella Meadows, reflecting back on her long experience with systems thinking and systems thinkers. I can identify with many things in the article, so I find it hard to choose an appropriate quote. I chose the one below, as it has some relevance to the current elections in the US, soaring oil prices, as well as, in my opinion, a lack of feedback driven policies in the Netherlands. Also, I and others are currently struggling to explain feedback driven policies in organisations.

Make feedback policies for feedback systems.

President Jimmy Carter had an unusual ability to think in feedback terms and to make feedback policies. Unfortunately he had a hard time explaining them to a press and public that didn’t understand feedback.

He suggested, at a time when oil imports were soaring, that there be a tax on gasoline proportional to the fraction of US oil consumption that had to be imported. If imports continued to rise the tax would rise, until it suppressed demand and brought forth substitutes and reduced imports. If imports fell to zero, the tax would fall to zero.

The tax never got passed.

Imagine for a moment: what would have happened now with respect to oil if this policy got passed 25 years ago?

Today I’m working on an invited session for SPA2005 with Laurent Bossavit, shepherded by Rachel Davies . It is about freewriting, the session is called Lightning Writing Workshop. Freewriting consists of setting apart 5 to 10 minutes to write in one go continuously, without censoring yourself. Getting Started with Freewriting contains a brief explanation of the process, as well as some useful links on the topic. My main motivation to co-create this workshop with Laurents is to get myself restarted with freewriting, and explore one more way of writing in-depth.

I just tried a 5-minute freewriting exercise on a question Marc Evers asked me today: What does product management mean? The exercise didn’t come out with a specific answer, it did turn up some hints about what I think it should be: about a long-term vision translated in a concrete fashion to day-to-day actions, where software is developed in small increments without taking a mortgage on the future. I also started writing about some situations where I succeeded or failed to collectively do effective product-management with clients and developers on one hand, and consulting clients of mine whom I am helping to deal more effectively with outsourcing on the other hand.

As I was writing this, I was thinking I haven’t done much freewriting before. In fact I have, but I wasn’t aware of it. I have three or four notebooks filled with notes and diagrams, written at moments when I was contemplating my work. Amongst others, it is promoted in Becoming a technical leader by Gerald Weinberg, to set a few minutes apart every day to write about what you experienced that day. I did that for a few weeks in a notebook, but found it difficult to keep it up. On the other hand, I am writing about my experiences every day in e-mail messages to my friends and sometimes a blog-entry such as this one.

One of the reasons it may be hard to write regularly, is that writing is one of those things that is always important, never urgent. Freewriting may help to get started, as it takes only five minutes to begin.

Getting good at anything requires lots and lots of practice, and sometimes letting go of the critic inside you, so you can enjoy small successes and failures.