 |
| Source: http://www.deborahschultz.com/deblog/2006/07/the_law_of_two_.html |
Six weeks of
Open Space—it’s a new world record! I facilitated a six-week-long Open Space with my software development team. As far as we know, this is a unique experience: we are the only people in the world to have held an Open Space for such a long time. We pushed the limits of Open Space Technology, discovering for ourselves some of the things it is great at, as well as some of its limitations. Here are the highlights of what we learned.
A real problem
Our problem is the BigCo reorg. BigCo is shutting down an important BigProduct software dev team located in another country. Our team is less experienced and assists the other team. In two months, though, the other team won’t exist, and our team will be the BigProduct dev team. How do we become the BigProduct dev team, with full responsibility for the product’s success, in six weeks?
BigProduct has a large codebase. The software is much too complex for anyone to be able to design a curriculum and hold training courses in such a short amount of time. There is no way we could define the right set of generalized classes and specialist tracks, no way we could appoint the right people for the right speciailties, via central planning. Open Space Technology seemed like the best way to conduct our knowledge transfer and to become the BigProduct dev team. Our Open Space thrived for six weeks because we had a real, urgent problem to solve, and Open Space was the best way to address it.
Shared responsibility
The most important aspect of Open Space is shared responsibility. Everyone is equally responsible for the successful outcome. As a participant, there is no scapegoat to blame if you don’t achieve your Open Space goal. It’s not the curriculum designer’s fault if you didn’t learn the skills you need—you are the course designer. It’s not the visiting knowledge leaders’ fault if they didn’t teach the right skills the right way—you are responsible for creating the sessions and guiding the knowledge leaders. If you aren’t getting what you need from today’s sessions, it’s no one else’s fault. Use the
Law of Two Feet, and make sure you are always contributing or always learning. If you’d be better off sitting by yourself studying code, do it!
Authority
The Law of Two Feet grants you formal authority to do whatever it takes to achieve the goal. Everyone is explicitly authorized to make the Open Space successful. You set up the sessions you need, you make sure you get what you need from the sessions. If you don’t like it, you change it. You don’t have to ask. You don’t have to wait for permission. You are authorized.
Many short Open Spaces
We actually held a series of Open Spaces. We started with a one-day Open Space prelude, followed by six one-week long Open Spaces. The one-day prelude was a great warm-up, showing the team how Open Space works. The weekly Open Spaces were like weekly
sprints, giving us regular opportunities to inspect and adapt every week. At the beginning of each week, we established the curriculum for the rest of the week, based on which knowledge leaders were visiting, which topics we had already covered, what we needed to review, and what we need to learn fresh. The closing ceremony at the end of each week was a great way to review our progress and prepare for the following week.
Send an invitation
Every Friday afternoon, we told each other that the next opening ceremony would be on Monday morning. Every Monday morning, most of us forgot. People were doing the right things, studying and learning; they honestly forgot the weekly rhythm and Monday morning schedule. I learned to send a formal invitation to the opening and closing ceremonies every time.
Repeat yourself
As the facilitator, I thought it would be insulting to repeat the opening message and instructions every time—we had already done it, everyone heard it already, why should I waste their time with it? But when I skipped the ceremony, it was chaos! We lost focus on the problem, forgot to announce our sessions, and didn’t know which sessions had been planned.
The lesson is to always start at the beginning. Use the opening ceremony to inspire the team and transform the mood from “we’re hanging out, shooting the breeze,” to “we are starting something important right now—let’s pay attention to each other and make it work.” Establish the space, set the mood, reinforce the goal, and establish formal authority and mutual responsibility, every time. Explain the marketplace rules so the session ideas flow and people know what sessions to expect for the rest of the week.
Self doubt about achieving our goal
Did we learn everything we needed? Did we all become experts? Does everyone have broad knowledge of the system? Did the right people become specialists in the right topics? Are we ready to be the BigProduct dev team? Maybe we should have conducted a single weeklong Open Space, with the goal, “Establish the training program for the next five weeks, organize the trainers, and assign the students to the right training tracks”, followed by five weeks of programmed training.
Change it up
Inspecting and adapting, we noticed that we were doing too much learning by lecture, and not enough learning by doing. We ended most weeks with the advice that we should hold sessions that are in the style of a
code camp, but we started most weeks by setting up lecture sessions. During Week 5, we forced a week of code camps. Every session had to be a code camp, or you had to postpone your session until the next week. This worked, helping people practice their skills rather than listen to people talk about the skills.
Don’t do it alone
Conducting Open Space is too much work for the facilitator to do by himself. Get volunteers to help you set up the space, arrange the chairs, make the posters and tape them to the walls, order food, and do everything else you need help with. You not only spread the load, you share the responsibility. Every volunteer has a stake in the success of the Open Space, and they try harder to make it succeed.
Daily news, not daily stand-up
At the end of each day, everyone already knows what happened today: we organized and attended sessions. But what’s new? What changed since this morning? What is different about tomorrow’s schedule that we didn’t already know? Whose travel plans have changed? Where is the Fun Event session being held? Focus the new and important.
Easy to read session grid
We started with an informal sessions list, with one column on the wall for each day’s sessions. It wasn’t a true grid, with a row for each time slot. We skipped that detail, thinking it was unnecessary, but we were wrong. It wasn’t obvious which sessions were at what time during the day, and people got confused and frustrated. Gaffer’s tape to the rescue: we divided the columns into two rows, dividing the day into morning and afternoon sessions, and making it easier to show up at the right place at the right time.
Your experience?
What are your experiences with Open Space Technology? Have you conducted a short Open Space, a long one, or something in between? What did you learn about Open Space? What did you learn about your team and yourself?
For the last year, we’ve been experimenting with an open plan collaboration space. Instead of working as individuals in cubicles, we work together in a space with no walls between us. For the first six months, we loved it. Knowledge and learning were in the air, and they spread spontaneously amongst team members. Everyone knew what was going on without asking. Junior team members barely had to ask for help, and their skills increased dramatically. We coalesced as a very good team and wrote some very good software.
I awoke a few days ago with the inspiration for better space. We played Perfection Game together, and we arrived at this:
For the last year, we’ve been experimenting with an open plan collaboration space. Instead of working as individuals in cubicles, we work together in a space with no walls between us. For the first six months, we loved it. Knowledge and learning were in the air, and they spread spontaneously amongst team members. Everyone knew what was going on without asking. Junior team members barely had to ask for help, and their skills increased dramatically. We coalesced as a very good team and wrote some very good software.
