Stage Producer 101: Building the Best Stage Possible

in Agile, Scrum, and Musings - 0

So you want to be a stage producer for the Agile conference? Great! This post is meant to give you a primer not only on how to get started but also on how to build a wonderful experience for the attendees.

You should skip this job if…

  • You are doing it for the money. (As I explained in my first blog post, stage producers get at most $1,000 plus hotel and free conference admission.)
  • You don't have a lot of time. (I find I spend about 100 hours just to get to the point where I send the accept/reject letters. At that point I have another 60 - 100 hours to go.)
  • You are using it as a way to build your business. My advice, build your business on your own time.

Why do the job?

  • Because you enjoy the challenge. Running a stage is like running a project. You have to build a team of people you like to work with, and others that can work together. You have to motivate people through leadership and communicate with them frequently.
  • Because you get to meet other people in the community that you might not otherwise meet.
  • Because, most importantly, you get the opportunity to give something back to the community.

Stage producers have to meet certain date milestones and have a firm grasp on what will happen when.

  • August - November: Build your team.
  • November - March: Review and communicate to the team
  • March - April: Acceptance and reject emails go out
  • April - August: You will need to do small things to get your stage ready
  • August: As the conference nears, things ramp up again

Build Your Team

Setting up your team is a lot harder than you think. I start out by sending an email to 10-15 people that I think might be interested. I ask people that I have worked with in the past and new acquaintances that I think might enjoy being a part of the review team. In 2009 I asked people to review at least 20 sessions each. Doing it this way did not work because we received more submissions than we anticipated. In response, this year I gave people a percentage of submissions for which they would be responsible.

Reviews - Giving Them

Reviews are fun and quite challenging at the same time. When doing reviews, or having your team do reviews. Follow these guidelines:

  • Make sure there is a vision, a well structured outline, and clear learning objectives.
  • Give yourself ample time and do them without distractions. I like working in 45-minute blocks.
  • Provide actionable feedback.

Your review does not need to be a novel, but it should also not be one sentence (unless the submitter really nailed the submission and you're going to accept it).

Here are some examples of feedback that I used for Agile 2010:

"As other reviewers have said, there are a lot of things thrown about freely. On the surface this seems very good. In order to get accepted, however, it needs the sources to back up the claims."

"This feels like it has everything, which I view as a detriment. While attempting to cover a broad range, it feels like it lacks focus. Hone in on a specific set of items and drill them home."

Here is a piece of feedback I gave to a submitter (one of many) who submitted late and did not have a well-built submission.

"This submission lacks the detail necessary for serious consideration. If you are to run a 90-minute tutorial, you need to outline the timings in detail and expand on the exercises you will use. I have read the comments and feel that if you had submitted this before the deadline was approaching, it would have had at least one round of reviews and feedback with the review team, allowing you to adjust the submission. In its current form, I cannot advocate it for the conference this year."

I will always give a review over a comment as it allows me to get a picture of the program as it's being reviewed. I instruct team members to provide comments in the review and put in a recommendation (accept, maybe, reject) and use this data to manage the stage.

Reviews - Managing Them

The submission system, as built today, is not a very good tool for managing reviews. As a result, I use google docs to keep track of how the reviewers have rated individual submissions. I import the submission titles, ID numbers, and reviews and list them out like this:

The count is the number of team members that have reviewed the submission. Each reviewer gives each submission a numerical value of 2 for accept, 1 for maybe, and 0 for reject. These individual ratings are then averaged out. As you saw in the email, I like to have all reviewers review at least 75% of all submissions. This is to ensure that I get at least four, ideally five, reviews per submission. The conference committee only requires three; but I like to have more eyes look at the submissions.

Once the submission system closes, we go back one last time, review all of the stragglers and any updated comments from the review that we missed and solidify the plan. For our stage this year, this was done about five days after the submission system closed. A week later, we had a team conference call to discuss any submissions on the edge of accept/reject. We had about eight to discuss; two were promoted to accept. At this point the review team’s job is done.

Post Acceptance

As of today, 31 March 2010, we are in the accept/reject phase. Acceptance emails went out on the 30th of March and reject letters will go in a week or two. Why the delay? Because not all the people who were accepted will be able to go. We give people 7 to 10 days to confirm. If they don't, we move onto our backups. Once we’ve heard back from all of the submitters, the reject letters go out.

The Conference

Jim Newkirk, conference chair for Agile 2010, instituted some new rules that I think are wonderful. First, stage producers and assistants must open each session on their respective stages, introducing the talk and the speaker. They are not required to stay for the session, but they must collect the feedback at the end of each session and build a report in real time on how the stage is doing based on the scores for the sessions that were accepted. This report is given to the conference coordinator, Jessica, to build into a larger report. The chair will then write a larger conference report to submit to the board at the end. All of this is kicked off by the conference retrospective on Sunday, which all producers are required to attend.

In Closing

All in all, I find working on the conference very rewarding. Because I have done this for many years, I have worked out most of the process bugs for my stage. Every producers approach is a bit different, but in the end, we are all working towards a single goal - build the best conference program and experience we can.

Your takeaway : I encourage you to be a stage producer, but only if you are doing it for the right reasons and you have a firm grasp on the commitment you are making. Though the process isn’t perfect, every producer and every review team is working hard to create the best possible conference. If you have any suggestions on how we could do better, please send them to me. I’ll pass them along at our August retrospective.