technojunk.net

A colleague Rob discovered Google Coop - those clever folks at Google now let you create your own private search engine, restricted to search your own set of sites.

We created a search engine for our project, and loaded it up with all the Javadocs, HowTos, reference documentation and examples from all of the open-source libraries we use on a daily basis. It’s become a real time-saver, as you have exactly the right versions of all your framework and tool docs in one handy place, linked to off our project wiki. Nice!

Ivan Moore’s session on agile estimation and tracking had some interesting discussion centred around the idea of using real-day estimates for iteration planning in conjunction with ideal-day estimates for release planning.

For me, this is one of the areas of agile that needs simplification. I always have problems getting people to understand the difference between release planning, iteration planning, ideal days, velocity, story points, gummy bears….

I’d like to explore the idea of using real days a bit more. I think they have something going for them - people actually understand what they are!

Joshua Kerievsky’s Keynote was all about selling, namely selling the benefits of agile to large organisations. He made some interesting points, which I’ve captured here:

• Coaching can be repetitive and exhausing when you try to scale it up to multiple teams. There’s also issues with inconsistency and quality as different coaches issue different advice. As a solution to this Industrial Logic have started using eLearning on topics such as TDD, to help scale agile learning to large organisations. An interesting idea to get people started, although of course you can’t learn everything from a screencast!
• Metrics are a good way of answering objections to agile practices. Larry Putnam’s work has been at the forefront of this area for some time.
• Rather than selling the benefits of an agile practice, try selling the risks of not doing it.
• Try filiming the XP team at work and then showing it to the rest of the organisation to help dispel any myths and objections about XP.

In Lasse Koskela’s workshop entitled Resistance as a Resource, we played a game which explored the concept of effectively dealing with resistance. You need a group of people, four sets of coloured cards and some markers. The coloured cards each represent one of:

A move consists of taking an appropriate colour card and writing on it either a form of Change, a form of Resistance to that Change, a possible Reason for the Resistance or finally a possible Response to that Resistance. Moves can be played in any order by anyone. Here’s a picture of one of the areas we explored - Fixed Price Contracts:

So, what was this all about? As a consultant, you often come across resistance to new ways of working. For example, introducing Pair Programming is often met with resistance from managers who don’t understand why we are doing it. I sometimes find myself trotting out the same responses to this sort of resistance, without really thinking about it.

I thought the game was interesting because it made me focus on exactly what is the reason behind resistance, rather than making assumptions about it. I think you could adapt this game to get some interesting results in Retrospectives.

I had fun at XPDay this year. It felt less “extreme” than in previous years, as people seemed to focus on pragmatic advice and techniques rather than evangelism.

One of my favourite sessions was Dan and Joe’s Awesome Acceptance Testing. They identified 5 aspects to any acceptance testing regime:

• Automation - the tools and frameworks you use to automate bits of your application and tests
• Vocabulary - the ubiquitous language you try and create in your tests
• Syntax - how you express the vocabularly in a test
• Intent - what is the behaviour you are actually trying to test
• Harness - the tools and framework you use to run your tests and report on them

(Read on …)