Using an Open Space to Teach and Get Results

The organization I’m currently working with is suffering from ‘we have no time’ disorder.  Demand is exceeding capability which is leaving little time for ‘non-contextual’ learning for the lack of a better phrase.

While one team has been making some great strides with root cause analysis, they have been struggling to turn those learnings into actions simply due to the volume of work that needs to get done.  In addition to ‘we have no time‘ disorder, they have also been diagnosed with ‘we have to‘ syndrome.  A dangerous combination of diseases indeed.

Enter Open Space.

Now that this particular team has gathered a bunch of data that narrows the focus of what parts of the application are causing the most problems, (amongst other organizational causes that are out of scope here), I’m planning on conducting an Open Space to gather the more subjective data as well.

So why an Open Space as opposed to a typical brainstorm session?

I see this as an opportunity to teach within context which will help the team with:

– self-organization skills (facilitation, time-boxes, collaboration)
– spreading domain and application knowledge amongst the team
– gaining perspective from multiple disciplines (QA/DEV/Business)
– giving everyone on the team the opportunity to speak up (team has some dominant personality issues)
– developing a framework for problem solving and brainstorming so they can be as effective as possible with future meetings
– having fun! get folks together and excited about their work!

These are the mechanics I’m planning on using, as I think some tweaking is necessary to get this to work in context:

  1. Setup the open space concept: give team members a few days to digest how an open space works and why we are trying this approach.  This will be wrapped in the business goal for this session (gain consensus on the part of the application that will become the focus for this quarterly initiative.)
  2. Open Space Intro: 10 minutes – re-state how an Open Space works and state the business goal of the session.
  3. Lightning Talks: 30 minutes – each team member will be allocated 2 minutes to present what they want to talk about.  Ideally we will post this in the wiki ahead of time and I suspect folks will pair up.
  4. The Twist!: 1 – 2 hours – Here’s where it gets risky.  Now it’s ideal for all team members to be part of each talk since there will be actual work derived from the output of this session.  Depending on the number of ‘sessions’ that are created, as a team, we may agree to do “X” number of sessions and everyone will participate or we will vote on what 2 sessions to do.  I suspect based on the hard data gathered there will only be 2 – 3 major functional parts of the application chosen by the team.  The backup plan is to use the hard data in conjunction with voting, fist of five or other consensus techniques to decide what topic(s) to drill down on.  The sessions themselves will functional much like a typical brainstorming session.
  5. Retrospective: 15 minutes.  For me to see how effective this was as a coach and for the team to see if there are techniques they can use going forward to have more effective meetings.

I’ll follow-up this post after the session has been held, but would love to hear your thoughts and suggestions!