Blog Posts:

Is Pushing Practices on Teams Agile?

This question comes up more and more: Is pushing practices on teams aligned with Agile values and principles? The answer may surprise you…let’s take a look.

Specifically: How does the OpenSpace Agility approach differ from the typical style of forcing practices on teams?

It comes down to “open space,” where conversation and connection is valued, versus “closed space,” where conformity and compliance is valued:

  • Fundamentally, OpenSpace Agility (OSA) creates an “open space” where everyone affected by the “Agile transformation” gets an opportunity to express what they think and feel, about how it is going.
    • In OSA, the emphasis is on cycles of experimentation, and inspection of the change process itself, at the level of enterprise or “the whole group.”
    • The result is very high levels of self-management across the enterprise. This is why OSA works.
  • Meanwhile, the typical “Agile transformation” creates a “closed space” where where everyone affected by the “Agile transformation” gets an opportunity to “be obedient” and “be told what to do.”
    • In the typical “Agile transformation,” the emphasis is on a “push” of practices upon teams, usually by entirely well-meaning yet fundamentally misguided executives.
    • The result, sadly,  is very high levels of disengagement and even active resentment across the enterprise. This is why typical “Agile transformations” fail, and do not actually “transform” anything at all.


You can learn more about OpenSpace Agility here:
The following is a compare-and-contrast of the OSA approach, and the typical, commonly accepted and commonly implemented assess/train/coach “Agile transformation” approach. The intent of presenting this data is to establish the fact that OSA is 100% aligned with Agile principles, while the typical assess/train/coach “Agile transformations” is clearly not aligned with Agile principles in any coherent way.


Well-established Agile Pattern Does the “pull”-based OSA Approach Support This This Aspect of Agile? Does the typical “push”-based approach Support This Aspect of Agile?
Build projects (and products) around “motivated individuals.” YES. In pull-based approaches such as OSA, we identify willing people and work with them, training and coaching the teams that explicitly opt-in to this style of work NO. Typical assess/train/coach “Agile transformations” do not make any distinction between willing and unwilling teams. This is the same as disregarding the Agile Manifesto.
Iteration YES. OSA’s enterprise-wide iterations are called “Chapters” and are 45 to 100 days, and punctuated by a whole-group meeting in the Open Space format. NO. The basic process is waterfall: assess, then train, then coach. And this is “until further notice,” with no whole-group iterative inspection event focused on inspecting the *process* of changing.
Experimentation YES. This is core of pull-based approaches and OSA. During a 45 to 100 day enterprise-wide iteration, teams conduct experiments with practices that align with the Agile Manifesto. They then inspect the experience with these practices using a whole-group meeting event. NO. Typical assess/train/coach “Agile transformations” typically follow a strict framework-based sequence, and the practices in the framework are forced on the teams who are affected. Teams are not encouraged to experiment with practices. Instead they are told to follow a procedure mandated by executives and implemented by the Agile “coaches” who serve these executives.
Inspection/Retrospective YES. Every iteration in pull-based OSA starts and ends with an whole-group, enterprise-wide  meeting in the “everyone is invited” Open Space format. The actual process of changing is inspected, by everyone affected, to make sure the change is actually serving the organization’s wider business objectives and the people who make it happen. NO. Retrospectives are usually at the team level, usually never the “whole group, everyone invited” enterprise level. In those very rare cases where the whole group engages together in retrospective, the focus is always on the projects and products rather than an inspection of the process of changing. And if they do inspect the change-process, it is only the short list of “higher ups” who are quietly invited to attend a closed-door meeting. Typical assess/train/coach “Agile transformations” never engage in whole-group inspection of the change-process itself.
Adaptation YES. Within the constraints created by the Agile Manifesto’s 12 principles (or better,) the entire enterprise engages in adaptive behaviors. Pull-based approaches like OSA encourages enterprise-level adaptive behavior. NO. Typical assess/train/coach “Agile transformations” do not inspect the process of changing with the whole group, so there is no adaptation-in-fact. Instead, there is usually a forcing of practices on teams, with no whole-group discussion of how well those mandated practices are actually working.
 Organizational Learning YES. The pull-based approach generates organizational learning by inviting everyone into a periodic, iterative, whole-group, consent-based process that encourages everyone to participate and contribute to the inspect-and-adapt process.  These whole-group meetings are important “signal events” that trigger and leverage whole-group collective intelligence, which is the true heart of Agile NO. Typical push-based assess/train/coach “Agile transformations” never engage in whole-group inspection of the change-process itself. It’s compliance over consent, imposition over invitation, and mandate over mutual respect. Organizations cannot learn in the “closed space” created by these design elements.
Self-Management YES. Pull-based approaches in general (and OSA in particular) encourages self-management by encouraging executives to encourage teams to make decisions that directly pertain to the team’s work. NO. Typical push-based assess/train/coach “Agile transformations” make decisions for teams, and typically without their consent. This lack of consent encourages disengagement (and even resentment) instead of engaged self-management.
Self-Organizing Teams YES. Teams are provides with enough decision-making authority to manifest genuine self-organization. NO. Self-organizing teams get that way by choosing who has influence over decision-making. In typical push-based assess/train/coach “Agile transformations,” teams do not make decisions that affect them. Instead, an external “authority” tells them what they “should” do. This is in complete conflict with the Agile Manifesto.
Give them the environment and support they need YES. In OSA, execs authorize teams to make decisions that pertain to their work and work process. OSA encourages the harvesting of whole-group collective intelligence. NO. Typical assess/train/coach “Agile transformations” assume that “executive buy in” is all that is necessary for success. This is the same as completely ignoring the Agile Manifesto. (In truth, *everyone* affected must agree to at least “suspend disbelief” if the Agile initiative is to succeed.)
Trust them to get the job done YES. In OSA, execs learn to signal support for iterative work, inspection, adaptation, and team-level decision making with intent to foster and manifest self-managed teams. In OSA execs learn to trust teams to do the right thing. NO. In typical assess/train/coach “Agile transformations,” teams are not trusted; instead the practices are trusted, and assumed to be sufficient, regardless of what teams think about these practices. This is the same as completely disregarding the Agile Manifesto.
Individuals and Interactions YES. OSA punctuates enterprise iterations of change with whole-group Open Space events. These events are focused on people and communication, that is: individuals and interactions. NO. Typical Typical assess/train/coach “Agile transformations” focus on practices and processes and tools. There is typically no whole-group participatory process. Instead there is trust and emphasis placed on proper processes, tools and practices. Once again, this is the same as completely disregarding the Agile Manifesto.
Respect for People (a core pillar of Lean) YES. In OSA, practices are not imposed on teams. Instead, team members are invited into an Open Space event to discuss Agile Manifesto principles and do experiments that use these principles as guidance. NO. Imposing practices on teams not only KILLS any potential for “self organizing teams,” it is fundamentally DISRESPECTFUL of people.
Continuous Improvement (a core pillar of Lean) YES. OSA represents genuine PROGRESS and gets better results compared to to the failed status-quo of imposition. NO. The process of introducing Agile into organizations has not changed in over 15 years. Forcing training and practices on the whole organization does not produce transformations and if it did, we would be celebrating literally *thousands* of verifyable success stories worldwide. This is obviously NOT happening, Agile adoptions routinely FAIL worldwide and the Agile Industry is completely silent about it. The alarmingly high rate of FAILS is the biggest issue facing the Agile Industry today and the “thought leadership” is either not thinking, not leading, or both.



You can learn more about OpenSpace Agility here:

Are OpenSpace Agility People Pushing The Idea of Pull?

Some folks say that OSA practitioners are using “push” to encourage “pull.”

They say that OSA people are doing the very same thing they are trying to eliminate, namely the forcing of something on people without their consent.

They say OSA people are “pushing pull.”

But wait: is that really true?

Push” is defined here as when you are able to successfully force someone to do something when it is difficult or impossible for them to opt out. This is the common “best practice” in the world of so-called “Agile transformation.” Agile practices are pushed on teams who had no part in the decision-making process. To opt out, they must quit the job. Nearly every large-scale “corporate” adoption of Agile imposes Agile practices on teams without asking them what they think about it. That’s push.

And then, in theory, “Agile transformation magic happens here.” Except it doesn’t.

Pull” here is defined as a request something, for example “pulling” more work into a workflow, from a queue. Like Kanban. And like Scrum, during the Sprint Planning meeting, where the Team “pulls” as much into the Sprint as they think they can complete.

Pull” as applied to OSA is when executives invite employee participation, to “go somewhere” or “do something,” and that invite results in a YES. That’s Pull. It’s the opposite of Push.

So here is the difference: if you do not like OSA, and someone is “pushing” it constantly on Twitter (for example,) you have options.

You have ‘outs.’ You can opt OUT. You can Unfollow. Unfriend. You can even Block.

The key difference is that you have options… and employees don’t. Employees have few if any “outs” where Agile is concerned, unless they quit.

They have no outs except to quit: and quitting one job and finding another a serious undertaking if there ever was one. Finding and starting a new job  is stressful. And risky. And time-consuming.

See the difference?

In the Twitter situation, you can opt-out. You can stop listening. Stop Following. You can even Block.

In the at-work “Agile transformation” situation, the employee has no outs. No options. Nothing.

Except to QUIT.

This means pushing practices like Scrum on teams is fundamentally lacking in respect for people. Because they have no “outs.”

So, please stop pretending that spreading an idea like OSA, to a public  audience with options— with ‘outs‘– is the same as executives pushing Agile practices on employees without their consent.

This not at all an apples-to-apples compare. Not even close!

And it is actually very misleading (dare I say deceptive and manipulative?) to say that it is.

Because clearly, it’s not.

So, please stop it. Because while it sounds good on the surface, by logic, this argument makes no sense whatsoever.

The 2016 Berlin OpenSpace Agility Workshop (Oct 11-12)

We are pleased to be offering the OpenSpace Agility Workshop in Berlin Germany !! This 2-day learning event is designed for those who want to achieve rapid and lasting Agile adoptions.




Who Benefits Most From Attendance:

  • Agile Coaching professionals & Scrum Masters
  • Executives & Managers who are considering an Agile adoption
  • Executives & Managers who have a troubled or underperforming Agile adoption

What You Will Learn:

The successful Agile adoptions are powered by human engagement. Improvements in morale, productivity, quality & predictability follow. This course teaches how to achieve very high levels of engagement in your Agile adoption, leading to strong improvement in everything you are measuring.

During this course:

  • Participants gain an understanding of the cultural dynamics of adopting Agile
  • Students learn the OpenSpace Agility technique, a proven method for obtaining a rapid & lasting Agile adoption
  • Students learn how to rapidly implement Agile in service to creating a high-performance organization
  • Executives, sponsors, coaches and team members learn how to create a rapid and lasting Agile adoption
  • Participants learn how to apply the OpenSpace Agility method to stabilize ongoing & troubled Agile adoptions
  • Students learn how to customize and tailor the flexible OpenSpace Agility method to fit their organizational context and circumstances


About the Instructor:

Daniel MezickCoaching executives and teams since 2006, DANIEL MEZICK is an expert on extending adaptive Agile culture beyond software. His books and workshops teach you how.

A  frequent speaker at industry conferences, Daniel’s list of clients include Capital One, INTUIT, CIGNA, SIEMENS Healthcare, Pitney Bowes, Harvard University, and dozens of smaller enterprises.

His first pioneering work on culture was published in 2012.  THE CULTURE GAME described 16 specific patterns that extend Agile ideas across the organization, beyond software. THE CULTURE GAME describes a very clear, step-by-step program for doing exactly that.

In 2014 he built upon THE CULTURE GAME patterns and formulated the OpenSpace Agility method. OpenSpace Agility is a flexible template for enabling lasting change in your organization. Daniel is the primary author of the OPEN SPACE AGILITY HANDBOOK  with co-authors Louise Kold-Taylor, Deb Pontes, Mark Sheffield and Harold Shinsato.

Daniel’s enterprise consulting practice is built upon the core concepts found inside these books. Daniel conducts workshops based on these books, and also offers enterprise Agile coaching, Agile training programs for teams, and management consulting.

You can learn more and contact Daniel at



When: October 11 & 12 2016


Cost: $1200US for 2 days includes:

  • Lunches both days
  • Student kit and classroom takeaway materials
  • The OpenSpace Agility Certificate of Completion (link)

Hotel Lodging:

Through September 30, you can mention “OPENSPACE AGILITY WORKSHOP” or “OSA WORKSHOP” to get a discount on lodging. Here are the hotel details:

You can arrange lodging at The Ellington Hotel at the rate of EUR 108,00 excluding breakfast. Specify “OSA Workshop” or “OpenSpace Agility Workshop” when you arrange your lodging.

You can make reservation requests by email by sending to:


Address: Nürnberger Str. 50-55, 10789 Berlin, Germany

Please make the reservation before September 30th. Please mention “OSA Workshop” or “OpenSpace Agility Workshop” for the group rate.


October 12: Optional Train the Trainer Feature

This promises to be an interesting learning experience, with certification. Those who want to teach OpenSpace Agility and award the certification to students, may optionally attend the Train-The-Trainer segment at the end of the 2nd day. This positions the participant to becomes an OpenSpace Agility Certified Teacher. After gaining some experience, candidates can submit an application and take a short exam to become authorized trainers.


We look forward to meeting you at the Berlin Workshop!









OpenSpace Agility at AGILE DC!!

We are happy to announce that we are a Platinum sponsor for the AGILE DC event coming up October 24, 2016!!

Large organizations are ramping up for big, enterprise-wide Agile adoptions.

Did you know that large-scale Agile-adoption efforts can cost ONE MILLION DOLLARS or more?

We show you how to do it better.

We show you how to get MORE out of your investment of time & money

OPENSPACE AGILITY takes the risk out of Agile adoption (and saves you LOADS of money on coaching !! ) …by including and engaging your people in the process.

We show you how to protect your investment, save serious money, and get real traction by engaging everyone in your organization. The OPENSPACE AGILITY HANDBOOK shows you how….

…We plan to give away up to 400 copies of the OPEN SPACE AGILITY HANDBOOK to all participants who visit our booth and provide a business card or otherwise sign up for our list:

Screen Shot 2015-10-23 at 8.45.50 AMThe OPENSPACE AGILITY HANDBOOK is a tutorial and reference guide on OPENSPACE AGILITY, a simple, highly inclusive method for getting a lasting and genuine Agile adoption.

Is your “Agile transformation” actually not what you expected? Are you facing serious resistance to change in your organization? If so, “OSA” is for you!

So: Come visit our booth, sign up for our list, and get yourself a complimentary copy of the 109-page OPENSPACE AGILITY HANDBOOK !


This books sells for $24.95 on AMAZON !!

It’s yours (with our compliments) at AGILE DC !!





You can learn more about the OPENSPACE AGILITY method via this executive summary:

OPENSPACE AGILITY executive summary:

You can learn more about AGILE DC here !

AGILE DC Conference, October 24 2016:



Scaling Engagement

Human engagement is what actually scales, and INVITATION is how you get it.

INVITATION is what actually scales. Not frameworks, not buzzwords. Not the usual BS.

Every good game has opt-in participation. Organizational change is a game.

Play it well. Learn to invite.

Playing the Game

Here is a way to play the OSA game with your client, without ever mentioning Open Space Technology, OpenSpace Agility, Invitation-Based Change, or Invitation-Based Leadership. It’s all very simple.

You DO yourself what you want the client to DO, namely:

To test the willingness of someone to go somewhere, or do something, by inviting them.

Here is the scenario: you are coaching, you are speaking to the formally authorized leader, the one with the budget authority to fund an OSA implementation (or not.) She contacted you based on what a colleague said about your Agile coaching.

You show up, and she wants to purchase some Agile training and coaching right away. After the usual pleasantries, which often include asking “why” questions (which I typically avoid completely by the way,) the time comes to figure out what is what.

You want her to issue an invite to all the teams with respect to the Agile training, and have them opt-in to attendance, with the understanding that once all the opt-in seats are taken in the initial class, any team that “wants in” has to wait… till the next class happens.

…But you sense she is not really ready to execute on opt-in Agile training. She is not ready. So you punt. Here is what you do.

1. You sell her the mandatory-to-attend training she wants, but only if she goes for this invitation herself:


Coach: “…I’m looking forward to delivering this Agile training program for your people. And some coaching as we have discussed. I also want to help you save serious money in the implementation of your Agile adoption program- I want to help you save potentially tens or even hundreds of thousands of dollars as you do this. Is that interesting to you? Can I help you do that?”

CTO: “Seriously right? OK. What’s the catch? Keep going. I’ll play along…”

Coach: “…To do this, to save loads of money doing this Agile adoption, I just need you to just kind of play along with me, and try some very simple things that don’t cost anything. Can we do that? I need you to play along and just do some of what I call “low cost, high-learning-yield” experiments.”

“Did I scare you away yet?”

CTO: No. Not yet! Keep going…”

Coach: “…I want you to change some of your meetings around. OK? I want you to make at least 4 of your meetings in the next month optional to attend, as an experiment. And see what happens. Are you willing to do that?”

(…a conversation <and some hilarity> ensues… as the CTO asks the usual questions, and indicates non-verbally that this idea is a bit uncomfortable for her. She has all the usual objections. She finally says no (politely) after hedging a bit. Discomfort is evident.)

Coach: OK, so how about just 2 meetings in the next 4 weeks? It can be any two meetings you want to try this out on. I promise this is sure to be interesting for you. We’ll both learn a lot, about a lot. Wait till you see this. I don’t want to ruin it for you, but…”

CTO: Hmmm. Yes, I think I could do that. Two meetings. Ok ya. yes. Let’s give it a try. What’s teh worst thing that could happen?

Coach: Wait…Could do that, or “can do that?” Is that a yes?

CTO: (laughing) “Can. Yes. Lol…”


So several things are going on here:

1. You never mentioned OSA, Open Space, Invitation-Based Change or anything like that AT ALL

2. You are delivering what she wants to buy- and has budget for: TRAINING. Bummer though: everyone HAS to attend it. But wait…

2a. You have also stopped conversations with OTHER coaches. They are no longer in the picture. OK? You are the person in the driver’s seat. You are delivering the initial training and coaching.

3. …You tested for trust and she signaled she trusts you, and will play along, try on “optional meetings,” as an experiment. With HER meetings.

4. You invited her to do something, and she signaled no, and you reduced the ask by half, and she said (tentative…) OK. Yes.

4a. You are being indirectly aggressive. You are WASTING NO TIME  in trying to figure out if you have a willing leader here, or not. You’re probing for willingness to go all the way with OSA…eventually.

5. You are doing a great job here.

6. The leader is submitting to being led through some learning. You are leading the leader. You are doing your job.

My friend Susan Daigle lamented, in the OSA Facebook group, , about all the joyful Open Space stuff going on at the Bangalore Scrum Gathering:

“…Such joy to read how hearts and minds shifted. How I wish what happened there in Bangalore could happen more in our corporate America.”

This little narrative illustrates what has to happen to get your wish Suzanne.

This is an actual story about an actual conversation with an actual CTO.

Can you see where this story is going? be continued…

Still reading? Curiously drawn to OSA? You might consider joining the OSA groups on Facebook, Twitter and Linkedin:

OSA Facebook:

OSA Linked In:

OSA Twitter:


Agile Medication Revisited

I recently was asked by a friend to provide a book recommendation for executives that want to learn about Agile fundamentals.

Here is what I offered as guidance. This has everything to do with OpenSpace Agility, which is a method of introducing Agile change that focuses on principles and stops well short of prescribing practices. Here we go: The question from a friend….

“If you were to recommend just one book on Agile/Scrum Methodologies, what would they be?

“This is for a client CEO to give to his senior leaders. Looking for intro to principles and practices especially as it relates to driving innovation, digital UX design, and collaborative, high-performance culture.”


People (and especially those very “busy” formally authorized leaders) often want A-B-C prescriptions that relieve pain, now. The problem of course is that the actual root causes of the pain do remain. Right? This is an especially acute condition across the wider world of Agile today. The focus on practices eventually becomes a very big problem.

If and when the core underlying principles (which actually power those practices) are ignored, expect troublesome side effects. Ditto for the ignoring the Agile values, which power those Agile principles.

Michael, I cannot offer you a design-thinking book however I can tell you that core-values and supporting principles are far more important that practices where Agile is concerned. This is true regardless of the context of where the work is performed (software work, or “agile beyond software” aka “Lean-Startup applications.”)

The core of the Agile thing is expressed in the Agile Manifesto. Teach them that. I’m concerned that if you hand them an Agile-practices book your client will not be served. Practices change. Principles don’t. This teaching is harder to deliver than a practices-gospel. It’s also much harder to receive. In service to my clients I offer them the Agile Manifesto as the definition of Agile we plan to use for the time being. If they are new to Agile thinking, start the discussion here and then lead them to a more mature conversation when they have digested these core fundamentals. The Manifesto is 15 years old and it still applies. There’s a reason for that.

Agile Manifesto

Here are some resources:

Understanding the Manifesto…/ref=cm_cr_arp_d_viewpnt_rgt…

The following book review is typical of those seeking immediate pain relief (medication) via an A-B-C prescription of practices. It just doesn’t work that way. There is no standard Agile implementation. As a leader, you are responsible for doing the hard work of creating a space where your people can define, tailor and customize your own program. That is the essence of effective agility. There is no pill you can take for this.

Screen Shot 2016-06-30 at 6.25.12 PM














See it?
This is the awkward message of OpenSpace Agility: if your Agile implementation is to have any chance of success whatsoever, you and your organization must take total responsibility for it. You must customize and tailor everything to fit your context. This requires some awkwardly honest conversations. The OpenSpace Agility method creates a space where these very awkward and very responsible conversations can actually happen.

Invitation as a Leadership Art

Any framework is OK, as long as those affected are invited, and are actually choosing to experiment with it. As long as there is genuine (and informed) consent from those affected. The framework used is not the problem, but rather the mandate of it… by authority.

Any experience with an approach to change is best framed as an experiment– one to be inspected by the tribe on a very specific date, some 45 to 100 days hence. This process is called Invitation-Based Change or IBC.

At the core of IBC is an invitation, from leadership, to an experiment with new ways of working. This is an invite to participate in what we commonly call “co-creation.”

A more accurate metaphor might be “the invitation”…the invitation to be a character in the new story, and even become a co-author of an exciting and emerging narrative. To be the characters in the story and the co-authors of the new story.

And these participants are not “bought in.” Because, truth be told,  the term “bought in” implies something is being marketed. Something is being bought and sold. Via persuasion. And that’s not what we are doing here. Here, we are not selling anything to anyone but rather, inviting participation. So, not “bought in” but rather, “located in” the emergent story of change.

In Invitation-Based Change, the authentic invitation from leadership includes an explicit and scheduled opportunity to inspect the results, as a group, typically with a fully-authorized, all-hands, enterprise wide, dialogue-oriented “Open Space” meeting. This enterprise-wide inspection of the results usually requires a duration of at least one day. It is a  “gathering of the tribes” from across the enterprise. Everyone affected is invited. What is actually going in this 1-day meeting is the rarest of events:  the genuine and authentic experience of “organizational learning.



Invitation-Based Change requires leaders actually become competent in what we have come to call “Invitation as a Leadership Art.” These concepts are embodied in a method called “OpenSpace Agility.” It is the first of several methods that are emerging inside the wider container of “Invitation-Based Change.” OpenSpace Agility (OSA) is built upon the empty, more generalized “beginning-middle-end” structure called Prime/OS. Prime/OS is the core bedrock foundation of OSA.

You can learn more about these simple, powerful, open-source culture technologies, right here, right now, via these two links:


The Mandate of Holacracy At Zappos

An actual example may more fully illustrate: Let us consider the mandate of “holacracy” at Zappos.

The introduction of holacracy at Zappos was, at best, an authoritative “push” gone terribly wrong.

At worst, holocracy was implemented as a despotic, tyrannical mandate. As push. With forceful persuasion. As coercion. I saw it coming in late January of 2104 and made certain predictions in March of 2014 concerning the predictable result.

The entire unfortunate mess is easily avoided by leveraging the incredible power of invitation. It offers the power to generate co-creation, alignment, and authentic organizational vitality. The Zappos story might have started this way. It did not.
Any framework is OK, as long as those affected are invited to the experiment, and each invitee is not coerced but rather, invited…and is actually choosing… to play the game.

Are you interested in testimonial videos from actual people who have experienced Invitation-Based Change inside real organizations?

You can find testimonial videos here- each is only 15 minutes long:

See also: 

Invitation-Based Change (link)

Invitation in OpenSpace Agility (link)

The Mandate of Holacracy at Zappos (link)

The Shu-Ha-Ri Argument

“These developers have no idea at all about Agile practices. They need to slavishly follow what we tell them- at least for a while. We must show them the exact A-B-C steps. And they must do them. It does not matter if they want to or not. They are in the “Shu” stage of Shu-Ha-Ri. We must tell them exactly what to do, and they must do it.”

Well, OK. Let’s unpack this.

First, “Shu-Ha-Ri” comes from the martial arts. “Shu” is beginner’s mind. “Ha” is the intermediate-stage of competence. “Ri” is mastery. So far so good.

Second, those karate students, those Judo students, those Kempo students….they all WANT to be taught. They want to learn. By being present in the dojo, they are signaling that they are submitting to the authority of the teacher.

So they are willing to be led through learning. WILLING. They are submitting. And they are in Shu-mode.


The situation is completely reversed when you impose teaching about Agile practices on teams, and then make them do these practices. These teams never agreed to submit to anything.

Yes- they are in “Shu” mode but let’s not pretend that they agreed. They did not.

Therefore: the Shu-Ha-Ri analogy does not really make sense, because you are imposing a set of practices on people who never agreed. People who never consented. 

The predicable result is a very unhappy ending. For everyone. This is the main problem with your Agile adoption. You’re forcing it on intelligent people, people who are problem-solvers.

People who are independent thinkers.

People who have a strong need for control.


So stop doing that. And use invitation instead. It actually works!


And please stop it with the Shu-Ha-Ri argument, because if they never agreed, then that argument just doesn’t have legs.


Definitions Are Agreements

Self-management is a game. Like any game, self-management requires very clear agreements.

To play any game, we must all first agree on the goals, the rules, and the progress-tracking aspects.

Since the good game has opt-in participation, the opportunity to play is presented as invitation.



Communication using human languages is, itself, a kind of game.

The goal of the game is the clear sending and clear receiving of clear messages.

The rules include information about what language is used, and the definition of specific words used.

We track progress by the volume, the frequency and the quality of the messages sent and received. We also track progress by how engaging the conversation does (or does not) become. By the progression of topics discussed. By the additional agreements made as a result of the sending and receiving of these messages. And so on.

These ideas quickly become useful when preparing for change in organizations. Let’s apply these ideas now.


Agile Change

If an org is moving in an Agile direction, it is essential to define what “Agile” actually means, and agree to use that definition across the entire set of people affected. If anyone disagrees, we must ask what it takes to get them in. Where definitions are concerned, we must agree if the game of communicating is to be experienced as a good one.

Likewise, if the practices to experiment with include Scrum, it is essential to precisely define what the word “Scrum” actually means, and begin using that definition consistently when sending and receiving messages (communicating) about that subject.

The definition of words constitute important agreements without which effective communication becomes very difficult. In OSA, we define “Agile” to mean the 4 values and 12 principles of the Agile Manifesto. This brings tremendous clarity to the task of communicating. The clear definition reduces one of the many anxieties that come with the liminality that change creates. A big part of the pre-work of any change is to begin the process of agreement on the rules of the game. Within this context the definition of essential terminology is itself essential to a good start.

And so it is, that the precise definitions of essential words are in fact the most important agreements, as they are the foundation of any agreements that follow.

Invitation Based Change

During the OSA Workshop held June 09-10 (2016) in Leuven, Belgium, a participant named Jef Cumps began using the term “invitation based change.” He used it several times (I think) before I actually began noticing. At one point, I noticed this and I asked him to stop, and repeat what he just said.

Invitation based change,” he replied.

This is a remarkable turn of a phrase. It describes everything OSA is doing, and also is a great description of Open Space Technology (OST) itself.

And so: it is now the term we use to describe exactly what we are doing with Open Space and OpenSpace Agility.

Invitation based change is bigger than OpenSpace Agility, bigger than even Open Space Technology. It’s a mindset, the mindset, a useful philosophy of change, and the idea that guides almost any authentic and lasting change in almost any organization. 

Because truth be told, self-management is what actually scales, not your A-B-C prescription or “shiny-infographic framework.”

The difficult truth is that engagement is essential to self-management, and that genuine invitation (aka “opt in participation”) is the primary way to get it. The idea is to frame everything as an experiment to be inspected. When leaders frame new ideas as experiments, to be inspected, something odd happens. Something rather nice.

We, the affected, suspend our disbelief, and actually try it. We engage. We the affected “act as if” it could work, and actually give it a try. Those who might resist suddenly become willing to “pretend” and “suspend disbelief” that the change might actually be interesting to investigate as an idea. An idea that is to be inspected after a period of direct experience. In other words, we approach change in an agile way. Via “committed experimentation.”

Invitation based change converts resistance to support. And more than occasionally. It converts strong (aka “passionate”) resistance from a “bug” to a “feature.” It creates a “double positive.”

Invitation based change is the future of work.

Are you skeptical? Good…

…let’s just give it a little time. Do a few experiments. 

And inspect them.

And go from there.

Special thanks for Jef Cumps, who coined this phrase “Invitation Based Change,” or what we are now calling “IBC” for short.

You are invited to investigate.


Related Links:

OpenSpace Agility (link)

The OpenSpace Agility group on Facebook (link)

Vast majority of employees not engaged- Gallup poll (link)





Discovering What is Possible

We live in a world where a mechanistic, “machine” view of organizations has served for some time. The end of this era is upon us, and the transition to a living-systems view is well underway.

Organizations are more like living things than they are like machines. Without getting into all the details of “why,” this essay assumes the living-systems view is the more accurate view, the more useful view. The view that is actually closer to reality.

In the living-systems view, change is not “managed.” Instead of having a definite end point, the process of change is based more on encouraging a general direction rather than a specific, ultimate destination with a date attached.

Which brings me to the subject of this essay: discovering what is possible. For purposes of this essay, assume the organization under consideration has these properties:

  1. The org is a business entity, organized as a corporation
  2. The org is not focused on selling software. Instead it has a services or products that it sells.
  3. Leaders (formally authorized) are contemplating the “change management” that may be involved in helping the entire org change in some way; presumably to become more effective.
  4. The org employs at least one hundred people and may have thousands of employees.
  5. The “formally authorized leaders” (hereafter, the “FALs”) are entirely well-intentioned even as they may be ignorant of certain fundamentals with respect to the conditions necessary for manifesting an adaptive, resilient organization
  6. The people in the organization are for the most part quite familiar with the current cultural game, and are generally happy with the way things are. They know the expressed and implied goals, the rules, and how the overall culture works.

Given these assumptions, the completely normal pattern goes something like this:

  1. Behind closed doors, the 100% well-intentioned FALs formulate a plan for change. This usually includes the “rolling out” of training, followed by some scheduled “coaching” with the help of highly paid consultants.
  2. An announcement of intent is issued. This is usually in the form of some emails from the FALs to the organization’s employees. These emails from the FALs describe what is about to happen.
  3. The program is initiated, usually with an immediate and pronounced uptick in everything that is being measured. This is reassuring- at least at first.
    1. Typically, measurement is happening in a meaningful way for the first time. Before long the highly paid consultants are busy doing their work.
  4. After a while, things start to wobble. There is some “murmuring” from the rank and file.
    1. Not just the rank and file resist the change. Some people who are in authority also are uncomfortable. Their direct reports sense this vibe and adjust accordingly.
    2. Those uncomfortable with the change do not simply vacate. Instead they serve to thwart the change by subtle moves intended to outwit, outplay and outlast the change issues from “on high.”
  5. The budget for consultants is consumed, and they leave. Shortly after that, the “change” begins the process of reversion to the mean. In other words, a backsliding to the starting point.

Does this sound familiar to you? I certainly hope so. I have not told the whole story, but you get the idea.

After a time, the “coaches” and consultants vacate. When they do, the org reverts back to it’s previous state, or, at a minimum, heads in that general direction immediately. At the end, the org has spent hundreds of thousands of dollars on a “change management program” that never did actually work.

Screen Shot 2016-06-08 at 9.30.53 AM

The Prime/OS approach short-circuits this by-now-familiar pattern of failure, by discovering what is possible.  By helping the FALs figure out the immediate next steps via quick, short, actionable “loops of feedback” that provide rich data for input into leadership decision-making.



Instead of putting down a bet of hundreds of thousands of dollars with far less than 50-50 odds for success, Prime/OS invites everyone affected to come and discuss the change.

Instead of following a monolithic “A-B-C” plan (typically the “framework” of a consulting firm,) Prime/OS invites everyone into the process of changing. And to write the new story. And be a character in this new story.

Instead of an edict or mandate from management, Prime/OS suggests a series of experiments to be inspected.

One of the goals of Prime/OS is to engage the people affected by the change. To do this, Prime/OS leverages the concept of invitation. Those who are curious and want to explore how to make change happen accept the invitation. Those who like things the way they are do not. In all cases, Prime/OS increases your chance of success by increasing the level of human engagement in the change.

Prime/OS increases the level of engagement in the process of changing and this is why Prime/OS actually works.


Avoiding the “Self Organized” Approach

The idea that self-organization and self-management are messy any chaotic is actually quite false. Groups of people who share a common purpose and organize around it are often called “self organizing systems.” This label assumes that people are the same as birds, insects and fish that “self organize.” This is not strictly true, and I therefore prefer the term “self management” when describing how people self-organize. Where people in organizations are concerned, “self organization” is in fact self-management.

Tremendous gains in productivity are possible when individuals and teams are self-managing.

Self-management is only possible when the people involved are making decisions. Decisions are what engages people, and decisions are essential if the group is to self-manage. Since self-management requires enough authority to make decisions, FALs often freak out at the notion of  authorizing self-managed teams, departments and divisions. The assumption is that chaos will ensue.

Screen Shot 2016-06-08 at 9.32.51 AM

In Prime/OS, the FALs to do not encourage chaos and do not give up “control.” Instead, FALs create the very conditions for self-management by clearly identifying and communicating the following:

  1. The direction of the organization (an example might be “towards continuous improvement” or “towards more efficiency in operations.”)
  2. The “guardrails,” or limits outside of which are considered out-of-bounds. (an example might be a set or principles, or a set of rules for action.)

Interestingly, the FALs in Prime/OS need to avoid defining the practices or “ABC” steps needed to get started. Instead, individuals and teams make decisions about the specifics. To encourage this, FALs stop well short of naming specific practices.  If specific practices must be specified, these are presented explicitly and repeatedly as “experiments with specific practices for a specific limited time”, or “a trial period after which we will inspect results.” The “why” behind this is quite obvious: we need the people who do the work to be making decisions if we are to engage them. The entire hypothesis of Prime/OS (and OpenSpace Agility) is very simple:

 Human engagement is essential for any change to be authentic, genuine and lasting.

Sometimes, the definition of practices cannot be avoided. The solution here is to frame the entire thing as an temporary experiment to inspected. The org will “suspend disbelief” and “pretend” during the temporary/experiment period, confident that we will then inspect the results. This framing-the-experience-as–an-experiment is a way to bring everyone into the story of “inspect and adapt.” This is the way to introduce the idea of a change. The hypothesis is that those who resist the change can in fact assure failure. Experimentation affords those who may resist, with the opportunity to speak their mind after getting some experience with the contemplated change.


A Practical Example for Your Consideration

Let’s take a practical example: say you are a formally authorized leader who is going to be introducing some pretty big changes to your organization soon. Let us assume further that specific new practices are the content of the change. Here is your solution:

  1. Define a period of experimentation
  2. Start in “open space.” Call an enterprise-wide, “all hands” meeting to air concerns and issues. Assure everyone that this is an authentic experiment- that is, one to be inspected, 45 to 100 days hence.
  3. Do the experiment.
  4. End in “open space.” Call an enterprise-wide, “all hands” meeting to inspect the results.
  5. Use the wisdom harvested from this process to “go again” if necessary.

The alternative? Simply announce the change, fire everyone who disagrees, and hire new people who agree to the new “game change” you want to implement. There is only one problem with this: it is traumatic for your organization, and will result in chaos, negative emotional energy, and also poor results for years to come, before stabilizing.

A better approach is to view your leadership as cultivation and stewardship, rather than driving a vehicle or operating a machine. Your organization is more like a greenhouse than a train.

Screen Shot 2016-06-08 at 9.37.17 AM


The Prime/OS approach actually works, if you define success as “reaching extremely high levels of engagement in the investigation of how to change.” It starts and ends in Open Space, a meeting that is optimized on creating the conditions for the highest levels of human engagement possible. A key hypothesis of Prime/OS is that for any lasting change to occur, the humans affected must be engaged. Prime/OS therefore encourages very high levels of engagement. And that is why it uses Open Space.

Prime/OS is very simple and can lead to much higher performance across the organization. But to use it, if you are a formally authorized leader, you must first believe that for any change to be genuine and lasting, the humans affected must be engaged in the process of changing.

Prime/OS is a tool for formally authorized leaders who actually believe this is true.

See also:

The Worldwide Employee Engagement Crisis (link)

Prime/OS described (link)

70% of USA Employees Not Engaged At Work (link)




Q&A on OSA: online live video event on 12/14/2015

Next Q&A on OSA, 12/14, 4PM EST (GMT-5)

These Q&A calls are an ongoing series of sessions designed to enable practitioners and Sponsors. These sessions are designed to handle your questions after absorbing the OSA basics. We plan to have a guest speaker during the last 30 minutes, for example a sponsoring exec who has used OSA, or an Agile Transformation Lead who has led an Agile adoption in their org using OSA as the transition model.

Some good reasons for participating on the call include:

  • The low time commitment needed to take the next step- just 90 minutes…
  • This is an opportunity to get some of your more advanced and informed questions answered;
  • This is an opportunity to sample the online format before committing to the online OSA Workshop;
  • This is an opportunity to hear from others around the world who are exploring invitation-based culture technology and leadership tools.

We keep it to just 10 participants total, to keep it tight and also  tailored to the people who are actually present. Once these seats are occupied, the event is full and you’ll have to find another one to sign up for. You can find a class here.

Each Q&A event is unique, and so are the questions. This is not a canned-presentation and is more like a live-classroom conversation between colleagues for 90 minutes. This is a low-cost and low-commitment way to explore OSA beyond the website or the OSA HANDBOOK.

People from New Zealand, Canada, Singapore, Finland, USA, Canada, India, France and more have participated in these brief and engaging online video events. Many are returning to attend again after attending initially. $20US is charged as a nominal fee to encourage your commitment to attend at the appointed time.

This is the spot to get your questions answered and also meet others and explore the questions they are asking about implementing OpenSpace Agility.

Screen Shot 2015-04-26 at 4.19.48 PM

Registration Link:

OSA Workshop in Montreal !

Save this link for details  on the upcoming 2-day OSA Workshop in MONTREAL.

January 15,16,17

The date is January 16-17, a Saturday and Sunday. We plan to kick it off on Friday night (1/15) informally!

Each student receives:

  • The OSA certificate of completion
  • Listing in the OSA-certified consultants listing, on the OSA web site  (see example here)
  • Membership in the private online group of certificate holders




Click here to ask a question: CONTACT US

COURSE DESCRIPTION: (see English below….)


  • Comment créer une culture d’engagement, d’agilité et d’efficacité dans votre organisation ?  
  • Quelles approches ont fait leurs preuves pour atténuer la résistance à de nouvelles façons de travailler ?
  • Qu’est-ce qui achoppe dans les approches traditionnelles de gestion du changement, et quelles leçons pouvons-nous en tirer ?


Dans un contexte de changements rapides et de complexité, l’engagement, l’agilité et l’efficacité constituent la « sainte trinité » de la culture organisationnelle. Pourquoi la plupart des initiatives de changement continuent-elles donc à miser sur un mandat de la haute direction, sur un programme prédéterminé de changement qui prive les gens de toute influence? La plupart de ces initiatives sont pourtant loin de produire les effets désirés : il semble que le changement organisationnel ne puisse être « géré ». Il nous faut une approche radicalement différente.


Pour que votre organisation rehausse ses niveaux d’engagement, d’agilité et d’efficacité, il vous faut un processus de changement imprégné de ces ingrédients. Comme on dit, « le message, c’est le médium ».  Voilà pourquoi l’approche OpenSpace Agility™ (OSA) s’appuie sur la puissance de l’invitation, de l’intelligence narrative, des itérations, de l’auto-organisation et de la mécanique du jeu pour générer un changement rapide et durable – et efficace – dans toute l’organisation.


Présenté pour la première fois à Montréal, cet atelier hautement interactif offrira de précieux apprentissages à quiconque facilite des processus d’adoption Agile ou d’autres changements culturels et organisationnels. Vous qui êtes :

  • dirigeant(e) ou entrepreneur(e),
  • gestionnaire de services et d’équipe,
  • coach, consultant(e) ou facilitateur(trice),
  • professionnel(le) du développement organisationnel ou agent de changement,

venez apprendre avec nous les 15, 16 et 17 janvier 2016 comment OSA offre aux leaders une plateforme aussi simple que puissante pour cultiver le changement.




  • How can you create a culture of engagement, agility and effectiveness in your organization?  
  • What are some proven ways to overcome resistance to new ways of working?  
  • What’s not working about the most common approaches to change, and what can we learn from that?



In these times of rapid change and complexity, the “holy trinity” of organizational culture is engagement, agility and effectiveness.  Why, then, do so many change initiatives still rely on a disenfranchising mandate from above and a rigid, pre-planned roll-out, with the majority of initiatives falling well short of the desired effect?  It seems that organizational change can’t truly be “managed.”  A radically different approach is needed.


If you want to move your organization to higher levels of engagement, agility and effectiveness, you need a change process that has those very elements woven into it.   The medium is the message, as the saying goes.  This is why the OpenSpace Agility™ (OSA) approach integrates the power of invitation, leadership storytelling, iteration, self-organization and game mechanics to achieve rapid, lasting – and effective – change across an organization.


Join us on January 15, 16 and 17, 2016 to learn how OSA provides leaders with a simple but powerful template for cultivating change.   Offered for the first time in Montreal, this highly interactive workshop will be valuable for anyone facilitating processes like Agile adoption and other culture change in organizations, including:

  • Executives and business leaders
  • Managers of departments and teams
  • Coaches, consultants and facilitators
  • Organizational Development professionals and other change agents




Click here to ask a question: CONTACT US




Is Mandating Agile Practices and Good Bet?

Hundreds of millions of dollars are spent annually on Agile training, Agile coaching, and Agile-related software to manage the process.

Hundreds of millions. Annually.

It is not uncommon for a large organization to spend over 1 million dollars per year on Agile-related products and services.

Is this money being well-spent? Are the organizations that are spending this money making a good bet?

Gambling is the betting of money at unfavorable odds.

Wagering is the betting of money at favorable odds.

Let’s investigate, and see which one it is…



The History of Agile Adoptions

Let’s inspect this.

The sample size across the entire worldwide Agile experience since 2001 is at least 13 years of mostly-mandated Agile adoptions, worldwide! That might be 1,000 attempts a year for 13 years. Let’s use 13 years in this illustration. I am using low numbers, and being polite. (This was written in 2014….)

OK: If Agile-practice mandates actually worked, we would be able to point with pride to thousands upon thousands of verifiable and unmitigated success stories.


So for example, even with just a 20% win rate, we might be able to identify as many as 2,600 legitimate successes which is 20% of 13,000 attempted “Agile transformations.”

WOW-  TWO THOUSAND SIX HUNDRED success stories worldwide. Great … right?

Not really!

If  a mandate works 20 times out of 100 attempts, and a consent-based approach works 80 times per 100 attempts, both can be said to work SOME of the time.

A 20% win rate is nothing to brag about.

If a mandate will work in about 1 out of  5 attempts, in the long run, it is a gamble a bet at very unfavorable odds. You are a “4 to 1 dog against.” 4 out of 5 attempts (on average) will fail in the long run.

Are those actually good numbers?

Are we actually happy with that?




The OpenSpace Agility (OSA) assumes that human engagement is essential.

It replaces the mandate with an invitation. It is an approach that succeeds in  greatly improving the odds for success in getting a rapid and lasting Agile adoption, by acknowledging the reality of imposed mandates and replacing those nasty mandates with opt-in invitations.

The method includes leadership storytelling, the use of Open Space, deliberate experience design, game mechanics and more, all in service to the creation of rapid and more lasting Agile adoptions.



OpenSpace Agility gets it done. Are you ready? Let’s do this: CONTACT US


Related Links:

The Ken Blanchard Companies revealed the shocking fact that up to 70 per cent of all change initiatives fail. The article:

Mastering the Art of Change (link)


Simplicity Is What Scales

Participant engagement is absolutely essential to enterprise-wide process change.

I do not believe I am oversimplifying when I say that engaging people- at every level of authorization– actually creates ALL of the “right underlying conditions for agility” that are necessary to succeed.

I do not believe I am oversimplifying when I say that engaged people can and do routinely solve big, huge problems like “crushing system dependencies” without any help from an external authority. Being able to do this (without an army of consultants) is, after all, what self-sustaining, freestanding, enterprise-wide Agility is all about.

Accepting the idea that the “it doesn’t matter if you mandate it or not” is very much out of alignment with absolutely core Agile principles. Martin Fowler said as much, directly and plainly, back in 2006. Back then, he issues a big, protective warning to the Agile community. You can see for yourself by following the link below.

Engaged people, by definition, already know how to self-organize.

Some “thought leaders” in the Agile community explain that “people do not actually know how to self-manage and self-organize”, and that experts must “help” them learn how to do this.

Really? Is this true? Do we actually believe this?

Are we then to “manage” this process of self-management? Self-organization?

If the answer is yes, perhaps we are part of the very problem we claim to be solving.

Martin Fowler said as much in 2006: The Agile Imposition:

“…Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.”

Simplicity is what scales. It all starts in Open Space.