Open Agile Adoption | New Technology Solutions

August 3, 2014

Telling Me What I Want to Hear

The whole idea that you can bring radical process changes into an organization without considering the people who do the work is an idea promoted by many “Agile enablement firms.”

According to these highly authoritative “Agile transformation” consultants, all you have to do is completely authorize their well-documented process-change plan, and write a big check. The now-authorized consultants will do the rest. Click. Done. Well-intentioned leaders in large corporations are usually very happy to believe this, as it is often exactly what they hope to hear.

If they ask about employee engagement, the well-intentioned org leaders are told that employee engagement in the new plan is not a necessary precondition for success. What a relief! The employees and eventually the entire culture will eventually do what the new plan (the new “structure”) encourages them to do.

While it is true that new rules encourage new behaviors, this is typically not immediately true, since people are involved … and people like to be free.

New rules imply some kind of game. And every good game has opt-in participation. The process change amounts to a management mandate. A large number of participants refuse to play, and “opt out.”

But wait. These highly “triggered”, justifiably resistant, opted-out employees do not “up and leave.” Far from it! They do not vacate your organization for a long, long time. Instead, they simply disengage. They “check out.” It shows up as passive behavior that directly opposes the very-well-intentioned process change.

And this high level of disengagement virtually guarantees that the change isn’t rapid, and that it doesn’t last.

Management-mandated process change actually perpetuates the original problem: lower and lower levels of employee engagement.

The solution is very simple. Instead of pushing a process change, use “pull” instead. Use invitation, instead of that nasty mandate.

Open Agile Adoption (OAA) is one way to use invitation and “pull” to begin the process…the process of installing genuine and lasting business agility across your entire enterprise.

May 9, 2014

The Law of Two Feet

You might be hearing a lot about “The Law Of Two Feet.” The idea comes from Open Space, a meeting format composed by Harrison Owen and friends.

The Law is very simple:

“If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet, go someplace else.”

The Law of Two Feet speaks to the idea of OPT IN PARTICIPATION. This idea has applicability far beyond Open Space meetings. The reality is that we all are “opting in” or “opting out” of various choices and opportunities, every single hour of every single day. You can get out of bed, or not. You can help a friend get something done, or not. You can quit your job, or not. You can choose this job, or that one.

You can continue to examine this blog post, or opt-out. So simple right?

My friend and the originator of Open Space is Harrison Owen. He often says that the Law of Two Feet is “always active”, meaning that it is applicable everywhere, not just inside the Open Space meeting format. As an example. consider your meetings at work. Almost all the time, you are REQUIRED to attend these meetings. But what if you could opt-out?

The reality is, when “you are you are neither learning nor contributing” you do in fact CHECK OUT mentally and psychologically. Your body is there– your head is not. This is DISENGAGEMENT. It’s death to you, and your meetings, and your organization. So the Law Of Two Feet actually is active, even if you “must” be there. You use the “virtual Law Of Two Feet”– by DIS engaging your mind, and leaving your body in the room. Your body is present, your head is not. Disengagement. “Embodied disengagement” if you will. The virtual Law of Two Feet.

Remember– the Law Of Two Feet is always active. People want to be free.

So. Imagine if you could opt-out and ELECT to not attend. Imagine if every meeting was optional to attend. Imagine that…

…now, with every meeting optional….are you still attending every meeting? Probably not. Why? Because, in your view, it is unlikely you will either learn much or contribute much.

The new workplace authorizes you to allocate your time and attention to the activities that can do the most good for your organization. The new workplace trusts you to do the right thing. The new workplace admits that the Law Of Two Feet is always active.

The new workplace admits that mandating and imposing attendance at meetings is dumb.

Mandating and imposing attendance (or any other activity) kills engagement. The remedy is INVITATION. Invite people to meetings, and make attendance optional. Engagement is what happens when the passionate, responsible people are all in the same space, focused on an issue that connects them.

And that is what the Law Of Two Feet (and the Open Space meeting format) is all about.

Related Links:

Open Space Explained (link)

The Problem With Mandated & Imposed Agile Adoptions (link)

Open Agile Adoption Explained (link)

Contact Me To Discuss The Law Of Two Feet (link)

April 26, 2014

Agile Adoptions, Open Space and control

There is a fellow named Ed Seykota. He innovates. He has 2 pairs of models: a pair for 1-to-1 relationships, and a pair for group & system level relationships. His models confirm and align with the philosophies and assumptions which form the foundation of Open Space:

· All systems are open

· All systems are self-organizing

The Models

(1) intimacy-centric and control-centric models for relationships:

In a control-centric relationship, the parties go for control. They use manipulation, force, threats, guilt, etc. to get each other to “behave” properly. In an intimacy-centric relationship, the parties go for connection. Every event becomes an opportunity to become closer and more intimate.

(2) causal and system models for dynamic behavior.

In the causal model, we have a cause and an effect. You flip the switch and the light goes on. In the system model, you have inter-relating elements that co-evolve as their effects on each other change. Some examples of systems are a thermostat that intends to keep the temperature in the room constant and a futures market that intends to find a price that balances supply, demand and other speculative interests. Politicians typically apply the causal model to economic situations so as to find a convenient “cause” that justifies expenditures on their pet projects.

Now, what is interesting & concerning (to me) is the way the so-called Agile institutions tacitly support the control-centric model for relationships and the causal model for dynamic behavior, in Agile adoptions. Throughout the world.

I am an Agile consultant. I choose to focus my attention on finding ways to reduce the number of coaching days, such that organizations can reach a state of self-sustaining, “freestanding” agility faster. And here is what I have discovered: to speed up the process of change, the people in the situation have to actually consent to the change. They must be willing. They must be choosing freely. High Performance in Agile adoptions is a function of opt-in willingness to proceed on the part of the people who actually do the work.

Sound familiar?

Typical Agile adoptions today are implemented as imposed and mandated process change. By “management”. By “formally authorized leadership.” This is the control-centric model for relationships.

Typical Agile adoptions today are implemented as imposed, mandated process change. The assumption is that if we can just “make them do this or that”, we can “cause” improvement in the organization. This is the causal model for system behavior.

This is a very serious problem in our world, and one that the so-called Agile institutions are just not addressing. The Agile Alliance, for example, has various policy statements. Yet the Agile Alliance has no policy statement whatsoever regarding the harmful, mandated imposition of Agile practices. This amounts to a rubber-stamping of the control-centric, causal, imposed-Agile “status quo” that we see in the world today.

Open Space can help with Agile adoptions, but only if the Facilitator is unwilling to implement the control-centric model for relationships, and only if the Facilitator is unwilling to implement the causal model for social-system behavior. Well-intentioned management often just does not see it that way.

I’m concerned that we are entering a period where, absent any clear position statement on mandated-Agile from the so-called Agile institutions, we can expect trouble in the way Open Space evolves in the Agile-adoption marketplace.

Let’s see what develops.

Daniel

Authorization in Self-Organizing Systems

I’m zooming in on authorization, because I notice that when coaching Agile adoptions, there is always this sticky “authority aspect” in just about any problems that need addressing. Authority always seems to be the central concern.

Like Harrison Owen [1], I believe that all systems are open and all systems are fundamentally self-organizing.

I also currently hold the following additional beliefs:

Self-organization in a social system (like a team) is actually the act of self-management. Management is a function, not a role. Manager-roles are obsolete, even as (self) management becomes more important than ever.
Self-management in a group is the act of distributing informal authority in real time. Authority is dynamically allocated (given and taken away) by the informal system in real-time. The informal system responds moment by moment to environmental change 1000 times faster that the best formal system. It is super-efficient. For this reason the “informal system” (the self-organizing universe) is superior in every way to formalized methods of authority distribution. The informal system wins every time. It’s “no contest.” Remembr: “All systems are self organizing”. There’s a REASON for that: Higher, better, superior performance.
All self-organization is self-management at the level of group.

This has serious implications for Agile adoptions. If the above is true, the following is strongly implied:

Allow teams to make decisions. The act of deciding requires authority distribution. This is self-organization.
If you routinely alter team composition, expect a rapid decrease in productivity as the propensity to self-organize is diminished. Making decisions for the team kills self-organization.
If you want more than the 25% improvement in whatever you are measuring, make sure you encourage genuine self-organization (dynamic authority distribution) inside your teams. Do this by encouraging decision-making. Note: Imposing Agile on teams routinely results in productivity gains from 15 to 25 percent. Self-organizing teams will get 3 or 4 times that. Imposing Agile practices on teams is not advised [2].
Never attempt to exercise authority from outside the team where team-level decisions are concerned. Let them decide. Otherwise you will reduce the propensity of the team to self-organize and this will result in a drop in productivity.
Don’t mandate the use of specific Agile practices, since this will kill the potential for genuine self-organization. Instead, create the best environment you can for teams to actively decide what practices are best for them, consistent with the Agile Manifesto [3].
Consider the use of Open Agile Adoption [4], which is set up to encourage self-organization by design

Related Links:

1/ Harrison Owen: TED talk in Self-Organizing systems. (link)

2/ The Agile Imposition. Essay. Martin Fowler. (link)

3/ The Agile Manifesto. Web page. (link)

4/ Open Agile Adoption Explained. Blog Post (link)

***

March 29, 2014

Push vs Pull in Agile Adoptions

Agile folks who claim advanced knowledge and know-how extol the virtue of “pull systems” like Kanban. The idea here is that pushing a load of work on teams is bad. Far better for teams to pull the next chunk of work, or work item. Scrum asks teams to “pull” in a group of work items that they think they can handle. Kanban goes further, asking that teams simply pull individual work items as they have capacity to do so.

The idea with a pull system is that the receiver initiates the pull. There is no push from a sender. The team “opts in” to pull work in based on their capacity to do that work.

Pull is a great idea right? Teams know what they can handle, so they “pull” in what they can handle. A superior idea for sure!

Pushing Agile Practices on Teams

If you believe workflow “pull” is superior to workflow “push” by management, you have a problem. And that problem is that most Agile adoptions are implemented as mandates. As impositions. As push.

If you approve of this, and you are a fan of “pull” systems for workflow, you are in conflict with yourself. You are actively promoting “pull” for workflow even as you are promoting a coercive “push” of Agile practices on teams.

This makes no sense whatsoever.

Martin Fowler, an original signatory of the Agile Manifesto, said as much in 2006 in an essay entitled “The Agile Imposition“.

Here are some quotes from that essay:

“Imposing a process on a team is completely opposed to the principles of agile software, and has been since its inception.”

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

“Not just should a team choose their own process, the team should be control of how that process evolves.”

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

“So… I hope I’ve made clear that imposing agile methods is a very red flag.”

The answer of course is to invite the teams to give Agile a try. At issue is how to set it up so the teams can opt-in to experimenting with Agile practices.

OpenSpace Agility is a method for engaging everyone: executives, managers, the teams. Everyone. It expects something from everyone involved. It creates engagement, which is the very fuel of a rapid and lasting Agile adoption. It works, and it is fun.

You can learn more here:

Open Space Agility Explained

***

March 29, 2014

Executives Can’t Make Agile Work

In the olden days, executives in suits never heard of “agile” or “Scrum”. It was new back then. The “agile” and the “Scrum” were brought in by developers. In a very grassroots kind of way. Teams wanted to improve, so they tried it on for size. Agile. Scrum.

They were “in”, they were engaged, they were experimenting. These developers opted-in to try Scrum. They gave their consent to investigate it.

Teams gave their consent. And that’s a big part of why it actually worked…

Mandated Collaboration

In the present day, Agile is a mainstream idea. Now formally authorized leadership- management- is leading the charge. And here is where it gets interesting.

Interesting, because now Agile is being pushed on teams, without their consent. By authority. Professional “agile coaches” seal the fate of the teams, by acting as management’s proxy, force-feeding training and “inflicting help” on teams, teams that never, ever consented… because no one asked them in the 1st place.

This is a very serious problem.We seem to looking the other way in the Agile community, like this actually doesn’t matter.

It matters. A lot. You can have a transaction with your “agile enablement” vendor, but you cannot have a transformation in your organization if the people who do the work are not engaged. And engagement does not come from mandating or imposing Agile practices, from the top-down, on teams.

It comes from people choosing for themselves.

Engagement is the secret sauce.

Prescriptive mandates kill engagement.

What To Do?

The obvious thing to do is engage everyone- the executives AND the people who do the work- EVERYONE. Now, some Agile coaches will just tell you this is just not necessary. That all we need is the executives. That you can just push Agile on the teams, and everything will be OK. That everything will be fine. That “pushing” Agile on teams without their consent will work.

It won’t…and it doesn’t. Martin Fowler, an original signatory of the Agile Manifesto, said as much in 2006 in an essay entitled “The Agile Imposition“.

Here are some quotes from that essay:

“Imposing a process on a team is completely opposed to the principles of agile software, and has been since its inception.”

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

“Not just should a team choose their own process, the team should be control of how that process evolves.”

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

“So… I hope I’ve made clear that imposing agile methods is a very red flag.”

Not convinced yet? Gallup says disengagement is costing employers BILLIONS every year:

…about one in eight workers — roughly 180 million employees in the countries studied — are psychologically committed to their jobs and likely to be making positive contributions to their organizations. (source link)

Employers can reclaim this lost productivity by engaging people. That ain’t gonna happen with a mandate or imposition of Agile practices.

Still not convinced?

There is a mound of data now coming out of MIT that now completely invalidates the idea that you can make a top-down “push” work. The MIT data proves you cannot get lasting organizational change without getting engagement from the people being affected. This data proves that pushing process change on teams that are not engaged simply does not work.

Open Agile Adoption is a method for engaging everyone. It expects something from everyone involved. It creates engagement, which is the very fuel of a rapid and lasting Agile adoption. It works.

You can learn more here:

Open Agile Adoption Explained

20 Minute Video of Daniel Mezick Explaining Open Agile Adoption on INFOQ

Open Agile Adoption Videos

Open Agile Adoption Articles

Open Agile Adoption Blog Posts

***

March 26, 2014

A Very Poor Bet: The Mandate of Agile Practices

Fact #1: Almost 100% of Agile adoptions are implemented as mandates. Ask almost anyone who has been party to a “rollout” of Agile in their organization. Ask them if it was presented as a mandate or not.

If you doubt this 100% figure, ask around. Read this post:

Imposing Agile Practices: Does It Actually Work?

The imposition of Agile practices is the one constant in most Agile adoptions in most organizations and has been for at least 7 years, around the time the “agile coach” role appeared on the scene. Right about the time Agile started getting popular! Right about the time Agile Manifesto signatory Martin Fowler warned against “the Agile Imposition”….

Fact #2: The general consensus is that Agile “sticks” in about 15% of the organizations where it is attempted. Ask any pro Agile coach and they will tell you, if they are honest. This is close to the actual number.

Fact #3: The definition of insanity is doing the same thing over and over and expecting different results.

We keep doing that. Something has to give.

Martin Fowler, a Manifesto signatory in 2001, warned against this. In 2006! Here is the link:

The Agile Imposition

Imposing a process on a team is completely opposed to the principles of agile software, and has been since its inception. -Martin Fowler

Fact #4: Replacing that mandate with a sincere invitation, from authority, to experiment and learn…that seems to work. I have been experimenting for awhile with a new approach to Agile adoption, one that actually seems to work. It’s called Open Agile Adoption. You can learn more here:

Open Agile Adoption Explained

OpenAgileAdoption.com

***

March 24, 2014

Imposing Agile Practices: Does It Actually Work?

The OpenSpace Agility approach has created some questions. Some of these questions, collected from around the web, appear below. Some of the questions are very specific and very interesting (I think.) I’ve included them here. These particular questions are harvested from recent interactions with professional Agile coaches who are active on Twitter.

Related Links:

OpenSpace Agility Explained

20 Minute Video of Daniel Mezick Explaining OpenSpace Agility Agile on INFOQ

OpenSpace Agility Client-Interview Videos

The Questions:

Q. Guide them through change, but not impose. What if they don’t want to change?

A. Respect the no. Let the org…the self-organizing system…figure out how to address this problem.

Q. Would you let a developer you were paying personally choose their own approach?

A. This is a non-starter kind of question. The typical context of an Agile adoption is an existing organization with an existing IT department or development team group.

Q. Are there any constraints you’d be willing to impose or mandate?

A. OSA tolerates the “imposition” of an Agile direction, even though that can be a problem. The Agile direction has to be in service to something- something besides Agile itself.

An Agile direction, articulated by formally authorized leadership.

Agile: in service to what?

Q. So you are willing to impose constraints?

A. The idea is to open up a conversation about how Agile ideas can help. We invite the folks to play with the various Agile practices. Iterations, Retros, and so on. We explain to them that they can try any practices they like which do not offend the majority of the Agile Manifesto’s 4 values and 12 principles. We encourage them to know the Manifesto well, and find practices that align with those values and principles.

Practices change, principles don’t. We explain that and turn them loose into a time of “authorized experimentation.”

Q. Deliver working software every two weeks?

A. Iterations are an Agile idea that aligns with the Manifesto: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” Let (aka “authorize”) the teams to experiment with that!

Q. Work in a cross functional team?

A. Once again, allow experimentation. Do not “mandate collaboration. “

Q. Plan in functional slices of the product?

A. Allow experimentation. Do not mandate behaviors. Instead, ask them to align everything they do to the Manifesto.

Q. Those are constraints. They are also agile process. But we can’t say that we are mandating agile?

A. The output from an experiment is learning. In OSA we invite experimentation. We invite learning.

We make the distinction in OSA between the naming of an Agile direction, and the mandating of specific practices. Direction-setting is an important activity for formally authorized leadership. In OSA we stop short of mandating specific practices. Instead we invite the teams to experiment. Martin Fowler in 2006 writes the important essay “The Agile Imposition”. This is essential reading for anyone considering mandates of Agile practices. Quoting that essay: “So I hope I’ve made clear that imposing agile methods is a very red flag.”

Q. I’m starting to wonder if there is a nuance here that I am missing. This makes NO sense to me.

A. The nuance is: human engagement powers successful process change. Disengagement can slow down and eventually ruin your process-change plans. Therefore, engagement is essential. OSA is all about creating engagement on the premise that human engagement is absolutely essential.

Q. Are we really talking about an approach or disposition? We invite rather than mandate? Like non-violent comm.?

A. Invitation is respectful and can create engagement. Coercion and mandates are fundamentally disrespectful, and can create disengagement.

Q. “…I would place constraints on team such as I want X feature in 2 week Quality MUST be high. Outcome focused. “ What’s the difference between that and mandating agile?

A. The difference in the OpenSpace Agility approach is this: we place the people inside a period of time when the primary outcome is learning, through experimentation. The period of experimentation is actually a designed experience. It is designed as a rite of passage. See also http://en.wikipedia.org/wiki/Rite_of_passage

Q. Is it the social implications of agile we don’t want to mandate? Not the process aspects?

A. OSA is a sociological approach based on opt-in engagement. Remember, the premise is that human engagement is essential. Jeff Sutherland has data on Scrum (see http://assets.scrumfoundation.com/downloads/2/scrumpapers.pdf?1285932052) saying teams can double productivity and double again. A central hypothesis of OSA is that higher productivity is correlated with higher levels of human engagement.

Q. Like, I won’t mandate you trust someone? Or be vulnerable in a retrospective? Or create safety for someone?

A. I’m sorry if you think you believe that this kind of thinking and action can be forced on someone by some kind of external authority. I have never seen it done.

Q. I won’t mandate you like each other, or work as a high performing team?

A. High performance is mostly a function of self-organization. Self-organization is a goal of OSA. We create the conditions for self-organization to emerge. We do not pretend we can manufacture or mandate it. In OSA we create the conditions and the conditions always include a legitimate (opt out with no sanctions) invitation.

Q. I’d suggest there is no way to mandate that stuff anyway. You can only mandate behavior or process compliance.

A. In a prison, you can mandate behavior compliance and process compliance. Are workplaces prisons? I guess some kind of are…maybe.

Harrison Owen is fond of saying that the Law of 2 Feet is always active—that is, people are exercising their options, including the option to disengage. A central premise of OSA is that you cannot actually mandate behavior or process compliance, because people “check out” and disengage on you instead of playing your mandatory-to-play game. Good games have opt-in participation. That requires the consent of each player.

Q. Like, my desired result is you work in a team & deliver a working tested increment of product every two weeks?

A. Yes, this is much closer to the idea of OSA: we name the issues we are facing , we suggest some experiments with Agile practices. We inspect the experiment. The constraint is “use any practice that supports and is not obviously in conflict with the 4 values and 12 principles of the Agile Manifesto.”

Q. Again, we must be arguing some semantic nuance I don’t understand

A. Again, the central idea is very simple: Engagement is essential. Great teams, great products and great organizations exhibit very high levels of human engagement. Engagement is essential. Mandates tend to dampen engagement while invitations (such as an invitation to attend an Open Space meeting) tend to increase it. Engagement is essential.

Q. If you are willing to mandate team based iterative and incremental delivery, how is that not mandating agile?

A. First, learn to differentiate between mandating an Agile direction and mandating specific Agile practices. The constraint is is “use any practice that supports and is not obviously in conflict with the 4 values and 12 principles of the Agile Manifesto.” From there, common sense governs. Quote from Martin Fowler, Agile Manifesto signatory: Imposing Agile methods on a team is in conflict with the principles of Agile and have been since inception.” See also http://newtechusa.net/agile/people-then-practices/ and http://martinfowler.com/bliki/AgileImposition.html

Q. (say) they are failing now doing ad-hoc or waterfall. What if they want to do an 18 month waterfall process? Can I ask them not to do that?

A. See the above question. In OSA we start and end in Open Space. In between we experiment with practices, using the Agile Manifesto for guidance. Make sense? Quote: “An important consequence of these values and principles is that a team should choose its own process – one that suits the people and context in which they work. Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.” – Martin Fowler, “The Agile Imposition”, see http://martinfowler.com/bliki/AgileImposition.html

Q. Okay, you’re willing to mandate producing value every two weeks?

A. No. There is no mandate, there is an invitation to experiment and create learning. Again, the Agile Manifesto is the guide: Is the idea of producing value every two weeks consistent with the Manifesto? Yes, it is. The difference in OSA is that we are inviting people to play a game, we are not mandating this or that.

Q. What kind of result then can I mandate? Valuable software on some regular interval?

A. Why mandate a specific outcome like iterative delivery when you know you need the human engagement of the team? In OSA we teach the Manifesto and invite the teams to try an experiment, for example experimenting with Scrum. The difference between the mandate and the invitation is huge. The mandate is experienced as command-control and coercion, both of which reduce engagement. The invite is experienced as a respectful request to engage in a game. Every good game has opt-in participation. See also http://newtechusa.net/agile/how-games-deliver-happiness-learning/

Q. What if they want to do an 18 month waterfall process? Can I ask them not to do that?

A. In OSA, we “explain the why” of the Agile experiment, in an invite to attend an Open Space meeting. That invite is an invite to explore a theme, a theme like “Agile: In Service To What?” or “What Do We Want Agile to SOLVE?” We then schedule another Open Space about 12 weeks out. In between, we authorize experimentation with Agile, defined as using practices that support the Manifesto principles. Is an 18-month waterfall process consistent with that? No. And in this scenario, the folks themselves will not go that way, because an 18-month waterfall would not be in alignment with the Manifesto principles.

Q. Can we mandate that people show up and do work or do I have to invite them and coach them on that 2?

A. This is a silly question.

Q. I am desperately trying to understand the POV here. I am trying to understand that nuance. What is the difference between mandating agile and mandating some of the other outcomes that folks have suggested? Maybe you can do a post for me or something, because honestly, I am really, really confused.

A. A central premise of OSA is that engagement is essential. Mandates reduce the sense of control and belonging. This kills engagement. It is really, REALLY this simple.

Q. Is the nuance I am missing that people have to be invited to participate, but if they don’t I can coach them out?

A. The nuance you are missing is that the very people who are allergic to your mandate are often the people who have the very best ideas on how to make Agile work inside their team and inside their company. Inviting all the people to experiment and then inspect the results has a way of getting people in. Those who do not get in receive feedback from peers on what is working and what is not. A goal of OSA is to get everyone in.

Q. Is the nuance I’m missing that we have to take a disposition of invitation, we have to lead, coach, and help people along…

A. Yes, a premise of OSA is that engagement is essential and that mandates can kill engagement. Therefore, we replace that disengaging mandate with an engaging invitation to play a game: the game of experimenting with Agile practices to see if they actually work.

Q. …we all agree that they can’t do waterfall, not produce incremental value, allow defects to carry forward, else they leave?

A. We issue an invitation to attend a themed Open Space meeting. After that we play with practices and see if they serve. Quote: “Not just should a team choose their own process, the team should be control of how that process evolves.” – Martin Fowler, The Agile Imposition. See http://martinfowler.com/bliki/AgileImposition.html

Q. I’m not pushing a side, i am trying to understand and no one can explain to me what it means not to mandate.

A. To not mandate means to invite. To be inviting. To replace the coercive command-control mandate with an invitation to play a game of experimentation which will be inspected. This tends to engage people. The premise is that engagement is essential.

Q. Dan explicitly asserted that you cannot mandate an agile transformation. We have done this many times with great success.

A. I love success stories and I am sure you have many. Let’s run the numbers. Since 2001, the year of the Agile Manifesto, that’s about about 13 years, I’m guessing there have been over 10,000 attempts at successful adoption of Agile. (That’s probably low). I’m also guessing that 99% of these have been implemented as mandates of Agile practices. Right? Is that a fair and reasonable assumption? By that measure, the 500 or more legitimate success stories are actually outliers! Those 500 success stories represent about 5% of the sample, meaning there is a 95% lack of success is this hypothetical example.

Say there were actually 1500 verifiable success stories out there, about the mandate of Agile practices. In the language of wagering, that means you’d still be about a “6 to 1 dog” (with odds about 6 to 1 against you) when making that bet.

There’s loads of experience data. Where in that data is the overwhelmingly positive evidence that mandating Agile practices actually works? There is a lot of data from organizations like Gallup which shows that engagement is correlated with things that are really good, like employee retention and employee morale and better products.

Question: Where is the evidence that these mandates of Agile practices are actually increasing employee engagement?

Q. So I am trying to understand what he means. There is some nuance I am clearly missing. Trying to understand what that is.

A. The nuance is very simple. People have to be willing. You can create indirect opposition, resentment and so on by forcing agile practices on people without their consent. The clear solution is to replace the mandate of practices with a genuine invitation to experiment with them.

Q. I think you can mandate going to agile, but then have to win the hearts and minds of the people involved.

A. Almost. You can win the hearts and minds of the people involved. Mandates create feeling associated with a loss of control and belonging. In his book DELIVERING HAPPINESS, Zappos CEO Tony Hsieh explains how the senses of control and of belonging are essential for human happiness. See page Appendix A page 233. When people lose a sense of control, they may tip into the state of Learned Helplessness. Martin Seligman did experiments that exposed this dynamic. It stems from a lack of perceived control. Is this what we want to start happening inside our Agile adoption programs? See also: http://psychology.about.com/od/lindex/f/earned-helplessness.htm and http://youarenotsosmart.com/2009/11/11/learned-helplessness/

Q. But if they choose not to participate, and that is their choice, they may have to find employment elsewhere.

A. This is true. However, in OSA, the adoption is emergent and adaptive—not prefabricated and forced via a mandate or coercion. This is a very big difference from the mandated approach. In the OSA approach, the adoption has emergence baked in from the beginning. Everyone is invited and those who opt-in are co-creating it. Everyone has a decent sense of control and strong sense of belonging. The group senses things together, along with the person who no longer fits. Authority does not tell the person they are fired. Instead, emergent order creates a shared sense of agreement about reality by and between the members. When the new culture of learning takes root, the unengaged person and the tribe both realize what is no longer working.

Q. I’m not suggesting we enslave people, but if I decide to run my company using an agile approach that is not debatable.

A. As the owner, if a command-control approach works for you, great. Keep doing that.

Q. I will teach, coach, mentor, help them understand, be kind and gentle along the way and give them time to learn.

A. That is a good idea, consistent with the Open Agile Adoption approach.

Q. But if there is no option but to do agile or leave, that is fundamentally a mandate.

A. In OSA, formally authorized leadership works from a belief that people actually want to do great work, and will do great work if you create the conditions for it to emerge. Essential elements of these conditions include a sense of control and a sense of belonging. Invitations to engage can encourage both. The sense of control and belonging show up when people are actively making decisions about the customization and tailoring of practices they are choosing with others in the group. The co-created agreements associate with a sense of control and membership.

Q. Maybe as you suggested the word mandate carries some baggage for people that I don’t have. Like calling people resources.

A. What it is called does not matter: if you reduce the sense of control and sense of belonging below a certain level, or lower, the participants will stop playing the game and check out. When that happens, it’s “game over” and the Agile adoption is dead in the water.

Q. Ah, so mandate implies one-way communication. That is insightful… I didn’t interpret the word that way.

A. Yes, and an invitation is a two-way communication. The OSA approach replaces mandates (which can feel coercive) with an invitation (which can feel inclusive.)

Q. Okay, so that is insightful for me too. I think agile is a way of working, but it doesn’t require an agile mindset.

A. Yes, and if there is no Agile mindset at the beginning, that probably means the folks at least have to be consenting to what is happening. If there is no mindset and there and no consent, what is there? Answer: compliance, resentment, learned helplessness. See also http://en.wikipedia.org/wiki/Learned_helplessness#Summary

Q. If I act with agility, the feeling of agility will follow.

A. Maybe. If you are willing. If you are experimenting. If you have actively consented to play the game. If you have AGREED to “act as if”, to “suspend disbelief”, to “pretend this might work” for a little while.

Otherwise, maybe not. The feeling of agility is probably not going to happen if you are feeling compelled, coerced or forced. If you are feeling a low sense of control and a lower sense of belonging.

Where there is no consent, there is often a general feeling that something just ain’t right. At first, you may have difficulty being able to name and identify these feelings.

Q. I don’t believe that it is an effective strategy to transform 6000 people through cultural indoctrination

A. Open Agile Adoption is not a cultural indoctrination program. There are NO attempts at “persuasion” to get “buy-in” from teams, in OSA. This is because genuine engagement is deeper than that.

The OSA method is a way to introduce process-change through a consent-based approach that uses invitation and the use of Open Space to create an experience. The OSA experience is designed to encourage self-organization at scale. It creates the conditions for a rapid and lasting Agile adoption.

Q. I believe you have to get the systems in place to enable agility and that will allow the mindset of agility to follow.

A. A core premise of OpenSpace Agility is that people want to be part of creating the solution (sense of belonging) and want to consent to that (sense of control). When you force Agile practices, there is no experimentation. There is no belonging as there is no shared-agreement. There is simply a forced march to collaboration. A forced march to “mandated collaboration”. This is a terrible idea.

Q. I do believe [OpenSpace Agility] is very contextually sensitive, not impossible to do it the other [mandated] way.

A. Almost every big change in almost every organization is context-sensitive. Right?
A core premise of OpenSpace Agility is that engagement is absolutely essential. Another core premise is that a mandate of practices can quickly reduce levels of engagement by reducing the senses of control and belonging. If this is true, then OpenSpace Agility is widely applicable. It is applicable in almost any enterprise that wants a rapid and lasting Agile adoption.

Q. Dan just happened to say that my way doesn’t work and there were no examples of it working. I disagreed and offered to introduce him.

A. I say that mandates reduce engagement, and that engagement is essential for a rapid and lasting Agile adoption. If your way is to mandate, I am doubtful it creates rapid and lasting Agile adoptions.

I am sure you have some success stories in your sample. However, the sample size across the entire Agile experience is at least 13 years of mostly-mandated Agile adoptions, worldwide! That might be 10,000 or more attempts at mandated Agile adoption. So, if Agile-practice mandates are a good bet, and actually work, we’d by now be able to point with pride to thousands upon thousands of verifiable and unmitigated success stories. Right?

Thirteen years and thousands of attempts to force Agile practices. Where are the thousands upon thousands of verifiable success stories?

Why is it a crime to ask this question?

Where is the “mound of data” with verifiable results that strongly support the mandate of Agile practices?

Q. The only thing I wanted to assert here is that both ways can work.

A. If Approach-A works 15 time out of 100, and Approach-B works 85 times per 100 trials, both can be said to work. At issue is the expectation. One, Approach-A, has very negative expectation, we can expect on balance to fail (LOSE MONEY) most of the time. The other, Approach-B, has very positive expectation; we can expect on balance to succeed (WIN MONEY) almost every time. Both can be said to work some of the time. They have widely different “expected value.”

The mandated approach might work maybe 15 times per 100 attempts. Are those actually good numbers? Are we actually happy with that? Today, we are collecting data on a NEW approach. An approach that focuses on engagement, on the premise that human engagement is essential from the very beginning.

Summary

The OSA approach assumes human engagement is essential. It replaces the mandate with the invitation. It is an approach that attempts to improve the odds for success in getting a rapid and lasting Agile adoption, by acknowledging the reality of imposed mandates and replacing those 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.

***

February 26, 2014

Agile Coaching Values Explained

In a previous post, we outlined 4 Agile Coaching values and 8 related and supporting principles.

Mandated practices may prevent a rapid and lasting Agile adoption, by reducing feelings of control and belonging in the very people who do the work.

Embedded coaches present 5 days a week often prevent teams from taking up their authority to lead in the creation of their own Agile practices and processes.

Here is a bit more detail on the 4 values and 8 principles, for your consideration. You are invited to consider this detail and how it might apply to your own Agile work as a coach, client, or team member.

These Agile coaching values were authored by the following professional coaches in the Greater Boston area (listed alphabetical by last name):

4 Agile Coaching Values

Creating Independence over generating billing

Coaches are often drafted into the role of “authority in chief” and with that comes the risk of substantial client dependence. Coaches value creating client independence and client self-sufficiency over all other considerations.

Championing Learning over avoiding risk

Continuous learning is destabilizing to existing culture. Questioning long-help assumptions can be risky in an organization that values stability over learning. Agile coaches value the building of a capacity of continuous learning in the orgs they serve. This includes encouraging the client to identify, expect and manage the many risks of genuine organizational learning

Building Relationships over building transactions

Agile coaching is a very lucrative profession. Coaches have creditors like everyone else. The development of relationship with the people in the client organization must take precedence over financial considerations if the coaching is to be effective and lasting.

Inviting Participation over assigning responsibility

Assigning responsibility without authority is a recipe for failure in any attempted adoption of Agile methods. Instead of a command and a prescription, the people closest to the work must play a part in designing the solution. Agile coaches encourage formally authorized leaders to avoid mandating participation in prescribed Agile practices. Agile coaches encourage leadership to invite the people who do the work to participate directly in the design and implementation of any move to Agile and Agile practices.

8 Agile Coaching Principles

We use these Principles to guide our work with clients:

Voluntary engagement of everyone involved in organizational change is an essential requirement for success.

Mandating an Agile practice is the same as mandating collaboration. This is a contradiction of terms and is also contrary to the letter and spirit of the Agile Manifesto values and principles

Coaching every single day in an organization creates a serious risk of client dependency and is to be avoided, consistent with common sense and good judgement with respect to client needs.

Dependency on the Agile coach is harmful to coach and client and is to be avoided at all costs. Occupying the Scrum Master role of Scrum for an indefinite period of time is not coaching and reduces the learning capacity of the client organization.

Organizations are responsible for their own learning. Arms-length, time-boxed working agreements between clients and coaches are essential.

Coaches and clients work best together when they agree to a time-boxed structure for executing on coaching. Teams and entire organizations take more responsibility for learning when they know the teacher is not available for an indefinite period of time.

Coaches must look for every opportunity to increase the learning of the organization as a whole, with strong intent to vacate or otherwise evolve the current coaching role as soon as possible.

Coaches and clients work best together when it is understood that the coach’s role will change and that the intent of the coach is to vacate as soon as possible. The promise of Agile is served when client organizations can routinely reach a state of self-sustaining, “freestanding” agility.

Coaching requires the willingness to identify any cultural impediments to continuous improvement, and to communicate these to the people in the organization who have the authority to address them.

Agile is Trojan horse for bringing in a substantial change in culture. Coaches have an obligation to see to it that leaders occupying roles highly authorized roles commit to using their authority to remove cultural impediments to rapid and lasting agility.

The primary task of a coach is to help improve the effective results and working lives of the people employed in the organizations they serve.

Agile practices create engagement and good results– in part by putting decision-making authority in the hands of the people who do the work. Agile coaches encourage leaders to make this happen.

The ability of an organization to respond to change is the primary measure of progress.

Agile coaches are in the business of teaching and encouraging practices that lead to adaptability and the ability to handle rapid change. Agile coaches teach entire organizations how to learn, and adapt—without the ongoing need for the presence an external authority named ‘coach’

Leaders in an organization must continuously signal positive encouragement, and create safe space for others to think and learn, if positive culture change is to be lasting and effective.

Agile coaches are obligated to teach organizational leaders how to best create an environment that is open and safe for experimentation and the learning that comes from that.

***

February 26, 2014

Agile Coaching Values

Agile Coaches are familiar with the patterns of naive and vulnerable client organizations that are new to Agile. In our view, Agile Coaching professionals have an obligation to help clients understand what is best for them. In the beginning this is seldom the case. The Agile coach is obligated to do the right thing. This always includes encouraging and helping the client take 100% responsibility for their own learning.

This usually means the coach must routinely and politely decline opportunities to play a larger, more authoritative role.

Being there, 5 days a week, full time, for 3 months or more can be lucrative and hard to resist. As coaching professionals, we do our best (and live up to our potential) by serving the learning of the client organization first. This includes challenging the client org to take 100% responsibility to reach a self-sustaining state of Agility, without the need for the 5-days-a-week presence of the external coach.

These Agile Coaching values and principles listed below are a good and solid basis for guiding coach-client relationships and interactions. These values and principles are listed in the familiar ‘agile manifesto‘ format.

The content- these values and principles– are optimized on the continuous, progressive and ongoing organizational learning of the coached organization.

In serving our clients, we have come to value:

Creating Independence over generating billing
Championing Learning over avoiding risk
Building Relationships over building transactions
Inviting Participation over assigning responsibility

We use these Principles to guide our work with clients:

Voluntary engagement of everyone involved in organizational change is an essential requirement for success.

Coaching every single day in an organization creates a serious risk of client dependency and is to be avoided, consistent with common sense and good judgement with respect to client needs.

Organizations are responsible for their own learning. Arms-length, time-boxed working agreements between clients and coaches are essential.

Coaches must look for every opportunity to increase the learning of the organization as a whole, with strong intent to vacate or otherwise evolve the current coaching role as soon as possible.

Coaching requires the willingness to identify any cultural impediments to continuous improvement, and to communicate these to the people in the organization who have the authority to address them.

The primary task of a coach is to help improve the effective results and working lives of the people employed in the organizations they serve.

The ability of an organization to respond to change is the primary measure of progress.

Leaders in an organization must continuously signal positive encouragement, and create safe space for others to think and learn, if positive culture change is to be lasting and effective.

***

These Agile coaching values were authored by the following professional coaches in the Greater Boston area (listed alphabetical by last name):

Pat Arcady, Freestanding Agility (www.freestandingagility.com)

Dan LeFebvre, Freestanding Agility (www.freestandingagility.com)

Daniel Mezick, New Technology Solutions Inc (www.DanielMezick.com)

Frank Saucier, Freestanding Agility (www.freestandingagility.com)