Last week I discussed two types of sessions that I think should be particularly useful to people relatively new to Agile, especially if attending the conference for the first time: Keynotes, which tend to “set the stage” for other sessions as well as for discussions with other attendees, and Education sessions (such as the ones offered in the Boot Camp track), which offer gentle introductions to basic concepts of Agile.
This week we move on, both to sessions that go beyond introductory content, and to sessions that are less obviously labeled in the program.
Experience sessions are useful to novices and experienced practitioners alike. They are relatively straightforward to spot on the program, as a separate track is dedicated to these sessions. (As with keynotes, many sessions not specifically called out as “experience reports” in the program nevertheless draw heavily on the speaker’s own experiences.)
Ostensibly the purpose of an experience report is to provide practical advice on how one or many Agile practices have been applied in a specific real-world context. The ideal format of an experience report goes more or less as follows:
- “This is our particular domain, the situation we started with, and some issues we faced, or objectives we sought;”
- “we decided to adopt these Agile practices to help with that;”
- “here is what worked well for us, and some challenges we met;”
- “here is the situation now, and what we think lies ahead.”
A deeper function served by experience reports is to reassure attendees: Agile ideas often seem weird at first, and to some people a major hurdle to adoption is simply the inability to picture the resulting context precisely enough. The disconnect between the world as they experience it, and what’s described in Agile literature, is simply too big to be bridged. Experience reports convey “this is what it’s like to live with this idea”, the day-to-day consequences, the compromises, the hurdles. One session which I suspect exemplifies this is “Refactoring as a Lifeline: Lessons Learned from Refactoring“.
Hands-on sessions are another type useful to practitioners as well as novices. These may be a little harder to look for, since they neither have a separate track, nor are clearly separated from other types of session of a more interactive nature; what the program calls a “Workshop”, as opposed to a “Talk”.
In a “hands-on” session, the intent is to help the attendees get first-hand experience with a technique; this is even more effective than the indirect, “second-hand” perspective of experience reports. If, say, your curiosity was piqued by the experience report on refactoring, then you’d definitely pick “LEGO TDD and Refactoring“ too.
(By contrast, “Practical Refactoring“ may be well worth attending, but it’s clear from the session description that it’s more of a demonstration: you will pick up some insights, but not direct experience of how it feels like when you are refactoring.)
Important keywords to look for in a hands-on session are “work”, “practice” or “exercise”. Be aware that there are other types of sessions also called “Workshop”, which fulfill different purposes: for instance, debate sessions that serve as a venue for expert practitioners to refine or advance Agile concepts or techniques not yet fully worked out, or reflection workshops where attendees exchange points of view for deeper understanding.
Stay tuned for further picks illustrating more kinds of sessions at Agile.
About the Author
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.