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)

 

***

 

 

 

 

 

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

***

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

***

 

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

***

 

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.

***

 

 

 

 

 

 

 

Culture Technology Wants To Be Free

Culture technology wants to be free.

Quick, answer this question: what kind of world are we building? An open, flexible, free-to-innovate world, OR…a closed, rigid world where just a few people can slow down or even STOP innovation… cold…with restrictive licensing?

Listen up…

Triads as described by Dave Logan in the book TRIBAL LEADERSHIP is a micro-culture design.

Scrum as described by Jeff Sutherland & Ken Schwaber is a culture design for teams.

Sociocracy as described in the book WE THE PEOPLE by John Buck is a culture design for large groups of people.

“The Core” from Jim and Michele McCarthy are a set of 11 commitments and 11 key interactions- a culture design for teams of up to 10 people. 

These culture designs are games– social games with goals, rules, roles and feedback loops. These are social systems designs.

Here is a quote to consider:

The field of system dynamics is leading to the new profession of enterprise designer. Methods now exist for designing the structure and policies of human systems so that the systems will better serve the people within them. Several decades of progress in system dynamics point to a new kind of management education. Such a future education will train a new kind of manager for the future. I anticipate future management schools devoted to “enterprise design.” Such business schools would train “enterprise designers.”…just as successful aircraft are possible only through skilled designers, so in the future will successful corporations, countries and social systems be possible through enterprise designers. Enterprise designers will be able to reduce the number of mistakes in the structure and policies of social institutions. -Jay Forrester, December 15, 1988, Sevilla Spain

 

 

Here is another:

In response to the demands of software, various high tech development disciplines have been articulated and “packaged up.” We have created several seminal management “movements” (such as Agile, Scrum, XP, etc.). These movements represent the birth of culture engineering and are primitive compared to what will soon follow. -Jim McCarthy, September 2012, CULTUREcon Boston

 

 

In my book THE CULTURE GAME, I explain how culture is a game.

Games can be and are designed.

If a culture is a game, it can be designed, just LIKE a game.

The current pace of change in business and society is unrelenting.  To rapidly IDENTIFY and rationally RESPOND to change, we must re-invent continuously. We must design new ways of organizing. We must INVENT new structures that are responsive to change.

And therefore, the time has come for the big shift: the shift into a new era of design…the era of social system design. An era where we routinely create, refine and re-create ever-more effective ways of working.

 

The Golden Age

The massive changes in society we are experiencing today are being created and amplified by software technology. Software is the dominant influence now: it is the engine of relentless change.

Because of this, we are on the threshold of a golden age,  a new era where social system design has suddenly become VERY important. For businesses, the implementation of good designs that serve the people who populate them is now a huge competitive advantage.

The various skills and disciplines from computer software (analysis, design, code, implementation, testing and maintenance, the use of patterns, refactoring and the like) are being ported to this new discipline. This is beginning to give rise to a new movement…a movement whose goal is to design and implement not computer systems but social systems… social systems designs that serve the people who populate them, instead of the other way around.

What can slow this movement?

Licensing.

What can accelerate this movement?

Licensing.

There’s an alarming trend in culture design. Some individuals and organizations are marketing social system designs while attempting to lock up their designs through licensing.

This is the OPPOSITE of what is needed now.

For example, anything published under the Creative Commons “Atribution-NonCommercial-NoDerivatives” license prevents those who build on it from selling or distributing those innovations.  This is a serious impediment to innovation at a time when the need for innovative culture design is accelerating. This license is bad for innovation. That why Creative Commons says plainly:

“This is not a Free Culture license.”

Jim and Michele McCarthy led the way by example, in 1999 by publishing The Core Protocols, their “social IP”, under the GNU-GPL license. Under the terms of this license, the The Core are published with two key features:

  • First: if you make a work derived from a GPL-licensed work, you must make it available on the same terms.
  • Second: if you distribute your derivation, you must make the “source code” that it is based upon available to absolutely everyone you distribute your derivation to.

These features of the GPL license encourage innovation at a time when we are on the verge of a new era: a Golden Age of culture design. Lack of attribution is also very big problem solved by open source licensing: people who do good work need to be recognized as the author of it, because that encourages them to do more of the same.

If your work is easily co-opted without considerate attribution, and an attendant increase in your reputation, why bother?

Open source licensing for culture designs is THE solution. The alternative- locking up “social IP” with restrictive licensing– PREVENTS others from distributing and profiting from innovation in the social sciences.

In one extreme case, an “integral” entrepreneur marketing a work derived from the work of others attempted to protect that derivation with a USA patent.

The USA patent was not awarded.

If it was, anyone that tried to build on that work would have to pay the patent holder a royalty!

That “integral” entrepreneur is now publishing a social system design called “holacracy” under one of the most restrictive licenses ever– the so-called “Creative Commons “Attribution-NonCommercial-NoDerivatives” license which prevents those who build on the design from selling or distributing any derivative works.

This license impedes innovation!!

Moral of story: Some Creative Commons licenses impede innovation, and don’t take my word for it- Creative Commons also says so. The so-called “Creative Commons “Attribution-NonCommercial-NoDerivatives” license DOES NOT encourage innovation. This is NOT an open source license.

What the world needs now is social intellectual property that is published under licensing terms that promote— instead of attempting to lock up– and prevent– innovation. With true open source licensing, innovators publish their works with intent to promote innovation. Truly open source licenses contain provisions that not only honor the originator, but also see to it that the originator’s ideas and work are ported into the future, attached to the innovations of others who build on the originators work.

Do you have a culture design? Consider publishing it under the Creative Commons Attribution Share-Alike (CC-BY-SA-40) license. This IS an open source license!

The nasty Creative Commons “Attribution-NonCommercial-NoDerivatives 3.0 (the one that the “holacracy constitution” is published under)  is NOT an open source license. Far from it! You cannot distribute ANY of your innovations on that work. You cannot recoup your valuable time and effort by commercializing your innovation.

This license IMPEDES innovation.

 

 

What kind of world are we building? An open, flexible, free-to-innovate world, with a commons, OR…a closed, rigid world with NO COMMONS where a few people can slow down or even STOP innovation… with restrictive licensing?

Social technology must be free to build on, derive from, and innovate. Otherwise, we’ll go backwards 30 years and kill an emerging golden age in sociocultural system design & engineering.

Culture technology wants to be free.

 

Related Links: Culture Technology

Triads from David Logan (link)

Scrum from Jeff Sutherland and Ken Schwaber (link)

The Core from Jim and Michele McCarthy (link)

Sociocracy from The Sociocracy Group (link)

 

Related Links: Licenses and Licensing

The nasty Creative Commons “Attribution-NonCommercial-NoDerivatives” license, a license that actually discourages innovation in culture design. Note: The so-called “holacracy constitution” is published under this license! (link)

The Creative Commons Attribution 4.0 International (CC BY 4.0) license, a license that promotes innovation in Culture Design. (link)

The GNU-GPL, a license that promotes innovation in Culture Design. (link)

***

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The Mandate of Holacracy at Zappos

(Published on: March 04, 2014)

In case you have not heard, Zappos is rolling out a defined authority distribution scheme called “holacracy”.

The way everyone works will change. Every single employee will be forced to comply with a set of rules they had no part in creating.

Under this new set of rules, the people who work at Zappos must submit to (and are in fact compelled to participate in) the company-wide change. There is no “opt-out” possible, except to quit.

The change is a change in the way authority is distributed. This change is effecting every single employee. There is no escape.

Tony Hsieh is the CEO of Zappos. He wrote the book DELIVERING HAPPINESS. In that book, in the Appendix (page 233) he describes a “Happiness Framework” which states that people need to feel control and belonging (“connectedness”) to feel good and be happy. I totally agree.

And that’s why, unlike so many others, I am predicting some very major problems with the widely celebrated rollout of this new process change at Zappos…unless something changes quick.

Mandating a process change is a recipe for disaster. As a management consultant who makes a living helping organizations improve, I have seen it firsthand, working with lots of executive and teams inside nearly 100 organizations since 2007. My book THE CULTURE GAME tells many of these stories, and concludes: engagement is the name of the game.

Engagement drives everything, and mandates kill engagement. End of story.

The mandate reduces feelings of control, as the new way of working is forced on you without any regard to what you want, what you think, or what you feel.

This creates disengagement.

Next, the mandate comes from “on high”, from “higher ups”, and the decision is one you have no part in whatsoever.  Not participating in the decision generates very reduced feelings of belonging. No one wants to play a game that they have no part in creating. Good games have opt-in participation. Mandates don’t.

This mandate from authority creates disengagement and eventually, the very negative feeling of resentment.

These feelings of disengagement and resentment work against the process change. The people that stay on are unenthusiastic…they murmur, and drag their feet. Instead of engaged, enthusiastic people, the result is disengaged, unenthusiastic, resentful people.

Many of these people will be unable to name their feelings at first; they just know that something ain’t right.

Mandating process change is a bad idea because it makes people unhappy when their feelings of perceived control and a perceived sense of belonging are greatly diminished.

The other problem is the fact that the people working there are selected for “culture fit” with the 10 Core Values of Zappos. How does this new system of organizing support those 10 core values? This remains a very open question… and one that many employees are probably already asking.

Maybe it will work perfectly. A more likely scenario is:

  • Many employees feeling a low sense of control and belonging will eventually seek new jobs,
  • Zappos will hire new people to replace them, and
  • The entire org will be in a state of dissonance with substantial employee turnover for some time to come.

It does not have to be this way, and there is a very simple solution to this very big problem.

Here it is:

OpenSpaceAgility.com

 

About the Author: I am Daniel Mezick. I am a management consultant and expert on culture and employee engagement.  I am the author of THE CULTURE GAME and other books. Reach me here, at 203 915 7248 or email: dan [at] newtechusa [dot] net.

Whatever you do, don’t follow me…don’t follow anyone…as explained quite clearly, in this 45-second video: https://www.youtube.com/watch?v=jVygqjyS4CA

***

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Task Mapping: Defining the “How”

Guest post by Adam Kowal

Hey Scrum Master – I know you’ve got a wonderfully groomed backlog.  Great job!  You may even have a predictable velocity.  Super!  The team has moved the right amount of product backlog into the sprint backlog and you’re ready to go. Right?  Not so fast.

You still need the self-managed agile team to assign tasks and hours to each of the stories, and “oh boy” engineers, UX, QA and Ops folks love nothing more than sitting around a room watching someone perform software gymnastics in the form of data entry.

What if there was a better and more engaging way to complete this step in the agile process?

As we implemented Agile at Intuit QuickBase we were presented with the same challenge.  As a Scrum Master I wanted the team to be fully engaged and openly discussing the “right” tasks to complete each story and assign a fast and loose time estimate.  I also wanted them to feel ownership and control over the tasks.  But – I also didn’t want to waste their time by forcing them to watch me enter the data into the “tool” real time.  With those guidelines in mind we created the “Task Mapping” exercise.

Task Mapping is quite simple and logical.  To start off – the entire meeting takes place on the white board and is completely unencumbered by software.

Step 1:  Agree to the sprint duration and the number of “work hours” in a week (write this anywhere on the white board). 

Then create a grid with the story ids you’ll be tasking in the far left column and the names of the team members in each of the columns to the right until you run out of team member names.  Above each name write the number zero.  The zero represents how much time each engineer has been assigned to the sprint so far…when you start…everyone is at zero.

 

Screen Shot 2014-03-03 at 8.05.31 AM

Step 2:  Now review the story again quickly asking if anyone has questions before you begin.  At this point, you should start timing the conversation. 

Then explain to the team that for each story they’ll need to Screen Shot 2014-03-03 at 8.05.43 AMwork together “out-loud” defining the tasks needed to complete the story.  A good facilitator can come in handy here to keep the meeting orderly, but not limiting people’s ability to express themselves.  Each person is then responsible for tracking what task and how many hours they will personally need to spend on each story.  To do this, we created the “ticket” system using sticky notes.  When a team member creates their task they need to quickly write down the story id, their name, the task and a rough estimate on the        number of hours.  Some team members may have 1 task, some may have 10 and some may have 0.  In any case – each team member walks up to the board and places their sticky in the correct location on the grid corresponding with their name and the story id.  Remember – each team member is ONLY posting tasks on the board that they are personally signing up to complete.  (Special Note:  Unless you force it, people will forget to account for meeting time related to the sprint.  Please remind team members to include tasks like “meet to review the doc” or “meet to make decision on ABC”. )   Also – once all the tasks are accounted for stop the timer.  Keep a record of how long it took the team to arrive at a completed list of tasks for each story and use this as a baseline to improve against going forward (think “continual improvement”)

Step 3: Once the team member posts their sticky on the wall they’ll need to mark the number of hours they just committed to at the top of the grid. 

Each team member is accountable for keep a running tally of the number of hours they are committing to so as not to exceed the number of “real” hours available in a sprint.  If someone is getting overloaded you’ll do the team a favor spreading that work out across people who are not as booked.

Screen Shot 2014-03-03 at 8.05.58 AM

 

 

Step 4: Rinse and Repeat

 

Two stories down looks like this:

Screen Shot 2014-03-03 at 8.06.17 AM

 

 

 

 

Five stories down looks like this:

Screen Shot 2014-03-03 at 8.06.30 AM

 

 

 

 

 

 

Step 5: DONE. Task Mapping Complete

DONE looks like this:

Screen Shot 2014-03-03 at 8.06.39 AM

 

 

 

 

 

 

 

One more thing: If you have not yet done so, this is the perfect time to enlist the help of the PO to construct a succinct “sprint goal” and ensure everyone understands it. Write this at the top of the board in your scrum room (if you have one).  Then have each team member peel all the sticky notes they wrote from the board.  Give them a “time boxed” period to enter the tasks into your Agile software tool of choice.  And you’re off!

A huge advantage of this method is that it is a highly interactive ceremony.  It gets the team comfortable with the upcoming effort, a shared understanding of each other’s roles and provides a sense of ownership as they’ve written their own work orders!  Moreover – it is a fantastic team building exercise as they work in unison to complete the grid together.   I look at it like “the tribe has spoken and this is the work they are going to do”.

 

***