It’s odd how I’ve been unable to be very consistent in my subject-matter for this blog. I tend to hop around, going from very technical subject to very organisational ones. Some might see this as lacking focus. Maybe that’s true. I’ve never been able to separate execution from organisation and vision very well. To me they seem intrinsically linked. It’s comforting to me that even such luminaries as Kent Beck also seem to see things in this light.

I’ve been experimenting a bit with JavaScript. My lack of real knowledge of the language, apart from some simple DOM-manipulations, is starting to become embarrassing! So a couple of months ago I decided I should pick up the JS axe, and do some chopping. And the first step to guiding yourself into any new programming language is the selection of (or writing of…) the unit testing framework! My first choice was qunit.

My esteemed colleague, Ciarán ÓNéill just posted a nice and considered discussion on estimation, velocity and cycle time. I, however, do not plan on being so considered, or considerate. You see, too many people are bent under the crushing weight of living up to estimates. Even reckoning that they provided these estimates to begin with, the continuing focus on this fragile, incomplete, numerical slice of their work is having a seriously detrimental effect on our industry.

A while back I had a little fun comparing Agile to Rock’n’Roll. It’s still one of my favourite posts, and after my recent talk on the benefits of TDD, I got the idea that the best follow-up on that is something about the XP practices. Test Driven Development with Bonnie Riatt The first artist that came up was Bonnie Riatt. This is mostly because Ron Jeffries has mentioned her a few times on the Scrum Development mailing list, and since that picture above is from his site, I figure I owe it to him.

I recently wrote here about the benefits of failure. One of my recent failures reminded me about the importance of success. I thought that to be nicely circular enough to warrant a new post! You see, while it’s important to embrace failure - how else are you going to learn? - it is just as important that you don’t set yourself up for failure too often. One very popular way that agile teams do set themselves up for failure is by taking in too much work in a sprint.

Last Thursday, Januari 19, I gave a short talk at ArrowsGroup’s Agile Evangelists event in Amsterdam. Michiel de Vries was the other speaker, talking about the role of Trust in Agile adoptions. On my recommendation the organisers had changed the format of the evening to include two Open Space Technology sessions, right after each 20 minute talk, with the subject of the talk as its theme. This worked very well, and we had some lively discussions going on after both talks, with the 50 or so attendents talking in four or five groups.