Blog Posts:

Invite Not Impose

What we are calling INVITING LEADERSHIP may be the most important leadership skill of the 21st century.

Especially when the executive leaders are endeavoring to bring change and real improvement to the organization.

Employee engagement is essential to success in achieving a lasting business agility transformation.

Imposing practices enterprise-wide does not actually work long-term, and never actually did.

Everybody knows.

But: don’t take my word for it.

Here’s what other world-class experts have to say:

 

 

 

“The failures resulted from trying to use positional power to impose a process.”
-David J Anderson, management science pioneer and author. From his book The KANBAN Method (page 21)
 
“…Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.”
-Martin Fowler, author and Agile Manifesto signatory
 
“…You know as well as I do that if the team really doesn’t want to use a methodology, IT WON’T WORK. Let them make their own assessment.”
-Jeff Sutherland, Agile Manifesto signatory & Scrum co-author. From POWER OF SCRUM book, page 31 
I have read several studies. From 70% TO 87% of workers dislike their job/are disengaged. THAT IS A HORRID CONDEMNATION OF MANAGERS/LEADERS. (And of the ineffectiveness of those of us trying to fix the problem.)
Tom Peters, world famous authority on management & organizations. Author, IN PURSUIT OF EXCELLENCE. From his Twitter feed (link)
 
“…I hope I’ve made clear that imposing agile methods is a very red flag. ”
Martin Fowler, The Agile Imposition (link)
 
“Transformation occurs through choice, not mandate. Invitation is the call to create an alternative future.”
– Peter Block, world renowned expert on culture and community. From his book COMMUNITY: The Structure of Belonging
 
“Transformations can’t be accomplished without others helping voluntarily, & people don’t help unless you engage them first.
-Geoffrey Moore, world-renowned management consultant. (Arguably one of the greatest management minds of our time.) From his book ZONE TO WIN. 
 
“By 2002, I had concluded that prescriptively enforcing processes on a team didn’t work.”
David J Anderson, management science pioneer and author. From his book The KANBAN Method (page 03)

 

 

 

If this is not a complete refutation if what passes for “best practice” in the Agile industry, I do not know what is.

The obvious path forward goes something like this:

FOCUS YOUR EFFORT ON ENGAGING EMPLOYEES IN THE CHANGE.

Imposing change does not work. It is a complete waste of time and MONEY.

If you are an executive leader: do everything you can to avoid this trap. Stop yourself from listening to those “leading” Agile consultants that are telling you that you can push, you can force. That you can “roll it out.” That you can impose.

Because: it simply does not (and never did) WORK.

Listen to REAL Agile experts. (See below.) Stop listening to Agile consultants who say NOTHING about the essential nature of employee ENGAGEMENT in getting real success with Agile.

You, are invited. You are invited to:

Stop accepting advice from these people: THE AGILE INDUSTRIAL COMPLEX (link)

Start inviting.

 

Resources:

On social media, follow the hashtag: on Twitter, LinkedIn, Facebook: #InviteNotImpose

The OpenSpace Agility group on Facebook (link)

Follow and engage THESE people: The REAL AGILE LEADERS HALL OF FAME (link)

Engagement Models Explained

Employee engagement is essential to rapid and lasting change. It’s impossible to get a lasting “transformation” of anything at all if the people affected are not actively and willingly participating.

This is all explained here:

The term Engagement Model, defined: (link)

Mike Burrows (of Agendashift fame) offers these additional defining characteristics and properties of an Engagement Model: I do think they apply…

  • Non-prescriptive by design, Engagement Models work happily with frameworks big or small
  • In their various and complementary ways, Engagement Models bring people together from multiple levels of the organisation, and
  • Engagement Models help the organization to collectively reveal to itself what needs to change, and
  • Engagement Models help the organization come to agreement on what needs to change.

The Engagement Model concept is an essential part of any “transformation” plan. The idea is to address employee engagement UP FRONT and directly as part of the overall design for introducing organizational change. If you do not, means you are not managing the very large risk of FAILURE. And these initiatives can cost millions of dollars and tens of thousands of “up in smoke” employee hours. Those risks need to be managed.

Therefore: any overall “transformation” plan must include an “employee engagement plan” if there is going to be any success at all!

Current Engagement Models that are useful for managing risk in agile and digital transformation (by this definition) include:

Success with Agile: What They Don’t Tell You

 

There is now a very long list of “Agile scaling frameworks.”
None of them work particularly well if they are “rolled out” to a dis-engaged, dis-empowered workforce.

But nobody tells you that. Instead we are led to believe that “if we do the framework right,” success will surely follow.

Except that it won’t. Why?

What are all these frameworks missing?

An engagement model.

Repeat:

An Engagement Model.

And what exactly is an engagement model?

Here is the definition:

Any pattern or set of patterns, reducible to practice, which result in more employee engagement, during the implementation of an organizational-change initiative.

Now let’s be really, really clear about this:

As of today, almost none of the Agile scaling frameworks actually address the issue of employee engagement, let alone the use of a specific engagement model such as OpenSpace Agility. (The framework called Enterprise Scrum, from Mike Beedle, is one notable exception.)
 
OpenSpace Agility is an engagement model.
 
OpenSpace Agility is designed to reduce the risk of failure and increase the chances of success with your chosen framework. It does this by actually engaging your workforce in the change process.
 
Unless and until the issue of employee engagement is addressed, your chosen framework has almost no chance of actually sticking.
Almost NO CHANCE.

 

The Agile frameworks designers, for some reason, have somehow missed something essential, that amounts to a critical success factor: employee engagement in the change process.

Without it, all of your good intentions, all of your good plans, and all of that time, money and effort spent on “transformation” are … up in smoke. Gone. Wasted.

Why?

Because employee engagement in the change process is what actually scales, not your “Agile scaling framework.”

In summary: if you are embarking on a digital transformation, if you are embarking on an “Agile transformation,”  if you are getting ready to change your entire organization, getting ready to “transform” it… here is a word to the wise:

If you cannot name your Engagement Model, you don’t have one.

And you are therefore likely to fail, in a rather epic way.

At enormous cost.

This failure is avoidable. To avoid it, you must address the employee engagement problem, as part of your overall transformation plan.

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: http://www.openspaceagility.com/about
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: http://www.openspaceagility.com/about

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.

 

REGISTER HERE

 

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 www.DanielMezick.com.

 

DETAILS

When: October 11 & 12 2016

Where: ELLINGTON HOTEL (link)

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:

Reservation: reservierung@ellington-hotel.com

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.

screen-shot-2016-09-14-at-11-33-21-am

We look forward to meeting you at the Berlin Workshop!

 

 

REGISTER HERE

 

 

 

 

***

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 !!

 

 

 

LEARN MORE

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

OPENSPACE AGILITY executive summary: http://www.OpenSpaceAgility.com/about

You can learn more about AGILE DC here !

AGILE DC Conference, October 24 2016: http://www.agiledc.org

 

 

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:

<BEGIN>

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…”

<END>

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?

..to be continued…

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

OSA Facebook: https://www.facebook.com/groups/openagileadoption/

OSA Linked In: https://www.linkedin.com/groups/10306772

OSA Twitter: https://twitter.com/OSAgility

***

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.”

<BEGIN VERBATIM REPLY>

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:
http://newtechusa.net/agile/medication/

Understanding the Manifesto
https://www.amazon.com/…/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

 

 

 

 

 

 

 

 

 

 

 

 

<END VERBATIM REPLY>

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:

www.OpenSpaceAgility.com
www.Prime-OS.com

 

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

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.

 

Prime/OS

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

Summary

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:

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.

Right?

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?

 

 

On Human ENGAGEMENT

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.

http://martinfowler.com/bliki/AgileImposition.html