A typical for-profit conference costs $400 a day and takes you to a getaway vacation city like Las Vegas, Orlando or San Francisco. The staff creates the program months in advance; attendees can expect good food, snack breaks twice a day and plenty of PowerPoint presentations.
While that type of conference serves a purpose, those characteristics were not the things that drew me to BarCampGR (Grand Rapids, Mich.), Test Coach Camp (San Jose, Calif.) or Open Agile-Testing Pacific Northwest (Portland, Ore.). Instead, what drew me was the opposite—all three events are open-space conferences.
The History of the Open Conference Model
When Harrison Owen was organizing the third annual symposium on Organization Transformation in 1985, he reviewed the comments from previous events and noticed something odd. No matter how much effort the planners put into the program, people still found the most value in hallway conversations.
Owen wondered if would be possible to build a conference entirely out of hallway conversations. The result was something known today as Open Space Technologies.
Think of Open Space Technologies as a framework that lets a group of people create the event schedule in real time, focusing entirely on what the actual attendees want to hear, share and talk about—the problems they want to solve and the ideas they have to solve them. (In practice, there may be a board with schedules, a unifying thread and some managers on hand to decide who does what when.)
To really understand the open space format, you need to experience it, or at least have it described in practice. I went to the three different open space conferences listed above to capture the story.
BarCampGR: Session Suggestions on a (Virtual) Wall
BarCampGR was the broadest of the three events. Mobile application development was popular, with a double-length session called "Objective-C Eye For the .NET Guy" and a talk on developing native Android UI applications. There were also presentations on distributed version control, hacking GIS systems, decoupling team active record and about how "Real-Time Systems Keep You ALIVE!" In addition to hardcore technical topics, there were sessions on using a slow cooker to smoke ribs, publishing an ebook, learning macroeconomic theory and removing malware.
The great story of the conference wasn't the talks, though, but how it was organized. When I attended BarCampGR for the first time, in 2008, the schedule (Friday night to Saturday night) was built on a big board where people who wanted to present showed up and wrote in what they wanted to speak about. Organizers put up a new board every few hours, with three in all.
By 2012, the organizers had something better in mind. Prior to the event, they create a Reddit page for attendees to submit ideas. Anyone could browse the selection, vote ideas up or down or leave comments. This way, by the time the conference started, submitters know if a particular event will be popular enough to propose and will have feedback to make the talk better.
One highlight of the conference came from Calvin College Professor Patrick Bailey. He speaks about the science, technology, engineering and math professions, collectively called the STEM degrees. Bailey shows the difference between the new types of jobs that require STEM degrees and the number of students in the pipeline.
For computing through 2020, Bailey's research shows three-and-a-half times more computer science jobs created than CS graduates. While that might be good news for programmers, it suggests that employers need to develop hiring and retention strategies now or face pain later, he says.
Like many free conferences, BarCamp is hosted at a local college and sponsored by local employers. When Bailey speaks, I can't help but notice the large Atomic Object banner in the background. Then again, the conference has no entrance fee. I offer a toast to AO with my free soda while eating my free hot dog.
BarCampGR is literally a camp. Some people toast marshmallows late into the night and bring sleeping bags to crash on the floor. Since I have a warm bed 40 miles away, I head home.
Test Coach Camp: Learning to be a Good Example
My next open space event, while also called a camp, is held at a Holiday Inn on the Friday and Saturday before the annual conference for the Association for Software Testing.
Like BarCampGR, the program begins with an exercise to create a schedule. Here, though, we announce our sessions verbally, write them down and post them on the wall. We discuss which sessions have overlap, combine some and eliminate those with a lack of interest. After that, we build the schedule for the day by moving the sticky notes into a grid taped on the wall with duct tape by Matt Barcomb, who is the lead facilitator.
Where BarCampGR was local and eclectic, Test Coach Camp is international in attendees, but focused in vision. There are sessions on how to coach in difficult situations—dealing with people who don't want to be coached, people who don't want to test and so on—how to be a good role model, how to create games, puzzles and simulations that challenge the mind and, of course, how to play some games and learn from each other.
I sit in a session by Christin Wiedemann on being a good role model. Wiedemann offers to facilitate and takes notes on easel pad pages. The attendees throw out ideas: expressing appreciation for others creates a culture of appreciation, while keeping the work fun will tend to influence others to seek out fun and play. We write down that leaders must be careful about how they offer feedback, because other people will mirror that behavior.
The tester games session is a side-splitter. I show my old business card, which has a defect, and ask attendees to "find the bug." I let them ask reasonable questions. Like good testers, they jump into possible errors: "Is the phone number wrong? Do you really want it to say P: before phone, not H:?" and so on. Eventually, Wade Wachs points out that the color, which is different on both sides, could be perceived as a quality problem. The testing lesson is in the way testers engage—asking for requirements is a reasonable question.
At the end of the event, Barcomb runs a debrief in which people talk about their experiences and what they learned. Several people mention Paul Carvalho's Coaching game, which leads a small group through exercises to understand the perspective of people with different roles in the organization.
After Test Coach Camp, the 30-odd attendees go to the conference for the Association for Software Testing, where we create a one-hour presentation called "What I learned at Test Coach Camp." That talk is recorded and available on YouTube:
Agile Testing Open: Bridging the Communication Gap
The final event is Agile (Testing) Open Northwest (ATONW), organized by Diana Larsen, president of the Agile Alliance. Like Test Coach Camp, ATONW has a specific theme: Truly integrating the test process into agile software delivery.
The format of the sessions is similar to Test Coach Camp, too, with an easel and notes. Individuals propose sessions and, by proposing, also offer to host. At ATONW, hosting an event often means asking the audience questions, directing the flow and taking notes on an easel page.
Several sessions at ATONW dealt with the same issue: Regression testing for the current set of code to be deployed is a slow, painful process that can make a goal like "ship every week" seem impossible. Several sessions focus on test automation. Where most teams have programmers automating unit tests, nearly everyone present has human beings executing customer acceptance tests. A few people present have done successful test automation at the GUI level.
Michael Norton, a consultant at LeanDog, proposes a session titled "Help! My Automated Tests Are Out Of Control" Norton talks about the classic problems with large GUI automation test suites—how they are slow and brittle—and the group discusses how to break a complex test suite down into a reasonable selection of specific tests that do one thing at a time and do it well. I write down this idea—refactoring an aging test suite—to add to my list of tools.
Michelle Hochstetler, a QA engineer in Portland, proposes a session on bridging the communication gap between developers and QA. After a few minutes of reasonable, and expected, "us vs. them" comments, we talk about getting the groups together, including pairing roles in and out. That seems unrealistic, though, as many testers lack production code skills. Instead of insisting on production code, someone suggests pairing a developer with a tester to do a day's work, and vice versa.
At the closing session, Ben Simo, a tester from Phoenix, mentions that the best way to break down the barriers between development and QA is to literally break them down: Eliminate cubicles and physical space differences and even reorganize the groups if you have to.
Next Steps: Improve Regression Testing, Collaborate With New Friends
After attending three open space events (and taking notes), I am struck at just how emergent they are. In every conference, I found sessions that lined up directly with my interest. By the end of the events, I had a toolbox of ideas to help companies streamline the regression-test process, along with a half-dozen new friends to collaborate with.
Unconferences tend to be on a weekend, local and free (or at lease) very cheap. BarCampGR was entirely sponsor-supported, Test Coach Camp was grant-funded, and ATONW had a $75 entrance fee. This kind of price means that technical staff can attend local conferences without taking any time off, and use that time to pursue the exact idea they are struggling to solve.
Finding an open space conference can be as simple as searching Google for "barcamp (major city name)," "peer conference (topic)" or "open space (topic)." Once you find the right conference, getting your issues on the table is simply a matter of presenting the idea. Hosts do not need to present; they can take notes. This means there are no "bad" conference sessions; if the choices are poor, well, create a good one.
The best part is the quality of staff drawn to these events. It's people who care passionately about the topic. Beyond ideas for regression testing, doing this research I twice saw Michael Larsen, senior tester for Rovi and Association for Software Testing board member; ran a session with Jane Hein, director of product engineering at EthicsPoint, and met Ward Cunningham, the co-creator of extreme programming.
Thank you, Harrison Owen. Thank you very much.
Matthew Heusser is a consultant and writer based in West Michigan. You can follow Matt on Twitter @mheusser, contact him by email or visit the website of his company, Excelon Development. Follow everything from CIO.com on Twitter @CIOonline, on Facebook, and on Google +.