Emily Bache has blogged about the new rules for Tech Demos at XP2012.
I like to give you some background why we came up with the rules.
BTW: These rules and recommendations apply to both tech demos and technical tutorials.
The presenter is not allowed to touch the keyboard.
A wild guess: You want to look good at the demo, right?
At another major conference a well-respected agile guy started off an onstage coder’s dojo as the first person at the keyboard. He had every intention to yield to the audience but got stuck on some startup issues. While he was struggling with the demo devil, no one narrated what was happening and kept the audience on track. Worse some people who were really interested in hiring the presenter entered the room and saw only someone struggling. It was a big loss both to the presenter, the audience and the presenter’s potential clients.
Hands-on technical sessions require a written well-prepared lab instruction
I was attending a paid technical tutorial a few years ago at XP20xx. The presenter had written articles and even a book on his topic. But he had not really prepared his highly technical hands-on tutorial with certain popular open source agile tools. Nothing was working even on his own machine. I was supposed to do the hands-on exercises with a Swedish guy with some university teaching background. He reflected that he would have been toast if he would ever attempt to run a lab exercise with students without a written well-prepared lab instruction. I think we can benefit from that best practice at XP2012 and other conferences.
At XP2011 we introduced a new kind of presentation – the tech demo. The idea was to give people 30 minutes to demonstrate a new tool or technique. For example, some people performed code katas in diverse languages, and others showed various productivity-boosting frameworks.
For XP2012 we want to continue with these kinds of demos, but with an additional rule. You can’t touch the keyboard yourself when you present. We want you to co-present with someone else, drawn from the audience, who will do the typing and demonstrate the tool or technique. Your job is to coach them into doing the demo you’ve planned, and to explain to everyone what’s going on.
Your co-presenter could be someone drawn from the audience who you’ve never met before. You’ll have to expertly coach them into demonstrating what you aim to show to the rest of the audience. If you choose this route, it will certainly be a big test of your skills of coaching and pedagogy.
Alternatively you can come to the conference and find a volunteer in advance of the presentation. You could make time for a practice run or two before the presentation. Again, you’ll be showing not only your tool or technique, but also how easy it is for a good programmer to learn.
If you’re thinking this sounds like an awfly scary way to do a demo, then you may be right. We think it’s also a very good way to have demos that engage the audience and really show off what you’re capable of.
If you know someone else who’ll be at the conference you could of course prepare the demo with them well in advance. You’d be able to work out exactly what pitfalls they will fall into, and have a slick commentary ready. Just having one person typing and the other talking is a great advantage in a demo, and this would probably still be good to watch. It might not be quite as challenging though 🙂
Will you accept the XP2012 Tech Demo challenge?