Facilitation:SpeedGeeking

From Facilitation Wiki
Revision as of 20:29, 12 January 2016 by Miriam (talk | contribs) (→‎Learning objectives)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Overview

SpeedGeeking first saw the light of day at the AdvocacyDev I SpeedGeeking Session.

A tongue-in-cheek rip off of the speed dating concept, SpeedGeeking offers a fully immersive, invigorating and hilarious approach to meeting people ... and learning about the cool projects, software tools and crazy ideas that they have been working on. At a SpeedGeek, one group of participants sets up at stations around a room to give 5 minute presentations while the rest of the group migrates in a circle around the room to hear these high-speed raps. The result is an obscene amount of fun, all tied up with a good dose of learning about how technology is being used for social change.

Learning objectives

At the end of a SpeedGeeking session participants will:

  • See and touch some of the world's best activist websites and tools
  • Watch social change and technology converge before their very eyes
  • Laugh. Giggle. Smile. Catch breath. Repeat.

What do SpeedGeekers need to do?

All participants are encouraged to present at the SpeedGeek. If you are interested in presenting your site, software or idea at the SpeedGeek, you need to:

  • Sign up on the sheet provided by the organizers
  • Prepare a five-minute demo or pitch. This is not a lot of time, so make sure your presentation is tight and informative.
    • Visual aids are good: a few slides or screen captures (safer) or a live web demo (risky in terms of connectivity).
    • You can expect to make at most four (4) major points. Suggested talking points include:
      • 1) Why should listeners care about your TYPE of technology or project? How does it benefit the listener?
      • 2) Why should listeners care about your PARTICULAR technology or project?
      • 3) What distinguishes you from other offerings or models, from the user's perspective?
      • 4) High-level demo of the product. Screen shots are often excellent and adequate. Deep technical demos are probably too much.
  • Be ready to answer questions and enter into discussion for one minute.
  • Be loud and be lively.

Facilitation Process

One person needs to serve as Facilitator (aka "Manager of Mayhem"), tracking the 5 minute periods and blowing a whistle or ringing a bell to rotate listeners to the next station.

The facilitator takes the following steps:

  • Identify how many demos will run in parallel. 10 or so demos (50-60 minutes) is a practical limit; participant brain overload usually occurs with higher numbers, as does SpeedGeeker vocal cord stress.
  • Place the SpeedGeek presenters at stations around the room so that those viewing the demos can move in something resembling a circular path as they go from station to station.
    • Number the SpeekGeek stations from 1 to N, for use in assigning groups later
    • The larger the room, the better, as things get loud and space allows folks to reduce their yelling
  • Take the number of people who will be viewing the demos and divide into small groups, one group for each demo station.
    • For 30 people to see 10 stations, you would create 10 groups of 3 people.
      • For N stations, have participants count off in cycles 1..N, 1..N
    • Assign each small group to an initial demo station
      • Send group #X to table #X, etc.
      • This has nice randomizing effect on groups as well
    • The groups should as small as possible. Higher group sizes should be addressed by encouraging more folks to demo something; it's fine for folks to demo things they use and/or like as well as develop and/or support.
  • Make sure everyone understands the process
  • Blow the whistle / ring the bell to start the demo
  • Track time. Shout out a "1 minute warning" after 4 minutes, and then count down the final 10 seconds loudly, as if you were narrating a rocket launch.
  • When the 5 minutes are up, blow the whistle / ring the bell and actively force participants to move to the next station. Interrupt conversations, move folks along, get the next set of demos started
  • Lather, rinse, repeat until each small group has viewed each demo station

One drawback to this facilitation model is that those doing the demos don't get to see each other's demos. Multiple rounds of SpeedGeeking can partially mitigate this, but it remains an unsolved problem in the model described above.

One other drawback is that this model is relatively speaking a uni-directional approach: speed-geekers spend a lot of time talking, but very little time receiving feedback.

Future experiments in speed-geeking with smaller groups might allow for RapidFeedback, in which a bi-directional exchange is created. Just like in speed-dating, the geekers speaks first while the participants listen. After the first five minutes, the tables are turned, and the participants give their immediate feedback to the speed-geeker, in possibly another 5 minute interval. Obviously you'd need fewer geekers to get this done, but it might add a lot of value to projects looking for big-picture ideas from users.

Speedgeeking goes Europe

Where else to test the limits of speedgeeking than during a 2,500 person outdoor hacker event? Probably the first appearance outside North America, and perhaps the 'world record': 13 parallel presentations at What The Hack in The Netherlands, July 2005 (reported here)

Please add your comments and suggestions to this process!

Plone Community Innovates

The Plone community appears to be exploring the cutting edge of speed "geekery" ;-)

http://blogs.onenw.org/jon/archives/2007/03/19/pinitifcation-a-new-speed-geeking-technique/

Best, Jon Stahl, Program Manager