Agile Facilitation Jobs In Maryland

One of my Agile adoption clients, this one in Maryland (about 40 mins east of DC with no traffic)  immediately seeks several people for full-time hire to facilitate the ongoing work of 18 existing software teams relatively new to Agile software development.

In this role you are a member of a 6-person team responsible for facilitating higher performance across the entire enterprise…

…The ideal candidate has:

  • Passionate interest in the dynamics and application of self-organization
  • Solid understanding of Open Space concepts and facilities (strongly preferred)
  • Direct facilitation experience (general meetings, World Cafe etc)
  • Familiarity with Agile software development; especially the Agile Manifesto 4 values & 12 principles
  • Familiarity with concepts and components
  • Familiarity with Kanban, Scrum and related Agile practices (user stories, planning poker, retrospectives etc)

…If you are a successful candidate, you’ll be mentored and guided by professional Agile coaches. These temporary external coaches (myself included) will begin vacating throughout the Open Agile Adoption implementation period (90 to 120 days) after bringing you up to speed…

The primary responsibilities are:

  • Facilitate various team meetings
  • Sense what you teams need from a sociological point of view
  • Create conditions for self-management and self-organization to manifest
  • Work with peers and people in higher-authorized roles to create & then continuously maintain the conditions for high performance and continuous improvement
  • Be diplomatic and adept in communicating as needed, up and down the organization
  • Work within and contribute to an enterprise-wide community of practice
  • Encourage a culture of facilitation

These are full-time positions. This is a ground-floor opportunity to facilitate, full-time for a living. You’ll work in an Agile environment where periodic, enterprise-wide Open Space gatherings are part of the plan. Knowledge of the software side of things is important, yet less important than your grasp of Open Agile Adoption ( sociology and related topics.

If you have solid facilitation experience, and

  • are seeking a great full-time job in facilitation, and
  • have more than a clue about Agile software development, and
  • live near (or are willing to relocate to) northern Maryland, then:

….please contact me by email with “Maryland Jobs” in the subject line.

Reach me via

Self-Organization is Self-Management


Self organization is self management.

This means the reverse is true: “self management is self organization.”

What is management?

To manage is to direct and control. Inside software development teams, management includes directing and controlling decisions that effect the the team. Let’s set aside that important point for now. For now, let’s discuss the nature of management as it pertains to the software teams you are advising…

…Management is a function, not a role. Repeat: management is a function performed by the team, not performed a single person in a role. Not a person. Not a “manager-person.”

Management is a function, and an essential one. IT’S NOT GOING AWAY. Management is actually more alive then ever before. The difference, for purely Agile teams, is that management is an essential function, rather than an essential role.

So: when you hear “self organization”, replace that with “self management.”


Agile Coaching Lessons:

[<–Previous Lesson]    [Next Lesson–>]

[Table of Contents]




If you find value in these essays and find yourself curiously drawn to them, consider investigating OpenSpace Agility, and/or  following me on Twitter and/or joining the OpenSpace Agility group on Facebook






Positioning Is Signaling


If you think people are not paying attention to how you move, where you position, where you sit, where you are looking, where you are standing, etc….you are missing some very fundamental information that can help you be much more effective. Your choices of dress, postures, positioning and seating choices during meeting facilitation has everything to do with how you are signaling… in authority terms.

As it turns out, most people are quite adept at picking up signals without thinking about it. Especially signals about authorization.

And in Agile coaching, authority dynamics are the name of the game.

In the previous lesson I explained to you that must deflect any and all projections of authority from the teams you are advising.

Presumably you understand that. The question now is: how are you going to signal that you are not an authority figure?

Here is a very specific way you can signal a complete lack of authority: sit as close to the door as possible, with your back to the door. In all cases, avoid the head of table. Avoid seats that are deep in the room, facing the door. Why avoid these seats?

First, do so because that is where authority sits. And you are not authority in this organization. If you play the authority-figure, you are killing repeat KILLING any chance the team has to self-organize. (This is explained in the next lesson.)

Second, if you occupy any of those seats, you miss a wonderful chance to see who chooses to occupy them. By leaving them empty, you can see what develops. You can see who considers themselves to be authority in this social space.

Third, and most importantly, you can now easily get eye contact with the authority in the room. You are after all working for them- why wouldn’t you want to check in frequently with some eye contact?

Agile Coaching Lessons:

[<–Previous Lesson]    [Next Lesson–>]

[Table of Contents]



If you find value in these essays and find yourself curiously drawn to them, consider investigating OpenSpace Agility, and/or  following me on Twitter and/or joining the OpenSpace Agility group on Facebook











Signal That You Have No Authority


If you are an Agile coach, it is essential that you signal to anyone and everyone (inside the client org) that you have no authority. Period. Teams automatically project authority on you, and it is essential that you not only refuse to accept it, but also that you immediately reflect it back to the team that is offering it to you.


For this to work. two things must be true:



  • Formally authorized authority figures in the org must be willing to grant authority to teams to make decisions within clearly defined guardrails. They must signal this continuously. And mean it.
  • You yourself must be able to resist any and all attempts by the team to draft you into the role of authority-figure. Otherwise you have “no shot” at encouraging them to self-organize, which is in essence the act of self-management.


  • Formally authorized leaders must signal that teams are free to make real decisions within well defined “guardrails”.
  • You yourself must resist being attracted to any and all projections of authority by the team.

Do you see why?


Agile Coaching Lessons:

[Next Lesson–>]

[Table of Contents]



If you find value in these essays and find yourself curiously drawn to them, consider investigating OpenSpace Agility, and/or  following me on Twitter and/or joining the OpenSpace Agility group on Facebook




The Agile Imposition Revisited

Here are some verbatim statements from actual Agile Manifesto signatories, about the dangers and futility of imposing Agile practices on teams without their consent: 






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




“… imposing agile methods introduces a conflict with the values and principles that underlie agile methods.”
-Martin Fowler




“…I’d rather have a team work in a non-agile manner they chose themselves than have my favorite agile practices imposed upon them.”
-Martin Fowler




“…You know as well as I do that if the team really doesn’t want to use a methodology, IT WON’T WORK. (emphasis added.) Let them make their own assessment.” -Jeff Sutherland and co-authors, POWER OF SCRUM book, page 31 (page 37 in earlier versions)




“…[A leader’s] responsibility is to make clear to the team that THEY should be in control of their own work processes, and show them how to do that.” -POWER OF SCRUM book, page 31 (page 37 in earlier versions)




“…So I hope I’ve made clear that imposing agile methods is a very red flag. ”-Martin Fowler, Agile Manifesto signatory. Written 2006, the “Agile Imposition” blog post, Martin Fowler




These are protective warnings from Agile Manifesto signatories. These warning continue to be largely ignored by the Agile coaching community as a whole.



For good measure, and to add strong support for the story I am telling, here are some additional quotes from genuine thought leaders in community-building, organizational development and management science:



“Transformation occurs through choice, not mandate. Invitation is the call to create an alternative future. What is the invitation we can make to support people to participate and own the relationships, tasks, and process that lead to success?”

-Peter Block: COMMUNITY: THE STRUCTURE OF BELONGING (Arguably one of the most brilliant thinkers of our time on organizations and organizational development.)





Transformations can’t be accomplished without others helping voluntarily, & people don’t help unless you engage them first.
-Geoffrey Moore, ZONE TO WIN. (Arguably one of the greatest management minds of our time.)





Those in favor of push, coercion and top-down authoritative imposition of Agile practices on teams can’t say anything in defense that makes any sense.



The fact is that imposition makes no sense whatsoever if you are optimizing on genuine transformations over mere transactions.



I  mean, Martin Fowler is saying as much in those quotes. Who wants to take the other side of his argument?

Answer: NO ONE. 

Yet PUSH and IMPOSITION remains the de facto standard in “enterprise Agile adoptions” today !

What gives here?


Simplicity Is What Scales

I am sad.

I do not believe I am oversimplifying when I say that 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.

The fact that we as a community are willing to accept and approve of the idea that engaged people “don’t know how to self-organize” is something I am truly sad about.

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

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

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.

The Anxiety Iceberg

Let’s play a game. The object of the game is to initiate and obtain a rapid, lasting and positive change, across your entire organization, at scale, as fast as possible. OK?

Let’s call it “the culture game.”

To win the culture game, you have to see everything that is going on, just under the surface…

Let’s assume the org is a very large bank … with tens of thousands of employees…many of which have worked there for 10 years of more…let’s also assume the contemplated change is “an Agile adoption.”

…the main impediment to Agile adoption at this company? The legitimate concerns, worries and anxieties of everyone involved. Slamming “structure” changes into the organization triggers people with very legitimate worries, anxieties and fears.

These very legitimate worries, anxieties and fears (repeat: very legitimate worries, anxieties and fears) exist just under the surface, and represent about 90% of ALL the challenges and impediments to your Agile adoption.

There is lots of scientific proof that triggered, fearful people do not learn very quickly.

If at all!

Agile is about generating adaptability through learning.

Fear just shuts that learning down.



But wait. Some of the triggered people are formally authorized leaders who run entire departments and divisions. People with some authority. With direct and indirect reports. What happens when these leaders are not really supporting the Agile “structure” changes?

Answer: They send very clear “anti-Agile, anti-change” signals to their direct reports, who receive the signal. Then the receiver also (quite rationally) fails to strongly support the new change initiative. These direct reports of the leader in turn then become senders. They send clear signals of “fear, uncertainty and doubt” about the Agile-change to their direct reports. It just cascades down the reporting structure.

At the start, just one leader had doubts. Now 80 people are “skeptical at best.”

Multiply that times dozens of leaders, in a large company, at scale. This is actually THE main problem.

But wait. Some very vocal Agile coaches suggest these leaders (and their direct reports) can “self-organize to another job.”

Really? Does that actually work?

Because the reality is: these now highly triggered, very worried people do not vacate. Far from it! The reality is that people at a job 10 years or more are very, VERY slow to vacate. They have, after all, spent years fine-tuning their situation at work. And they can and will outlast, outwit and outplay those who authoritatively slammed in the Agile “structure” change.

When this happens, we say “Agile failed.” What actually failed was an attempt to force a process change on people– the leaders and the teams– without their consent.

And people want to be free.

The mandated approach can work. For it to work, lots and lots of people have to quit.

This usually takes many years. By then, the Agile coaches have come and gone: just like the Agile adoption itself.

Sound familiar?


Mandates create impediments hidden under the surface.

These “iceberg impediments” torpedo the very best of intentions for positive change in your company.


A Faster and More Lasting Solution- the OPEN Approach

The best way to bring process-change into an organization is to frame it as an experiment to be inspected … and invite people into the process of experimentation and inspection. That is, actually implement Agile in an empirical, inspectable, emergent, highly adaptive Agile way.

Leadership sets direction– and invites people to play. Leadership also sets the context with leadership storytelling and other intentional signaling behaviors that support the approach.

This is the fast-track to a rapid and lasting Agile adoption. Engage people. The people you already have! If people sense they can actually help author the new story, and be a character in the new story, there is no “buy in” …. because there is no need for persuasion. The people are not “bought in” …. instead, they are “LOCATED IN” … the new story. The Agile adoption story is THEIR story.

The Open Space meeting format can scale to thousands of people. We use this meeting format inside a wider method called Open Agile Adoption. It gets great results. It frames the experience as experiments— with inspections. And adjustments. There is no force-feeding of a mandate, and nothing is set in stone. It starts and ends in Open Space with a period of experimentation in between. Everything is inspected and the enterprise then adapts.

The Agile Manifesto is the single constraint- any practice can be used as long as it supports the Manifesto principles.

Pushed people are triggered people. Invited people are not. Invited people are free, pushed people are not. Invited people feel that the story of the org is unfolding, and that they are helping to write it, and that they are free. This generates absolutely tremendous levels of human engagement, the very fuel of a rapid and lasting Agile adoption.



Most of your biggest Agile adoption challenges are below the surface.

An open and inviting approach is the way to address these challenges, and neutralize them. Convert that anxiety from a bug to a feature. A double-positive, using one simple yet profound leadership move.

For handling any kind of enterprise-wide change initiative, you can use Prime/OS. For handling your Agile adoption, you can use Open Agile adoption, which is built on top of Prime/OS. Both are listed below.

Both of these tools will help you completely take the steam out of the very legitimate worries and fears that your people have.

This is done by “opening space” for everyone to express themselves, get in the game, and help write the story. And be a character in the emerging story.


Related Links:

Open Agile Adoption- based on Prime/OS (link)

Prime/OS- technology for culture change in organizations (link)

Video testimonials (link)

Telling Management What It Wants to Hear (link)














Open Agile Adoption Simplified

Here is Open Agile Adoption (OAA) in summary form: it’s not complicated….





  • Formally authorized leadership defines a 90-day period of time (minimum) for “authorized experimentation” with various Agile practices. Formally authorized leadership invites everyone in the organization to do this. The intent is to ENGAGE everyone.
  • It starts with an “all hands” (Open Space) meeting. This is a 100% opt-in meeting. The Open Space meeting format creates ENGAGEMENT. Everyone is invited. Everyone— in all affected business units and everyone– at all authorization levels, from high to low–  are invited. As a result, there is a huge mixing of people & ideas.
  • At that 1st Open Space, in the closing circle, everyone learns that there will be another meeting just like this one….in 90 days. Everyone learns that the organization is serious about inspecting results and making adjustments.
  • After the first Open Space, teams “suspend disbelief.”
  • After the first Open Space, teams “act as if.”
  • After the first Open Space, teams “pretend these practices can work.”
  • After the first Open Space, teams understand they are authorized ..and they then commit to experiments. They enter a period of “committed experimentation.”
  • The teams experiment with using any practice that aligns with the Agile Manifesto: the 4 values and 12 principles. This is the single constraint. There are no other constraints. This is a firm constraint- if an experimental practice obviously offends the spirit of the Manifesto it is out of bounds. If a practice does not align with the Manifesto, it is not a valid practice to play with during this 90-day period.
  • Other than this single constraint and the 90 days, there is no prescription of practices. Teams find practices that work– within the boundary of the Manifesto.
  • The emphasis is on learning…learning reinforced by formally authorized leaders. The emphasis is on learning what agile practices are and how to use them in a way that fits the organization’s mission, current position, and context.
  • Ideally, the formally authorized leadership team also experiments with Agile practices, like:  short daily meetings, iterations and retrospectives. This sends all the right signals. This tells a coherent leadership story.
  • After the 90 days are up, that period of experimentation ends— in Open Space. This “all hands”, 100% opt-in meeting is a look-back AND a look-ahead. One chapter ends- a new one begins.
  • The previous chapter is closed— and a new chapter of experimentation is opened. By that 2nd meeting, teams have unanimous agreement on what is working well, and how they want to work. And they start noticing what has to change.
  • A massively high volume of  self-organization occurs up and down the organization. The entire organizations begins a shift- a shift AWAY FROM mediocrity and TOWARDS excellence via continuous improvement.
  • Huge progress across the entire (invited) group is the result.

It’s really very simple. It scales. It’s not complicated.

Self-management (self-organization) at massive scale is deeply mysterious.

Creating the conditions for it to take place is not !!


Related Links:

Open Agile Adoption Home Page (link)













Is Mandated Agile a Reckless Gamble?

Placing a bet is not necessarily gambling.

Gambling is the betting of money at unfavorable odds.

Wagering is the betting of money at favorable odds.


The History of Agile Adoptions

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. (This was written in 2014….)

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.

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 Open Agile Adoption assumes 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.


Related Links:

Open Agile Adoption (link)

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)

Telling Them What They Want to Hear (link)

People, Then Practices (link)


Open Space Proceedings

Are you running a public conference with Open Space?

Are you looking to produce a great proceedings document?

Then, this post is for you.


Open Space Proceedings

Open Space proceedings in public Agile conference events do not … repeat,  do not.. have to be lame.

If you have attended a public Open Space event inside an Agile conference, you know exactly what I am talking about. The proceedings are often weak, hard to read, just kind of thrown together….or even non-existent.

Most public Agile conferences that have Open Space do not produce proceedings at all!

In 2011 in Boston, Agile Boston (see link below) did an event called Agile Day 2011. We had some speakers in the morning and did an Open Space meeting in the afternoon. For the Open Space segment in the afternoon, we created some innovations around the creation of Proceedings.

The method we developed is now known as the Agile Boston method. It is simple. It produces great proceedings. There’s a link at the end of this post, to a sample Proceedings document produced using this method.


Screen Shot 2014-11-07 at 6.19.08 PM



  • We delivered a document with hundreds of pages, just THREE HOURS after the event ended. Before people were done with dinner  that night, they had a link to the 90MB Proceedings PDF in their In-Box.
  • Every single session’s report from the Open Space was in the document
  • The text for each session was searchable. You could search your own name and find the sessions you attended. You could search ANY word or name you were looking for.
  • Every flip-chart artifact created in each session was there, as a JPG, in the PDF.
  • We included the slides from every single speaker in the AM
  • We included the pre-conference web pages, describing the event
  • We included information from all the Sponsors

Usually, a copy, or image is made of the messy handwritten report from the session, and that just gets thrown into the proceedings. Maybe! And it’s not searchable.

The reality is that with Agile conferences, you are lucky if you get even this. Because normally, there are no proceedings at all coming out of Open Space events convened inside public Agile conferences.

Take a look at the Proceedings document we produced. You might be wondering how we were able to deliver this just THREE HOURS after the event. Everyone who attended the event received a document that had all the slides from all the speakers, a full description of the event, pictures from the event….and the Open Space proceedings….with searchable text…all in one neat package.

If you like the results, send me an email and I’ll gladly explain to you how we did this. There’s a few tricks. Other than that, it’s simple. Any conference producer using the Open Space meeting format can make proceedings this good.

The PDF doc is 90MB, and takes some time to download. After it downloads, skip to the last, bottom third of the document to see the proceedings from the Open Space. (The first 1/2 of the document contains sponsor info, speakers slides, and the conference description.)


Related Links:

Agile Boston (link)

Agile Day 2011 (link)

Agile Day 2011 Proceedings (90MB PDF, link)