When Chet Hendrickson and Ann Anderson contacted me in 2002 to facilitate an Open Space track of a conference they were calling the Agile/XP Universe, I didn’t know anything about Agile software development. As they explained it to me, I think I said right out loud, “Holy cow! You’re making software in Open Space!” This was exciting because facilitating Open Space, and training others to do that, had already become a personal passion and professional specialty for me.
As I’ve worked my way around, and finally into, the Agile community, my first sense that Agile and Open Space are essentially the same has grown deeper. On the surface, they might appear otherwise. Most of the words and actions sound different. But much of what makes them work – the most important intentions, worldviews, practices and results – are remarkably well aligned.
Where to Start?
Open Space was discovered (rather than invented or designed) by Harrison Owen in 1985. He’d organized a conference on Organization Transformationation and the best parts of it turned out to be the coffee breaks, which he couldn’t actually take credit for. So when friends pushed him to do it again, he wondered how to make it less work and more value: more coffee breaks. He took his question to the bar and found Open Space at the bottom of the second martini. He went home, wrote an invitation, scheduled a place to meet, and let self-organization manage the rest.
Agile became a “thing” in 2001, with the crafting of the Agile Manifesto, by seventeen guys who gathered at a Utah ski resort to have some fun and figure out a better story than “lightweight methods” for the software development practices they’d been refining and sharing for some years.
Values, Methods and Practice
The spark for Open Space was Harrison’s realization that he did not and could not know what most needed to be on the conference agenda to best support the organization transformation activities and aspirations of his attendees. In the same way, the signatories of the Agile Manifesto had come to realize that it was impossible to discover everything, or even enough, about a software product or project before they started building it.
The Manifesto offered four of what the signatories called core values. While they valued all of these things, they valued the things on the left ‘’more.’’
These values, and Agile methods like Scrum, are well reflected in what happens in Open Space practice.
In planning an Open Space, we usually think about four main preparations: the invitation (states the purpose), the invitation list (names who needs to get it), the space/time logistical issues (place, time, food, materials), and a rough description and plan for capturing the results (notes, photos, video, or whatever else needs to be produced).
In Scrum, we create a product vision (purpose), gather all the stakeholders (or what some are now calling “product partners” because they all need to work together to get the product built), they arrange to be co-located in a team room, and describe the result in high-level budget, timeline, roadmap, and backlog stories.
The invitation to gather in Open Space is a tiny bit of (working) story, just enough to get the group together. It’s not a comprehensive agenda. We start in a big open circle, have a short briefing, and then participant collaboration generates an agenda that perfectly fits their needs. In creating the agenda, participants are reminded, “You don’t have to bring the (comprehensive) answers, it’s enough to bring the (working) questions.”
All participants are invited to post the issues and opportunities they see as essential to address the purpose of the meeting. The topics all go up on the wall of the meeting room, each one scheduled for a specific time and corner of the room, and the participants set to work completing each one, working in short iterative rounds of breakout sessions. New items are added to the agenda along the way, as the group learns its way into the work.
In the same way, when a Scrum project starts, all the product partners work together to create a product backlog of user stories, detailing the features to be delivered. These are prioritized and scheduled into (typically) two-week sprints, with each sprint’s work posted with sticky notes on a wall. New items are added to the product backlog as the work progresses.
While the Open Space facilitator usually specifies a very few process points, like the timing of breakout sessions, the Four Principles remind everyone that “whoever comes is the right people, whenever it starts is the right time, whatever happens is the only thing that could have and when it’s over, it’s over.” An invitation to focus on people and conversations rather than rules and process. Since there is almost nothing of a plan to follow, the facilitator’s main job is to keep responding to changes.
The closest thing to a process rule might be the Law of Two Feet, but that is more akin to the Law of Gravity (defy it at your own risk!) than a speed limit sort of rule. It says, “You and only you know when you’re learning and contributing as much as you can.” It gives all participants both the right and the responsibility to use their two feet to move around between groups, go wherever they need to, in order to maximize their own learning and contribution. In this way, the people drive the process, not the other way around.
In Open Space we have Morning and Evening News, a brief time for the whole group to get together and notice what’s happened, how they’re doing, raise new issues, and handle any problems that might have arisen. Scrum teams have daily stand-up meetings to share what they’ve done, what is next, what they’ve learned, and anything that might be blocking them.
At the end of an open space there is a reflective closing circle. At the end of every sprint, the Scrum team has a Review meeting with business and/or customer partners, and a Retrospective learning session as a developer team.
And then we do it all again, because it’s practice.
Conditions, Mechanisms and Tensions
Open Space works best when four conditions are present: Passion (even to the point of conflict), Complexity (in terms of the challenges to be met), Urgency (we need the solution yesterday), and Diversity (in terms of the skills, interests, needs, and/or solutions required). These conditions show up everywhere in software development.
We talk about Open Space running on four basic mechanisms: Circle, Bulletin Board, Marketplace (room to move), and Breathing (sometimes called Pulsation or Iteration). These mechanisms are all clearly activated in Agile practice. Teams are formed, everything is visualized on the walls with stickies and whiteboards, teams learn their way into self-manage and personal autonomy, and work in regular sprint iterations.
Underlying both of these ways of working are some basic tensions. Passion and Responsibility, we need to be responsibility for whatever issues we care about. Autonomy and Transparency, we trade high levels of freedom for equally high levels of exposure and accountability. And Learning and Contributing: we are charged with delivering results but also for getting better at delivering better results, so we are giving and receiving all the time. Self and Whole. Inner and Outer. Doing and Being.
The result is a sort of a flow in the work, a flow state in the people, but we recognize them as tensions, too. They’re hard work to manage, as participants and practitioners. So the most basic view and assumption and mechanism of all is invitation – voluntary self-selection and the realization that people do their best work when they have some choice and control.
Over and over again, organizations find that assigning people to Agile teams and directing them to follow a whole new set or procedures, to be adopted immediately and without question simply does not work. Invitation, on the other hand, has been shown through 30 years of Open Space practice, all around the world, has shown to be a powerful, engaging, story and practice.
The suffering that comes from the specialization and isolation of people and functions. The reality of uncertainty, complexity and ambiguity. The practical limitations of command and control. The defects, waste, missed deadlines, and budget disasters that result. Agile and Open Space take these things as givens, and offer ways to do our best work in spite of all of them. Agile and Open Space work because they invite people and organizations to care for the whole, to share clearer vision, to learn faster by doing, and to deliver more valuable results with greater ease. People want to respond to those invitations.
A few years ago Harrison Owen suggested a fifth principle: Wherever it happens is the right place. Last year we demonstrated that by organizing the first ever virtual Open Space on Open Space, an online version of the decades-old practitioner gathering. At that event, I met Mark Kilby, an Agile Coach who remembered me from the 2002 AgileXP/Universe? conference, where he’d learned about Open Space. This year, Mark asked me to co-facilitate his Audacious Salon session at Agile2016, on Distributed Agile Teamwork, to challenge the Agile community’s understanding of co-located teams.
More and more these evolving practices are crossing paths. That first 2002 Open Space track has become the Open Jam session at Agile20xx conferences and Agile Open series of regional practitioner gatherings in Open Space. But Open Space isn’t just for conferences, anymore. Daniel Mezick has developed OpenSpace Agility for Agile adoption. Dr. Sandra Walsh has shown the effectiveness of marrying Open Space and XP engineering practices, which I’ve generalized and adapted into something I’ve tentatively called SMARTer Agile. Ron Quartel has outlined the FAST Agile scaling approach based on Open Space. Tim Ottinger tells me he and his colleagues are running large chunks of Agile training work in Open Space. All of this, of course, only scratches the surface of what’s actually happening out there.
Back in 1998, Ken Wilber’s Integral “theory of everything” jolted me into an examination of my experience in Open Space, my teambuilding work with Outward Bound, and my wide-ranging study and practice of organization development. I translated everything I understood about organization into his framework. Now I see Michael Spayd, Michael Hamman, Lyssa Adkins leading Integral Agile training (with the book forthcoming) and Johannes Schartau blogging at Integral-Agile.com.
My Integral work led me to discover what I have called the Inviting Organization, emerging in Open Space. My personal response to 9/11 was to go (literally) around the world teaching Open Space as a “practice in invitation.” I’ve used the framework to make sense of what I see happening in client organization and as a guide in the shaping of invitations to Open Space meetings and events. It informed our design of the Distributed Agile Teamwork at Agile 2016. And I recognized this old stories at work in Josh Kerievsky’s Modern Agile keynote there.
This is Inviting Agility. It’s the distillation of everyting I’ve done and learned in Open Space. It’s the discovery of the Inviting Organization and how it works in practice. It’s the Integral map I’ve used and refined over the years and how I’m using it to understand how to do and be Agile today. It’s a new way to understand and implement Agile throughout the enterprise.
And, for the moment, it’s a loose collection of writings, old and new. Maybe, even in this rough form, you’ll be able to learn your way into this way of seeing and working with the whole of any situation. This is what we need to get whole solutions to complex problems. It might seem like a bit of a tangle at first, but the more you work with this story, the simpler and more useful it will get.
Please send your comments and questions. Help me make it a better story!