OK enough is enough. There’s a thread about IMPOSING AGILE PRACTICES on Twitter that’s grown a lot. Ron Jeffries, Liz Keogh, Eric Willeke and several dozen others are speaking their minds about the issue of when it’s OK (or not) to impose Agile practices on teams regardless of what they think about it.  There is a lot of confusion about the topic.

My position is clear: with very few exceptions, inviting is superior in every conceivable way to imposition for the vast majority of use cases that fall under the bell curve of typical situations.

Yes, there are a few edge cases, such as when the company will fail in 6 months if something is not done. Or when all of the best talent has already vacated for obvious reasons. Those are outliers, edge cases. Maybe 10 or 15% of the total set of all use cases for so-called “Agile transformation.” As I have said before, a stopped clock is right 2 minutes a day.  That’s a tiny minority of the 1440 minutes availoable, and it doesn’t mean the clock ever actually worked. Yes, I too can cite edge-case examples of when the brushing of teeth is not advised. Does that imply that the brushing of teeth in the main does not work, or is not advised? Does it mean that not brushing teeth is as good a practice as brushing teeth daily? No, and no.

So there you have it: my position, on the matter of The Agile Imposition. My Tweets pretty much sum up how I feel and you can see those here: (link)

Martin Fowler warned about this in 2006 and again recently, in 2018.

Is anyone listening?

To be clear, I have done my very best to instigate a conversation about this. And now we have one. It’s curious to watch what’s happening. Several of the participants chide me for various sins: self-selecting data, engaging in hyperbole, yelling, or being full of sh**. But these same participants remain mysteriously drawn to and remain in the conversation. You can see it all here. Scroll it to view:  (link)

I am grateful to each and every one that is participating. Some have asked me what I want, asking me to suggest a next step. Others are curious what the call to action actually is. Well, here it is. But first the definitions:



Now you know my position on this, so there’s nothing further for me to say. But lots of others seem to be OK with imposing Agile practices; that is, forcing those practices regardless of any lack of willingness on the part of those affected. From my point of view, you DO need to ask what the level of willingness is, without any threat of sanctions for the “wrong answer,” if you are to have any idea of what that level of willingness actually is. I have found that inviting everyone in one big room, after opening a little space for people to actually  speak their mind,  is usually the best way to ask people and find out.

Others disagree, as usual.

Here are some of the comments:








Now folks are asking for what’s next here. Asking what the call to action is. What the next step is. Asking where we are going with this. For example:






OK; here it is: Speak Your Mind. Document a statement of position, for or against. Be counted.

If you care whatsoever about this topic, here is your chance. This is your invitation to say something about where YOU stand in this issue of pushing Agile practices on teams without respect to what they want, what they think or what they feel about THAT.


For, or against, imposing.

For, or against,  INVITING.

Some general ground rules: suggestions

1. Use any medium you like. Your blog. Social media. Podcast. Youtube video. Get creative.

2. Try to keep it to less than 800 words if you can; people have short attention spans these days.

3. Post the link on Twitter using the hashtag #InviteOrImpose

When you do that, you’ll be telling the world exactly where you stand on this. Or not, depending on how you tell the tale.

You’re invited. The idea is to see who actually cares at all. Do you care? Let’s find out. Also, the idea to see where specific individuals in the #Agile space actually stand on this. Also, the idea is to engage in civil discourse about this topic.

The basic guidelines are the 1-2-3 listed above. Any medium. Less than 800 words of you can. Post to Twitter with the #InviteOrImpose hashtag.


Original Twitter thread: (link)

The Agile Industrial Complex: (link)

The Agile Imposition (link1) (link2) (link3)


The Agile Industrial Complex: People As Resources

Well. What a difference a day or two makes.

Over the summer of 2018, the following actually happened:

Ron Jeffries (Manifesto signatory) issued a protective warnings and protests about the forcing of Agile practices, and  The Agile Industrial Complex, in his public writing.

Martin Fowler called the Agile Industrial Complex “our first problem” and in that same essay he said “our challenge now is dealing with faux (fake) Agile.

And then he said:

“…the Agile Industrial Complex imposing methods upon people…is an absolute travesty.”

For the record, the word [travesty] is defined as “a false, absurd, or distorted representation of something” (as a noun) and “to represent in a false or distorted way.” (as a verb.)


You’d expect the rest of the “agile thought leaders” to weigh with an opinion on this big, huge issue, right?

Especially the loudest voices that are constantly seeking the spotlight.

But no. Not this time.

It’s strangely silent.

The crickets are chirping.

Can you see why?

Anyone party to “push” or anyone with friend$ in the “push” business are in a double-bind. If they come out for Push, they look idiotic in light of the Manifesto.

And if they say anything nice about opt-in participation, if they come down on the side of invitation, they risk alienating their friend$ in the industry who routinely provide lots of big-org consulting opportunities and deal flow.

So there it is.

The best strategy if you are for Push is…. to keep quiet.

To shut up.

And hope it all goes away.

Except it’s not.

In addition to Ron Jeffries and Martin Fowler, dozens of extremely experienced and very credible and very concerned Agile folks, people like Mark LevisonJon JorgensenMike Burrows. They just came out and said it.

They said it in print.

They said it from the conference keynote podium. And on social media:

  • The whole community is now driven by money.
  • The imposition of practices is a travesty.
  • Nothing good can come from forcing practices on teams.
    • Doing so is the exact OPPOSITE of what Agile is.
  • Forcing is fundamentally disrespectful of people.
    • It kills motivation and self-management, and creates disengagement and resentment.
  • And nothing good comes from that.

You can get an idea of what I am talking about by examining the REAL AGILE LEADERS HALL OF FAME link, at the end of this essay. That link contains the full story, and all the names.

And what’s notable is who is NOT on that list. All the big, loud, prominent voices are…missing in action. Nothing to say. No opinion whatsoever on the most pressing issue of our time.

Imagine THAT. This is the new version of “agile thought leadership.”

Let’s be clear:

Most all of the improvement from Agile comes from self-managed, self-organizing teams

Self-management is the self-management of decisions. If there is no change in who makes decisions and how decisions are made, there is no self-management of anything, and therefore no lasting “transformation” of anything at all. Any and all gains are temporary.

In this new default reality, in this fake-Agile  ‘reality distortion field’ , executives are told directly and indirectly that decision-making does not have to change to get a legitimate and lasting “Agile transformation.” That everything can stay the same. That employee engagement is not totally “not necessary.”

And it’s all very comforting.

And it’s just plain incorrect.

So…WRONG. On so many levels.

And a huge disservice to the executives who are supposedly being served an “Agile Transformation.”

In this strange new world of Agile, the “thought leaders,” the large consulting firms and the Agile institutions have exactly ZERO to say about the tolerance of imposition of practices on teams, even as the members of these teams are being fundamentally disrespected. The teams go to the web. They read about the Manifesto principles, and the “respect for people” pillar of Lean. And they know what’s going at their organization is…total bullshit.

In this strange new world of “Agile,” freedom is slavery.

Ignorance is strength.

People are resources.



Follow the money.



Related Links:

Ron Jeffries protesting the folly of forcing practices (link)

Martin Fowler warning on travesty of The Agile Industrial Complex (link)

THE REAL AGILE LEADERS HALL OF FAME: the real thought leaders emerge (link)

BEHOLD: The Agile Industrial Complex (link)


Get It In Writing

Everybody knows that a primary task of the Scrum Master is to remind everyone about the Scrum rules. This is all very nice. All very neat and tidy.
But how does this actually play out when there are boundary violations?
Answer: Not very well. Most organizations that implement Scrum do it poorly. Scrum is a game.
And all good games have rules. *Scrum* has rules.
So, let’s say you are a stakeholder that receives deliveries from a Scrum team. Let’s say that you violate a rule of Scrum– any rule– and I am the Scrum Master. If you never agreed to the rules of the game, how am I to hold you accountable to playing this game by the rules?
This problem plays out every single day in nearly every single Scrum implementation. Scrum is implemented; but they never agreed. BIG PROBLEM.
None of the people involved actually examined the Scrum Guide and accordingly, NONE OF THEM AGREED TO PLAY. Because not only did they NOT read the Scrum Guide, but even worse, no one asked them to AGREE to play by the rules.
In that scenario, the Scrum Master cannot (repeat) cannot be effective.
And the Scrum is going to be a total disaster.
So here is what you are going to do.
–You will print out dozens of copies of the Scrum Guide
–You will read it
–You will invite absolutely everyone and anyone affected by Scrum to READ IT
–If they are unwilling to read the Scrum Guide, you will treat that as an impediment to Scrum, and try something- anything- to resolve the issue
–You will invite everyone to accept the Scrum Guide as the DEFINITION of Scrum. This means that when anyone in the situation says the word “Scrum,” it means the thing described in the Scrum Guide.
–If they are unwilling to agree that the Scrum Guide is the DEFINITION of Scrum, you will also treat that as an impediment to Scrum, and try something- anything- to resolve that issue. Ask them what it takes to get them in. Listen intently. Do whatever it takes for them to get in– except negotiate away any part of the Scrum Guide.
–After they agree that the Scrum Guide is the definition of Scrum (a major achievement by the way,) you will THEN invite them to agree to honor it. For the executive: they will respect the decisions of the Product Owner. For the PO: they will agree to be accountable for every aspect of the Product Backlog. For the Team: they will agree to conduct the Daily Scrum every day. Etc. Etc. Etc.
It is only after these agreements are in place that the Scrum Master will be able to remind people about following the Scrum rules, and hold them accountable to that.
And it will be good.
If you are party to an implementation of Scrum, and you have not checked off as done the 3 things listed below, you have no one to blame but YOURSELF for the foolishness that is sure to follow.
So: Make sure you get these 3 outcomes. Make sure you can check them off…
[    ] Everyone affected by Scrum has read and examined the Scrum Guide
[    ] Everyone affected by Scrum agrees that when we say “Scrum” we mean the description found in the Scrum Guide
[    ] Everyone (Execs, Stakeholders, Team, PO, Scrum Master) agrees to play by the RULES of Scrum as described in the Scrum Guide.
None of this is going to be easy. All of this is essential.
But only if you are to be effective.
And so my guidance around this is very simple: get it in writing.
Because truth be told, you’ll be needing that later.


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







Ending In Open Space

(NOTE: This lesson assumes you understand the Open Space meeting format.)


At the 2016 AGILE ISRAEL conference event, I was honored with an invitation to keynote. Six hundred people in one room. Kind of scary…

….I asked for a show of hands: “…how many of you here have ever attended a meeting of at least one day, where the progress of the Agile transformation itself was inspected by everyone in the room?” About 40 hands went up.

Then I asked “…please keep those hands up. Next, how many of you have attended such a meeting, where absolutely everyone affected by the Agile transformation was invited, not just the ‘higher ups’ ?? ”

Thirty-four hands went down, leaving only 6 people remaining. In other words, in Israel, about 1% of all Agile adoptions are ever inspected by the-group-as-a-whole.

Is it smart to include and engage everyone in the overall process of changing?

Consider these fundamental aspects of Agility:

  • Empiricism
  • Experimentation
  • Iteration
  • Inspection
  • Adaptation
  • Pull
  • Self-management and self-organization


This kind of begs the question: how is it that we can successfully implementing Agile in an enterprise, without applying these Agile ideas to the enterprise transformation itself?

The answer of course is that we can’t actually be successful without taking an Agile approach to Agile transformation.


The very best way to get valid data on the progress and status of the Agile “transformation” is to invite everyone to inspect the progress.

A very excellent idea, and the one I am suggesting now, is to make sure you are periodically “ending in Open Space.”

In a previous lesson I told you to Start in Open Space and I gave you good reasons why. Now let’s discuss ending in Open Space.


If you get in the habit of “ending in Open Space,” the following good things are going to happen:

If the whole organization knows that an Open Space (“all hands”) meeting is going to happen in a few months, and that the whole Agile thing will be inspected there, by everyone, they will “suspend disbelief” and “act as if” and “pretend” the experiment with Agile practices could actually work. (If you are several years into your “transformation,” then the inspection is about your current state and the experiments you are doing. You are doing experiments- aren’t you?)

Because Open Space is an invitational (“opt in”) meeting, you’ll be able to see who attends and who is absent. This is very valuable data.

  • At the Closing Circle, you’ll be able to see who is really feeling passionate and responsible about the process. Many (if not most) of the people present at the Closing Circle are the very people who care the most about the success of the Agile transformation effort. These are the people who can and will propel the effort forward.
  • The Open Space meeting will generate a tremendous level of self-management and self-organization. Discussions in the meeting will provide rich detail on what impediments need to be removed at the enterprise level.
  • The Open Space “all hands” meeting provides a closure point for an “enterprise iteration of learning and progress.” Without that punctuation-point, the group can and will suffer from one.endless.experience.that.never.ends.

People are junkies for progress. So create a punctuation point. And an ending. An enterprise-wide iteration that begins and ends in Open Space.

An ending ends one thing, and starts another. Endings create beginning. And then we go again.

Iteration. Inspection. Adaptation.

At the enterprise level.

With everybody.


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

Only The Engaged Can Actively Self-Manage

The self-organization of teams is a tremendously misunderstood topic. The writing on it tends be inconsistent and yes, even incoherent at times. This brief lesson takes a swing at being both consistent and coherent.

Lessons 04, 05 and 06 gave you a basic understanding of some key concepts and the relationship between “self organizing teams,” self-management, and decision-making.

Every KPI (key performance indicator) that you are measuring is dependent on the level of self-management that the teams and the wider organization are exhibiting. No self-management, no KPI improvement. This is simple correlation and is not complicated.

You already know how to test for high levels of self-management from lessons 04, 05 and 06: just personally ask a few individuals from a team or group how they make decisions. If you get the same very consistent and coherent answer, you can be sure they are self-managing. This is because self-management is about managing decisions, not people.

Repeat: self-management is about managing decisions, not people.

This is all very nice. It all sounds so good. Doesn’t it? But wait: what are the common impediments to achieving self-management, and how do we remove these impediments?

The #1 Impediment to Self-Management

The top impediment to self-management in teams is a lack of engagement. If the team members do not care about what they are doing, self-management (and lasting KPI improvement) is NOT going to happen. There is no such thing as a “self managed team” without very high levels of engagement by and between the members. Pushing Agile practices on teams cannot help you here. Pushing practices on teams without their full and informed consent is not advised.

So how will we engage these potentially disengaged teams?  If the teams are not making decisions, or if most of the team’s decisions are made for them, you are going to have a very difficult time achieving self-management.

Teams need to be making decisions to stay engaged, and there’s no such thing as a self-managed team that is not engaged. In other words, “decision making by teams” and “self organization of teams”  are both intimately connected.

They are practically the same thing. One follows the other.

A primary way of generating a team-level decision is to invite the team to do something.

An invitation is a request for a decision.

Decisions are engaging. And only the engaged can self-manage. And self-management is where all the “continuous improvement” comes from.

Therefore, inviting is a necessary and essential tool of the trade in Agile coaching.


Can you see why?


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

Agile is a Game. Agree About The Rules

In the previous lesson, I taught you about how word definitions are agreements, and how agreements are essential to success with Agile. Once you get everyone involved to agree on the definitions for Agile and Scrum, you are in position to go all the way by seeking and obtaining everyone’s commitment to success with Agile. It’s all very simple but you have to go step-by-step and do all the steps just like I tell you.

So here is what you do: you already have everyone’s agreement that the Manifesto is the definition of Agile (2 pages) and the Scrum Guide (less than 20 pages) is the definition of Scrum. That is Step 1.

Step 2 is to go and ask (ASK) everyone involved to play by the rules of Scrum (which is a GAME by the way) for 6 or 7 iterations. If they are unwilling, ask (ASK) for them to agree to play by the rules of Scrum for 3 or 4 iterations. Or 2. Or ONE. Ask (ASK) for their agreement.

These are the roles you need to have very specific conversations with:

  • All the stakeholders
  • All the execs, directors, and managers
  • All the Product Owners
  • All the Scrum Masters
  • All of the Teams
  • Anyone else you can possibly think of

It is essential that you do this. Do NOT rush this Step and DO NOT skip it. Get it done. With each person in each role, explain clearly what is expected, what is permissible, and what is out of bounds. Clearly explain the boundaries of each role, and the specific tasks. Make sure everyone understands. Ask them to ask questions. Do not rush this.

It is best to scope the agreement to a specific period of time, like 7 or 8 iterations. This way, it is easier for everyone to commit. Making it temporary (and inspectable later) also teaches some core ideas about iteration, experimentation, inspection, adaptation, and so on.

Just go ahead and live these things out. That is your very clear message to them. Live it out. See how it feels. Give it a try, this Agile thing. For real. Tell them no one will get hurt, that you have led people through this many, many times. Because you have.


It is usually a very good idea (no joke) to GET IT IN WRITING as Step 3. After they signal they are OK agreeing to this. Get it in writing if you can. Make it very real. Make it kind of scary.

Now you are in position to really be successful. Here is why:

  1. There is a sense of community now– everyone shares in the same basic agreement. The agreement is about THE RULES OF THE GAME. Which everyone is about to play.
  2. There is clarity. Everyone is clear on roles and responsibilities. Or so it seems, for now (!!)
  3. You and the Scrum Masters you are teaching can now assert yourselves, strongly if necessary, by reminding executives, directors, managers, stakeholders, Product Owners, Scrum Masters, Teams and everyone else involved….about their commitment to the rules. About their commitment to their AGREEMENTS with you and everyone else.
  4. When the Teams start Scrumming, you can remind them that they AGREED to do a Daily Scrum Meeting.
  5. When the Teams start Scrumming, you can remind the executives that, per the Scrum Guide, they must signal and execute on real and deep respect for the decisions of Product Owners.
  6. When the Teams start Scrumming, you can remind stakeholders that the scope of work in a Sprint cannot be changed in an ad hoc way. Ever.

Now when it gets crazy, YOU CAN REMIND PEOPLE OF THEIR AGREEMENTS. This is Step 4. And because it is time-boxed with an end-date, you can very firmly remind them of how very reasonable the entire arrangement is.

The next Step is to coach everyone through the experience. This is Step 5.

The last Step is to inspect everything. Especially the great results everyone is getting.

Summing up:

  • Step 1 Get agreement on definition of Agile and Scrum
  • Step 2 Get agreement to play by the rules of Scrum (for teams that are doing Scrum)
  • Step 3 Get the agreement in writing
  • Step 4 Remind people about their commitments when the trouble starts
  • Step 5 Coach them through it. You have permission now. GO FOR IT
  • Step 6 Teach them how to inspect and adapt


The alternative– starting in some other way– is almost guaranteed to FAIL.

This procedure, in six Steps actually works.

Especially those FIRST THREE Steps.

Can you see why?


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

Definitions Are Agreements

Language is important, especially when everyone is being triggered by changes in the way authority is distributed. Agile “transformations” are no exception.

Also very important are agreements. Without agreements, nothing good can happen. So start your coaching by testing the willingness of the team(s) and the wider organization to make some agreements with itself. Agreements are commitments.

And all of this is very big deal, I assure you.

So here is what you do. You start by presenting the Agile Manifesto and explaining it. Use your imagination. Teach the 4 and the 12.

Once your audience receives this teaching, ask them to agree for say, the next N months (something reasonable for N, like “six) that THIS Agile Manifesto THING is the definition of Agile. That, when we discuss “Agile”, we are discussing “this.” That the definition of the word “Agile” when we use it….IS the Agile Manifesto. That when we say “Agile,”, THIS is what we mean. Those 4 values and 12 principles.

Then, so the same exact thing for the word “Scrum” and use the Scrum Guide as the definition of “Scrum.”

As a coach, you will quickly learn:

  • How much confusion there is in the organization about these fundamental terms;
  • How little (or how MUCH) the people in the organizations are actually willing to actually agree on;
  • How little willingness there actually is to execute on good Agile and good Scrum;
  • Who is “in” and who is “out.” Who is supporting, who is resisting. Very simple.

As you coach, always frame the use of these definitions as “temporary” and “just for now.” This way, you reduce the objections by being reasonable. By being kind. Be being a good teacher. A good leader. A reasonable person: it’s not FOREVER. Just for now, lets use these definitions. Let’s “agree” to them.

If anyone disagrees and absolutely cannot get in, ask them what has to change (what has to be TRUE that is not yet TRUE) for them to get in. Ask them what it will take to get them in. Work it out. Get them in.

Now, when you get everyone in, when everyone agrees to these two definitions, you have really achieved something: something very GREAT:

  • There is a shared agreement, and everyone is accountable to that agreement;
  • You now speak with much more clarity when you say the words “Agile” and “Scrum;”
  • You have set up the entire organization to be much more clear about what it says to itself;
  • You have helped them achieve an agreement ABOUT SOMETHING VERY IMPORTANT to success with Agile;
  • You have greatly expanded the “adjacent possible” for this organization’s transformation.

There is a method to your madness here. In the next step, you will invite them to play a game.

A very serious game. A game you can all win together. A cooperative game.


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

The PUSH of Agile Causes “Trance Formations”


Push-style “transformations” look good at first, and do not last long. What is actually going on there is this: TEMPORARY EFFECTS. It turns out that when you make a change in a workplace, like changing the brightness of lights for example, the productivity goes up temporarily and reverts back to the mean. It is not lasting. If you wait awhile and dim the lights down a little, same thing. Changes like this cause short-lived increases in productivity. When people are being observed as changes are being made, they temporarily change their behavior.

The cost of these effects is very real, however. And permanent (non-refundable) in nature.

What’s being sold as “Agile transformation” today are mostly short-run productivity increases that do not actually last. Temporary improvement. New procedures, new consultants, new teams, new practices, etc.

Observation. The short-run productivity increases from these temporary effects are all very misleading. They do not actually last; they are 100% temporary. There is no actual “transformation.” Furthermore, it is often highly prescriptive programs that produce these effects. When those highly prescriptive and authoritative (and expensive!) coaches vacate, the improvement goes with them. It’s all very temporary.

Starting with Lesson 4, I explained to you the dynamics of self-management. A little later on (in Lesson 14) I explained how making decisions triggers very high levels of engagement. And how engagement is where all the improvement actually comes from. All of these topics are related: decision-making, engagement, self management, and great results. One begets the other.

Engagement is the name of the game here, and you get it by inviting teams to make some decisions that affect their work. Scrum defines some decisions that only the teams are authorized to make. There’s a good reason for that.

If you are “helping” the team to make these decisions, you are discouraging self-management and self-organization. And this is where all the improvement (if any) is going to come from.

So stop doing that. You are generating disengagement and causing team members to “check out.”

You are creating “trance formations.



If you are party to the PUSH of Agile on teams without consent, you are part of the problem. You’re pushing Agile practices, and making most all the decisions for those who are affected. Or even worse, you are literally “looking the other way” while authority figures in the organization make decisions that the teams literally need to be making to stay engaged.

So stop that. And do these things, instead:

  1. Encourage executives and managers to refrain from making decisions for the teams that Scrum very clearly defines as belonging to those teams.
  2. And then, encourage teams to make the decisions that Scrum says are theirs (and theirs alone) to make.


And after a while, everything will start to improve. In a lasting way.

Because the teams are actually engaged in the difficult work of making decisions as a team.


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