It’s about a month since I attended XP Day 2004. For personal reasons I was thinking of missing it, but I am very pleased that I went. It was very hard to decide which sessions to attend; at any time there was at least two sessions that I wanted to attend.

David Snowden
The Key Note speaker on the Thursday was David Snowden; he is an excellent speaker with many thought provoking ideas on organisations, people, complexity, chaos, and using narrative. I decided to sign up for his afternoon masterclass, which proved challenging – too challenging. Some quotes (from memory, so at best paraphrases):

• When a measure becomes a target, it ceases to be a good measure.
• Hospital Matrons were examples of Strange Attractors.
• If the Singapore Navy closed the Mahjong club, the Intelligence could no longer talk to Operations.
• Humans use first fit pattern matching to make decisions; not rational or even best fit pattern matching.

For more information see this article and the Cynefin website (currently under construction)..

Agile Deployment (John Birtley and Hubert Mathews)
They presented a quite brilliant (and with hindsight) bleeding obvious idea. Everone who hands over work to be deployed by others knows that it is nearly always a nightmare, and a pain to debug problems. Also it is impossible for development, or even staging, to match production environment.

The idea is to write automated tests for the environment. Test things like OS versions, Database versions, Java (if appropriate) versions, connectivity, database setup (tables, stored procs, population). I imagine that deployment problems not covered by the test suite will still occur, but these can be used to increase test coverage.

An Introduction to Goldratt’s Theory of Constraints (Clarke Ching)
Clarke gave quite a good introduction to TOC, which is essentially common sense (as opposed to common practice). Highlights were

• An amusing animation starring the construction worker from The Village People.
• An illustration of why multitasking is evil.
• An excellent analysis of The Waterfall as vicious circle (my interpretation) – the drivers behind adopting Waterfall and how this makes those problems worse.

Tom Glib
Tom Glib gave the keynote on the second day. His basic message was that anything can be quantified, and iterations should be geared towards improving a limited set of key measures. For example the goal might be to improve a system’s intuitiveness: the measure might be the number of times a new user needs to consult the manual. I couldn’t help but remember one of yesterday’s maxims – when a measure becomes a target, it ceases to be a good measure.

I was not convinced by the quantify everything idea; I suspect it would be too easy to choose the slightly wrong metric and end up optimising the wrong thing. I did think that Tom Glib had some useful ideas. At coffee I discovered that he was generally not liked; I believe there’s some sort of “history” with Tom Glib and XP.

Understanding The Roots of Agility (Joseph Pelrine)
“If you’re doing XP as described in the White Book, you’re not doing XP”. This was an open presentation on the principles behind agile practices. If you understand the reasons for a practice you can apply it to your situation; if you doing it just because it is written that you should do it, you’re less likely to gain the benefits.

There was much reference to the Stacey, Certainty \ Agreement graph, moving towards chaos and back. There was a nice metaphor of “red green refactor” being like breathing out towards chaos and then back in towards simplicity.

He also discussed facilitation of project retrospectives with brainstorming techniques for moving from simplicity to the “edge of chaos” and back again.

Practices make Perfect Pair Programming (Andy Marks, Jo Waines)
Introduced as “a title in search of a presentation” this session kicked off with a brief presentation on choosing the environment for Extreme Programming and the importance of the coach, then on to the pair programming competition. In pairs we raced to complete the maximum number of (fairly low level and unit-like) acceptance tests in the allotted time. It ended in a dead heat with most pairs completing two out of six tests.

We took an early lead, being the only pair to (on my insistence) to start with the naive solution. Ater two tests we tried to refactor and then unfortunately noticed some utility classes that had been “made earlier”: we got bogged down trying to figure out how to use the provided classes and trying to work out the ultimate purpose of the code.

Some interesting lessons:

• if we’d stuck with naive solutions we would have won; I’m not so sure that this has wider lesssons.
• it took much longer to try and figure out how the utility classes might help us, then it would have been to ignore them. This resonates with thoughts I’ve been having on “not invented here” not been an anti-pattern after all.

Around the World in 80 standups
It always feels good to hear success stories, so this was a great final session to attend. WDS have introduced “distributed” XP with three teams working on the same code base in relay. The team’s are located in Poole (UK), Seattle (USA) and Singapore: when one team finishes for the day, the next team takes over. Why bother? The problems are obvious, the advantages are

• each team is close to a set of customers. This was given as the primary reason.
• Every five days 15 days worth of increments are released. Having the same numbers work on the code at the same time would introduce different (and perhaps more intractable) issues.

WDS have put a lot of effort into making the distributed XP work, and they have had problems. Their key practices are

• the morning and evening video meetings (UK to USA, USA to Singapore, Singapore to UK).
• people swapping: at any time a number of developers on any team are “foreign”.

Joseph Pelrine quoted Kent Beck thoughts on doing things that cause problems frequently: releases are traditionally a problem so the XP (Agile) approach is to release frequently; testing is difficult so we do more of it. I wonder if WDS have “solved” the handover problem by handing their work over every 8 hours. I suspect it must have a positive impact on the simplicity and clarity of their code.