Since I wanted to change the layout, and it has gotten a bit annoying to do that by hand, I decided to create a simple script, called website2go that would enable me to continue creating the site as I have so far, with the added benefit of automatic page generation

So far, I've maintained my website as individual html pages, edited with a text editor. Some of the reasons for this, I've documented some of my experiences and wishes before. What it boils down to right now is:

• header, footle and page title of my site are to be automatically generated
• With the remainder of the page, I want to be able to have a flexible layout
• the remainder of the page contains mostly basic html, so I want to edit html directly
• I want links to other websites automatically generated from a list of favourite sites, like I do for my weblog
• as I'm automating stuff anyway, I'd like to add an RSS feed to the site as well
• a way to easily incorporate script-generated content
• the ability to easily undo changes
• being able to easily use existing tools such as text-editors, scripts, version control system and html validators
• The ability to easily add metadata as time goes by

Where it goes from there, I'll see. Some of my friends are having the same problems as I have, so this might evolve into a simple solution to maintain one person consultancy-firm websites. The system will depend heavily on other open source stuff like Ruby and Subversion, so if there is interest from others, I might open source it. I just noticed a blog entry by Martin Fowler, open source research that captures some of the spirit in which website2go is developed

a fair number of them are taking an idea and programming around it to see where it goes and whether it has value. That's a notion that sounds strange if you believe that design and programming are separated, but makes a lot of sense if you accept that they are tied together [....] A successful R&D isn't measured by what proportion of their ideas turn into products, but rather by how many great products they generate and how great they are. Someone who starts three projects and turns them all into mediocre products isn't as good as someone who starts a dozen projects and turns only one of them into a killer app.

I wrote the first screen of code today, and hope to keep notes on the development in the new category Nimble Programming.

syndicate Being Agile

syndicate Nimble Programming

Vera worded the values,goals and condition for this review much more succinctly than I can, so I'll reproduce her invitation to session organisers here (with her permission):

We value communication, feedback, simplicity and courage. As a workshop review committee, we want:

• an open and transparant review process
• useful and valuable feedback for the submitters
• a lot of input to create a great conference
• an atmosphere that encourages information exchange
• participation and involvement of a large community

That is why we decided to invite all workshop submitters to participate in the WorkshopReviewCommittee. Everyone who accepts this invitation, agrees with the following rules:

• You review at least 1 proposal, according to the WorkshopReviewProcess
• You can choose which proposals you wish to review, from those proposals that don't have 3 reviewers yet
• The review forms are filled in on the wiki, which is password protected and accessible by the WorkshopReviewCommittee only
• The reviews are not anonymous

As a session organiser, I'm very happy with this, and it seems to work out very well in practice, as most reviews have now been completed. The sessions I sent in have not been fully reviewed yet, but so far I've received some excellent and detailed feedback. Wether a session is well received or not, does not matter so much - detailed feedback helps to improve the session itself as wel as its' description.

Also, the lack of anonimity (which is the norm for other conferences, and even tracks within the same conference) balances out the fact that (as Marc Evers pointed out) a session organiser can skew the results in his favour by being extra harsh on other sessions. If you do that, the other reviewers / session organisers will be on to you quickly, and you'll only damage your own reputation. With anonymous review, this is somewhat easier to pull of (or so some people think. If there are comments, style is quite recognizable...).

As far as support software goes, non anonymous reviews make it possible to use a wiki for the review, instead of a more elaborate review support system.

In dutch we have the neutral word 'inzender' (the person who sends something 'in'). I haven't found an equally powerful word in english yet. So for now I'll stick to session organiser.

Of course, we could just add a new word to English, and start using insender ;-). Let's see if this meme spreads.

The clients have a sort of 'open space' attitude towards the development team: it's done when it's done

We agreed that this is not quite so bad as the development team felt about it. This gives the developers the space they need to do quality work.

"Why do the developers feel bad about this?", I wondered . Precise estimation is not a reason to feel good or bad (if so, it feels a bit like moralistic programming to me). Estimation accuracy is information about the project, nothing more, nothing less. Frustratingly enough, it is very hard to turn this information into useful action.

For this particular team, I learnt that the development team is getting some definite benefits from the estimating activity, besides the estimates themselves. What we came up in the heat of the moment was:

Value of estimation

• (when predictable) possibility to make promises on delivery dates
• signal of uncertain or unclear wishes, or lack of clarity on design modifications (when estimates are difficult to make, or are proven to be highly inaccurate)
• creates communication and shared knowledge - if programmers make different estimates for the same task, they have to explain how they got to their estimate. This creates shared understanding.

Cost of estimation

• several hours a week, spent on discussing estimates, as well as design.
• time spent on meta-estimation - discussing why estimation works or not

One of the striking things when the development team reflected on their estimates yesterday was, that they're quite capable of giving a rough estimate on a large, not yet well-defined task. Say, 'this is going to take two to three months'. And then discover that estimating for the next two days is extremely difficult. Perhaps the answer is in David's counter entry agile estimating:

An agile estimate should have a number of value units, a velocity, an end date and a buffer (or a measure of variation in velocity). That's it. You shouldn't be estimating anything individually. Fine grained individual estimates of effort are waste - muda! Just say "No!"

As a sort of 'training wheels' (detailed) estimation can be very useful. It helps a team become aware of all the work they are doing, makes the team aware of what they know, what they can know and what they don't (and sometimes can't ) know.

Trying estimation in a certain way has to be done consequently for a certain period of time - since the effects of estimation are mostly medium-term. After trying a set way of estimation, the team becomes more experienced, and is able to decide what they want to estimate, and how and why they do it.

Just saying no can be done in a responsible manner, once you've experienced several alternatives - varying from no estimation at all to too detailed estimation.

By the way, if you're having an argument on velocity in your XP team, and you have been doing stories for a while, I definitely recommend David's recommendation to take into account a measure of variation in velocity.

If you feel velocity is problematic, creating an information radiator for the velocity, and drawing an upper and lower variation band around it (say 5 or 10%) will show you if velocity means anything in the project, or something else is going on.

This was one of the first theory of constraints / lean - related things I took to my practice. The effect was ehm, interesting. I soon realized not everyone in and around the team wanted to see and/or hear that the variation was so large the velocity numbers didn't mean anything.

Watch for fingers being put in ears when you explain the variation bands in the graph....

Models indirectly modify my communication, because they help me make better sense of the world around me, so I can be more aware, fully present and (re)act more effectively. For me the most powerful in the past three years have been Systems Thinking and the Satir tools.

Recently Nynke Fokma, Marc Evers and I co-created a tutorial around three Satir tools (congruent action, the interaction model and the Satir change model ): Congruence in action

I find the idea of congruence especially powerful - actively balancing self, other and context.

It helps me to be hard, as in tough when it is right to do so. It is also hard, as in difficult, to master. With the people from agile systems we play blame games, making fun of our own incongruence, or be incongruent in another style dan the persons 'default incongruence style' - aka coping stance.

If you want to know more about coping stances, I recommend the book Congruent Action by Gerald Weinberg, or a trip to Agile Open, where we hope to run a trial version of the tutorial.

Playing the blame game probably only works with a small group of people you trust. As time goes by, practicing and playing games make it easier for me to recognize my own and others' coping stances, and adjust my reactions to that.

Communication skills can be anything but soft. As an example, communication skills can make it easier to see through other people's games and play 'hard ball' in a correct way. I like the comment written by Jason Yip:

I don't even like to say conversation, confrontation, collaboration skills are "non-technical". There are reliable techniques for these sort of things and "non-technical" seems to me a subtle suggestion that it's all magic.

Sometimes I learn these things quickly, others take more time to master, even though the idea is simple - changing my behaviour is not always easily done - that also makes communication skills 'hard skills'.