Agile 2008: the end

The official programme of Agile 2008 conference just ended. With about 2000 attendees, 400 presenters and about thirty concurrent sessions running at any given time, this was by far the largest software development conference I ever attended.

Was it too big?

Trying to keep the conference spirit but still grow, the organisers decided to try out a multi-stage format with lots of parallel sessions split into some general themes. I was a bit overwhelmed and somewhat disappointed that I could not attend all the sessions that looked interesting, but I guess that is a nice problem to have. During his session, Henrik Kniberg asked the audience to vote on the “this conference is too big” issue, with most people raising red cards to signal that it was a real problem for them. In general, I think that the stage model worked relatively well, but I would probably prefer having only one session per stage next time. I decided early on not to attend any more workshops. Two workshops I have attended on the first day ended by participants only practicing their writing skills, without any recap or analysis on the end, leaving me with no feedback on what I have done good or what I should do better. Even worse, I might have missed something more interesting on a different stage. Presenters organising workshops should really leave more time to provide feedback for learning. One more thing that seemed to concern a lot of people is powering their laptops between sessions. It would be great if conference tables had power extension cords next year.

Here are the sessions that really caught my attention:

We are now officially mainstream

If anything, this conference has made me realise that agile is now definitely mainstream. As Ron Jeffries put it during his session on Natural laws of programming, “Agile is dead. Sixty million people are using it and it is no longer a revolution”. Henrik Kniberg said that one of the biggest mistakes with Scrum and XP was expecting that there is an installation CD for Agile. Ironically, just outside the doors of the conference room where he talked, there were dozens of companies bidding to sell that very CD to oblivious punters.

There was a surprising number of sessions on acceptance testing in various forms and under different names, which signals a shift of focus from programming practices to things that need to happen before the coding starts. Acceptance testing is gaining a lot of momentum, although I think that the current focus on tools is wrong and that people should be focusing more on the communication benefits and flushing out inconsistencies with realistic examples. It seems that the next big thing for agile practices will be emerging a coherent best practice for specifications and requirements out of all those seemingly different approaches. A thing that Ron Jeffries said about classic requirements during his session on Natural laws of programming really stuck with me — “the most important thing on a requirements document is the phone number of the person who wrote it”.

Snake oil and bureaucracy

Seeing so many agile project management products on offer at this conference scares me to death. Most booths in the hall were selling some sort of magical software that allows us to communicate through clicking and issue tracking and generates very nice graphs for project managers to misunderstand and misuse. I have still to be convinced in usefulness of any such tool, agile or otherwise. To me, this seems to completely miss the point and discourage personal communication.

Another thing that really bothered me was the emergence of preaching for a particular specific way to write things down which I noticed on few sessions. I attended quite a few sessions on acceptance testing and user stories and I’ve seen people advocate a particular format of writing user stories and bashing other formats, as if a format change would really make an important difference for the project. This reminds me of the famous curly brace discussions and similar coding format issues, that were always so pointless but wasted so much time. Ken Arnold’s legendary article asking for style wars to stop somehow always comes to my mind at these situations.

My personal perspective

On another note, I am very happy that I attended the conference. I met so many great people and put the faces on lots of e-mail addresses. There were quite a few interesting sessions and I heard a few new ideas and learned about enough interesting books to keep me reading until the next year. The conference was a great chance to present my new book in progress and the ideas for that book to a few people that I really respect and admire and the feedback was very encouraging, so I will now focus on completing it as soon as possible.

I was very glad to present with Marisa Seal in front of nearly a full room of people interested in database TDD. Judging from the comments and questions after the session, DbFit might be getting a few new users out of this.

One of the most interesting things for me was not actually a scheduled session, but a mini-discussion on FIT without inheritance that Mike Stockdale organised. This lead us to rethink the whole model of FIT a bit and digressed into FIT without fixtures, looking for ways to map acceptance tests directly to business domain services, repositories and objects. The idea is still half-baked but looks relatively promising. Expect a lot more writing on this idea soon on my blog.

I'm Gojko Adzic, author of Impact Mapping and Specification by Example. My latest book is Fifty Quick Ideas to Improve Your Tests. To learn about discounts on my books, conferences and workshops, sign up for Impact or follow me on Twitter. Join me at these conferences and workshops:

Specification by Example Workshops

How to get more value out of user stories

Impact Mapping

2 thoughts on “Agile 2008: the end

  1. Gojko,

    Thank you for inviting me to present with you. I was honored to do it. I hope that more people/organizations discover the benefits of DbFit by trying it themselves.

    Regarding: “I attended quite a few sessions on acceptance testing and user stories and I’ve seen people advocate a particular format of writing user stories and bashing other formats, as if a format change would really make an important difference for the project.”

    I actually attended the User Story Panel. While all panelists did mention the particular style/format that they typically use for user stories, all stressed that the user stories were a starting point for communication between the delivery team/business. I quite liked David Hussman’s comment (he was a panelist – and I’m paraphrasing) that the user story is a tool to get everyone talking about acceptance tests.

    Anyway, I do share your distaste for tool vendors/”experts”/whomever imposing imaginary process and formatting rules on Agile teams. I think this is why I enjoyed all of the Questioning Agile presentations so much…in my opinion, we cannot measure “how Agile” we are or run-down a checklist to see if our organization is indeed “Agile.”

    Thanks for your post.


  2. Pingback: Blog Xebia France - Revue de Presse Xebia

Leave a Reply

Your email address will not be published. Required fields are marked *