Once again, “XpDay”:http://www.xpday.org went well. We sold out and, as far as I can tell, people had a fine time. Glaziers’ Hall isn’t quite as memorable a building as Ironmongers’, but we needed the extra space and they have a view of the river.
I missed a lot of sessions that looked interesting because I had things to do that clashed, but did manage to get to “Dealing with conflict”, run by Matt Bonetti and Dave Leigh-Fellows. They had some nice role play exercises for those occasions when you have to tell someone that you’ve just trashed the production database.
Both keynotes were excellent. Tim Lister, entertaining as always, explained his notion of projects where the Dead Fish of Failure is lying on the table from the first day, but no-one wants to admit it. He’s on a campaign to introduce realism into the software industry so we’re not always scraping by on near-impossible projects. After all, if no projects are ever delivered early then that means the estimation data are severely skewed. As Tim pointed out, it takes a martyr to be a great team mate on a projects that�s going down. He had some great images: a pilot project is not like building a ship, it’s like building a ship in a bottle; and software is Magnificent Gossamer (or should be). Tim stayed around for both days to talk and take part in sessions.
Bill Gaver (who I knew in my EuroPARC days) caused quite a stir. We’re developing a tradition of “off-the-wall” keynotes at XpDay to keep things lively. He showed some very enticing gadgets, such as the “Drift Table”:http://www.pols.co.uk/blog/archive/000113.html but they had a deeper point which is to get beyond work/recreation/consumption and address the playful side of people. If you’ve ever seen children play, you’ll know that it’s a serious business that helps us understand the world.
Bill’s point is to recognise that people are first-class participants in a system’s meaning, the designers can never really know how something will be used. Bill’s group are relaxing the designer’s hold on what things are _for_, or even what they _are_, which why they are designing objects that have no obvious meaning.
Although this seems obscure (though entertaining), this play is again serious business for us and, I think, a justification for Agile development. If we cannot truly know how a system will be used (ask anyone who works with Enterprise systems), then we’d better be adaptable: try a little, see what happens, adjust for the next cycle. (I’ve just noticed that this maps directly onto the “Cynefin”:http://www.cynefin.net approach to chaotic situations: Act, Sense, Respond. Time for another article.)