A field guide to attending the Agile conference (part 3)

Added to The Alliance

The conference is now less than a week away! Time to wrap up the "Field Guide to Agile" series, which was intended to help you navigate the various types of sessions on offer at the conference.

In Part 1 and Part 2 we explored some of the more straightforward session types. I've saved for last what many would consider the best - but also harder to categorize.
Import sessions are intended to bring in some new idea into the community, to be considered and possibly adopted as a new practice or organizing insight. (I struggle a little with that name - you're welcome to suggest a better one. The term is meant to evoke sociologist of science Peter Galison's "trading zones", where different disciplines exchange ideas.)
Historically, a great example of an imported idea is Retrospectives. It's my understanding that these were borrowed from Norm Kerth's practice around 2001 by way of a session at XP2001, and were eventually taken up with such great enthusiasm that they became a core part of Agile and particularly Scrum.
This didn't happen overnight - it took several years - and it's very hard to pick out, ahead of time, those conference sessions that introduce a new topic destined to such widespread adoption within the community. Various things might happen - the idea might be rejected, or ignored altogether (those two more or less amount to the same), or those promoting the idea may have enough momentum to form an all new community - this is more or less what happened with Kanban, which had a big year at the Agile conference in 2008 (in good part within the Breaking Acts stage, which I had the honor of chairing) but afterwards developed somewhat separately.
My pick for an Import session this year would probably be The Agile Cognitive Bias by Manoj Vadakkan and Bob Payne - I've been saying for a few years now that we need to pay a lot more attention to cognitive bias than has been the case so far, and I haven't been exactly alone in that - but this is the first that the topic has been addressed head-on, trying to get some useful advice from that research.
Slow Burn sessions might be a good name for those discussing ideas that have been around for a while but have yet to strike enough of a chord that they lead to experimental adoptions, or have yet to generate enough practical advice. Real Options, I'm looking at you here - hopefully this is going to be your year. But if it isn't, so what - it's not as if all of the software industry's problems risk being solved overnight and there is a race on to be the first to do that.
Finally, I can't close this without mentioning my favorite type of session.
Hallway conversations are the number one reason why so many of us choose to attend the conference in person, rather than relying on the increasing proportion of sessions being videotaped. Obviously, the videos can't bring you the hands-on, interactives or workshops experience - but the real reason why planning to "catch the conference on video" is bound to disappoint is the spontaneous conversation, nurtured by the high ambient density of ideas and enthusiasm of attendees for improving the profession.
(As far as Agile is concerned, "Hallway" is something of a misnomer - the organizing team is well aware of this and there will be plenty of quite comfortable space around the main rooms, such as the Open Jam space or the Agile Alliance Lounge, where you can sit down while enjoying these conversations; however, the hallways is often where they start.)
Many of next year's official sessions will be conceived there, and as someone who's always on the lookout for how the community's thinking evolves over time, I plan to spend a fair bit of my time in these impromptu sessions. So, if you happen to spot me in some hallway, please don't be shy - come up, introduce yourself, and tell me about your half-baked ideas.
See you next week in Nashville!

About the Author

No bio currently available.

This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.