Posted on

Tribal Leadership: Is It a Game?

 

The book TRIBAL LEADERSHIP lays out 5 stages of culture. The 5 stages are basically stories that people tell themselves…and others.

 

 

 

 

Here are the 5 progressive stories:

  • Life Sucks
  • My Life Sucks
  • I’m Great!
  • We’re Great!
  • Life is Great!

What I have come to realize is that the content of this cultural self-talk is related to games.

Games have 4 properties:

  • A goal/set of goals
  • Rules
  • Ways to get feedback on progress
  • Opt in participation (you can opt-out)

My current belief is that the 4th property, “opt in participation”, is an absolutely huge factor. It is highly correlated with levels of joyfulness, satisfaction, feelings of well-being, and overall life quality.

When you are forced to play a game, it is almost never fun.

When you opt-in to play a game, things get interesting!

Here is a summary of what I think is going on with these stories. These five stages of TRIBAL LEADERSHIP are actually stories and related self-talk, and are actually about the ability to make choices, about game structure, and about control, progress, belonging and meaning:

 

TL Stage Your Story The GAME connection
Stage 1 Life sucks! I’m forced to play games I do not want to play and/or do not understand. I have no options. I have absolutely no sense of control.
Stage 2 My Life Sucks! Some people play enjoyable (opt-in) games, but I don’t. I’m forced to play and cannot opt out. I get it, yet I have a low sense of control and almost no sense of progress.
Stage 3 I’m Great! I’ve figured out how to win. Further, I now define MY game, and now you have to play it. You ARE playing it! I’m now in control & now making great progress!
Stage 4 We’re Great! I opt-in to play a bigger, cooperative, goal-seeking game, with others. I now have a sense of belonging.
Stage 5 Life is Great! I opt-in to play a bigger, cooperative goal-seeking game, with others. And this time, we play big and intend to change the world. I now have a sense of higher purpose.

 

Summary

In my book THE CULTURE GAME, I explain the concepts and facilities available to create a good-game structure at work, a game where the enjoyment is so great that the distinction between work and play is minimal.

My current belief is that we are not nearly focused enough on using know-how about game mechanics to debug the problems we face at home, and work and in the wider world.

Culture, as it turns out, is a game.

Jane McGonigal gets it right: Reality IS Broken. And Zappos CEO Tony Hsieh also gets it right in his book, DELIVERING HAPPINESS: we all want to experience a sense of control, a sense of progress, a sense of belonging, and a sense of higher purpose and meaning. Good games deliver substantial happiness. The 5 stages of culture as described in the book TRIBAL LEADERSHIP do appear to confirm this hypothesis.

 

The Relationship to Effective Agile Adoptions

Agile adoptions are typically implemented as a mandate. This is acceptable so long as leadership sets out the clear direction and stops short of mandating specific practices. My current hypothesis, which appears to be valid based on experience, is:

  • Mandates of practices in an Agile adoption amounts to a game without the essential opt-in feature
  • People have needs. The mandate quickly reduces the feelings of control, progress, and belonging that are basic human needs
  • Resentment and disengagement are the natural and predictable results;
  • Disengagement is death to any attempt at a rapid and lasting Agile adoption.

The solution? Check in on what people want, what people think and what people feel BEFORE embarking on the journey of Agile adoption in your company. Open Agile Adoption is one way to do that.

 

Resources

For a deeper dive into these concepts, you might consider taking a look at these resources:

Blog Post: How Games Deliver Happiness And Learning

Blog Post: Open Agile Adoption

Audio Book, absolutely free download: Tribal Leadership by Dave Logan and co-authors

***

 

 

 

 

 

 

 

 

Posted on

Soul-Sucking Death Marches from Hell

I just examined Jeff Patton’s post on backlog grooming and his total discomfort with it as typically implemented in typical agile adoptions. Backlog grooming is implemented as a very bad meeting in his story, which you can examine via the above link. Save that for now, and just examine what I am telling you:

I have the solution here, and it’s all very simple. Game your meetings. Specifically, game your backlog-grooming meetings.

It’s not backlog grooming that is the issue here– it’s the game mechanics. I have written about this in my book, THE CULTURE GAME, and in blog posts. I’m providing more background links at the end of this post. Your meetings are already games. And they have very bad game mechanics.

The “backlog grooming meeting” that Jeff describes is either explicitly stating or strongly suggesting the following:

  1. Everyone attending is mandated to be there; attendance is not optional
  2. The meeting is 2 hours long
  3. There are no breaks
  4. There are no ground rules; the meeting is diluted and polluted by a weak ambient culture (people are diddling phones during the meeting he describes. Others are clearly checked out/disengaged)
  5. The goal of the meeting is probably very vague
  6. There is a focus on tools and processes over people and interactions
  7. I suspect there is an ‘overlord’ feeling regarding how authority is handled in this meeting.

The goal, the rules, and the feedback mechanics are vague. In addition, as previously stated, attendance is not opt-in. People HAVE TO BE THERE.

This is a recipe for a soul-sucking death march from hell. The story he tells is consistent with and strongly suggests the organization is also engaging in mandated collaboration, aka “forced agile”.

Your meetings are games. And they are games no one wants to play. Scrum is also a game, and we usually “make” or “mandate” that the folks play it. And they say “yes” when they mean “no”, if they are asked at all, which they usually ARE NOT. So guess what?

No one wants to play your seriously flawed agile adoption game, no one wants to play your Scrum game, and absolutely no one wants to attend your soul-sucking ‘backlog grooming’ meeting. Why? Because the games you are offering to people to “play” deliver a very low sense of control, a very low sense of progress, a very low sense of belonging, and a very low sense of purpose. It’s all very simple. Your games suck!

The way we are implementing agile/Scrum is seriously flawed. With the best of intentions, we force “agile collaboration” with the predictable, deplorable results of doing that. Then we implement Scrum without asking people what they think or feel about it! Then we force people to attend our soul-sucking “backlog grooming” meetings.

Then we say Scrum doesn’t work. We can do better.

  1. Coaches can explain the concept of invitation and opt-in participation to the management that hires them. Coaches can explain the links between invitation, engagement and productivity.
  2. Management can use invitation to increase engagement.
  3. Coaches and management can inspect game mechanics of all meetings and STOP doing things that do not work. Meetings display a fractal instance of the overall company culture. Long meetings with infrequent breaks, autocracy, weak facilitation and poor game mechanics are the culprit here– not Scrum, and certainly not backlog grooming.

What to do about the backlog grooming? Very simple. Use game mechanics to engage people. Deploy the meeting as a learning ritual to manage liminality and the liminal state of being.

NOTE: This is NOT gamification. Repeat: this is NOT gamification. By definition, “gamification” assumes there is no game! Therefore: You cannot ‘gamify’ your meetings, because your meetings are already games, they are simply bad games with deplorable game mechanics.

Now: What are we to do about this backlog-grooming-from-hell scenario?

Here is the A-B-C “prescription” for refactoring the “backlog grooming from hell” meeting described in Jeff’s post:

  1. Start over. Frame the new way to doing this as an experiment. Call the meeting the “Backlog Timeout” meeting, or make up some other name. (clear goal)
  2. Do it for N sprints or N weeks. State that we will inspect this experiment AS A GROUP at the end of the trial period. (clear goal and sense of belonging)
  3. Meet every day for 25 minutes. The goal of the meeting is to answer the question “what do we know about the backlog today that we do not know yesterday?” (clear goal and sense of purpose)
  4. Co-create working agreements for cell phone use, laptop use, breaks and interactions. (clear rules, complete with a sense of belonging)
  5. Attendance by the PO is mandatory. The PO is the Convener. (clear rules)
  6. Attendance by the SM is mandatory. The SM works in service to the Convener. This is spelled out. (clear rules with sense of control)
  7. Attendance by Team members is optional. They are invited. They can opt-out with no consequences or sanctions. (clear rules with sense of control)
  8. Facilitator keeps group on task answering the question: “what do we know about the backlog today that we do not know yesterday?” (clear goal, sense of purpose and belonging, managing the liminal state of “not knowing”)
  9. When the 25 minutes are up, the meeting is over. (clear rules, sense of progress)
  10. PO adds the freshly-generated EXPLICIT KNOWLEDGE to the PB each day. The most recent PB changes are reviewed at the start all subsequent meetings. (clear sense of purpose, belonging, progress)
  11. Consider scheduling the meeting daily, immediately after the Daily Standup each day, every day. (clear rules and sense-of-control)
  12. Always thank the people who opt in to participate each day (sense of belonging and purpose)
  13. At the end of the “experiment”, be sure to follow through by conducting a formal retrospective that you promised (clear sense of belonging, purpose and progress)

These concepts are drop-dead simple and spelled out in this blog post, and in the links at the end of this post.

To be successful, you must:

  1. Make sure the practices you create are in alignment with the Agile Manifesto’s 12 principles, and
  2. Make sure the practices you create are in alignment with the Gaming Happiness framework discussed in my book, and supported by the principles, patterns and practices found in this post and the links below.

The Backlog Timeout is an object example of a good design.

I have experience implementing the 25-minute Backlog Timeout Meeting and I can tell you it works absolutely great.

The folks participating appreciate the clarity and brevity of the meeting, and the ability to opt-out. In typical (weak) agile agile implementations, there is a death march at the end of the Sprint and attendance at the Backlog Timeout wanes until the Sprint is over.

And that’s OK!

Note that this is just one instance of applying specific principles. Don’t “radar lock” on this practice. Practices change, principles don’t. Anyone can use these principles to get better agile-adoption results. Those principles are:

  1. Good game mechanics: a clear goal, clear rules, a clear feedback mechanism to depict progress, and opt-in participation.
  2. Nominalization. This is useful for sense-making. Give the activity a specific name. Always refer to an activity by its name. This is essential for sense-making.
  3. Frame Experience as Experimentation. Encourage “act as if”, and “pretend”. Frame every new policy as a temporary, experimental, game.

To completely understand this post, you must carefully examine all the supporting links that follow:

Related Links:

Game Your Meetings: http://newtechusa.net/agile/how-games-deliver-happiness-learning/

Mandated Collaboration: The Total Oxymoron: http://newtechusa.net/agile/the-recipe-for-botched-agile-adoptions/

Leveraged Learning: Learn fast as a group by doing very short recurring-every-day meetings instead of those long meetings! Those long meetings are stupid! http://newtechusa.net/agile/leveraged-learning/

Practices Change, Principles Don’t: http://www.freestandingagility.com/featured/practices-change-principles-dont/

Sense-making explained: http://en.wikipedia.org/wiki/Sensemaking

Nominalization explained (for sense-making): http://en.wikipedia.org/wiki/Nominalization

I invite you: Call me at 203 915 7248 if what I am saying is resonating with you.

Posted on

The Intentional Learning Organization

There is absolutely nothing automatic where group learning is concerned.

As a group, we either intend it, or we don’t. Look no further than the current (low) learning levels of typical groups: teams and organizations; and local, state and federal government. Look no further than how nations act and behave with respect to learning.

If learning in groups was automatic, we would already:

  • Be colonizing Mars;
  • Be creating Genius Organizations at will;
  • Be curing cancer;
  • Be electing leaders that actually help us evolve as a species;
  • Be routinely processing conflict without war;
  • Be routinely managing population growth.

AND SO ON. See? Very little of these achievements are actually within reach. Getting all of this kind of stuff done requires people who agree. People who are aligned. No one person can pull any of this off alone.

No, group learning or what I call Tribal Learning, is a highly intentional and uncomfortable act. If it was easy, we’d be colonizing Mars by now. Cancer would be cured. See? You have to intend it.

In a business setting, Tribal Learning requires that we do at least some of the following:

  • Be Purposeful
  • Facilitate Our Meetings
  • Examine Our Norms
  • Be Punctual
  • Structure Our Interactions
  • Announce Our Intent
  • Game Our Meetings
  • Conduct Frequent Experiments
  • Manage Visually
  • Inspect Frequently
  • Get Coached
  • Manage Your Boundaries
  • Socialize Books
  • Pay Explicit Attention
  • Open The Space
  • Be Playful

These are the exact patterns and topics that The CultureGame book addresses. Most of these group-level behaviors are very uncomfortable.

That is because learning is uncomfortable.

That is because learning is change, and change is uncomfortable.

To learn as a group, everyone has to want to do it. Or, they have to at least tolerate the new patterns of behavior (see above) that encourage group learning.

Is it really this simple? Yes, it is really this simple.

Tribal Learning: If nobody wants to, it ain’t gonna happen.

Leaders have a role to play in helping people to ‘want to’. I plan to explain that one soon.

 

Posted on

Keith Ray: Thought Pioneer

The following is printed with permission from Keith Ray. It originally appeared here. The post is preserved here in unadulterated form. In this post he makes certain assertions that start to link Agile practices with the ability to manifest a Learning Organization. This is a great read.

 

 

Quotes:

Continuous Learning. I’ve always said that XP requires a Learning Organization, and this practice make it explicit.

and this one…

“….If everybody isn’t learning, then learning becomes a subversive activity.”

What is striking about this post is the obvious development of many of what are called Tribal Learning Patterns in the Culture Game book….blogpost follows…..

============================================

2003.Apr.24 Thu

What is Industrial Extreme Programming?

At the BayXP meeting last night, Joshua Kerievsky, Russ Rufer, Somik Raha, and Tracy Bialik of Industrial Logic gave a presentation on their version of XP that they have developed over the last several years. They named it “Industrial Extreme Programming” (IXP). What follows here are taken from my notes. Any errors are my own.

IXP is what Industrial Logic has been doing the past few years as they work with their clients in training and coaching XP projects. Joshua said he was concerned with recent “blendings” of XP and other methods (DSDM, FDD, Scrum, Crystal) because some of those blendings were throwing away XP’s planning practices (one of the most valuable aspects of XP). Many of these blendings were for the most part untried and unproven, as well, though the unblended methods have records of success.

IXP doesn’t remove any of the core practices of XP (except Metaphor, and few teams have really felt like they successfully used XP’s Metaphor practice). IXP builds on XP, adapting it for survival in larger companies, highly political companies, and large teams.

Kent Beck defined four values of Extreme Programming, values he felt were essential… other values were good, but he wanted to emphasis four in particular. XP’s values are Communication, Courage, Feedback, and Simplicity. Agile Modeling adopted those four and added Humility.

Joshua and his team have chosen five values, which they not only want to emphasize, but insist that the absence of these values in the project or company will cause failure and unhappiness. The IXP values are: Communication, Simplicity, Learning, Quality, and Enjoyment.

The value of Enjoyment is sometimes deemed controversial. Joshua considered Fun, and probably felt Enjoyment sounded better. People who enjoy their work are more likely to want to learn I’ve always said that XP requires a Learning Organization). People who enjoy their work and enjoy working together are more likely to have the teamwork that XP requires.

Quality is “we know it when we see it.” Quality products, quality code, a quality process, quality people.

These are the original XP practices that IXP includes (more or less), sometimes with modified names and meanings: [names in brackets are the original XP names, or the names I prefer over Kent’s names.]

 

  • Sustainable Pace
  • Planning Game [Release Planning, Iteration Planning]
  • Frequent Releases [Small Releases]
  • Refactoring [Merciless Refactoring]
  • Story Test-Driven Development [Programmer Tests, Acceptance Tests, TDD]
  • Continuous Integration
  • Pairing [Pair Programming]
  • Collective [Code] Ownership
  • Coding Standard
  • Domain-Driven Design [replaces Metaphor]
  • Evolutionary Design [replaces Simple Design?]

The name changes are for clarity and to expand things beyond just coding — people can pair on other things besides code, collective ownership can extend beyond code.

The new practices are:

 

  • Readiness Assessment
  • Viability Assessment
  • Project Community
  • Project Chartering
  • Test-Driven Management
  • Storytelling
  • Storytesting
  • Small Teams
  • Sitting Together
  • Continuous Learning
  • Iterative Usability
  • Retrospectives

Readiness Assessment answers the question “Are they able to transition to IXP?” See http://www.industriallogic.com/xp/assessment.html.

Viability Assessment answers the question “Is the project idea viable? Profitable? Feasible? Does the project have the necessary resources?”

Project Community expands on Kent Beck’s “Whole Team” concept. “People who are affected by the project and who effect it.” (Hope I got that quote right.) This includes QA staff, middle and upper level managers, tech support staff, programmers, DBAs, customers, end-users, and probably marketing and sales. (Reference to David Schmaltz / True North Consulting’s Project Community Forum.)

Project Chartering provides the Vision and Mission, as well as the definition of who is in the Project Community. A light-weight exercise that seems to be necessary for clarifying the project’s goals.

Test-Driven Management requires objective measures be defined for the success of the project. External results like “support 100 users by December 2003.” The Whole Team cooperates to achieve this goal. Also defines return on investment.

Sustainable Pace. They considered renaming this to “Slack” (see the book by Tom DeMarco). An example of the value of slack is that it can provide the time for someone to write the tool needed to increase development speed — too much focus on getting stories implemented quickly can be sub-optimal.

Storytelling. I think Joshua separated this out from Planning Game in order to emphasize that story-telling is a natural way to get requirements (sometimes after a bit of coaxing). IXP stories are not necessarily “user-centered” stories, since they may address concerns of administrators, maintainers, etc. “A story is an excuse to have a conversation.” Conversation is required to understand some stories — a story that can’t be understood can’t be implemented. Five words for a story title was also mentioned.

Storytesting. One word, to parallel Storytelling. This is defining the acceptance tests, but not writing them. IXP coaches help their clients in both Storytelling and Storytesting. Ideally, you do want “executable documentation” and they talked up Fit by Ward Cunningham – a framework that allows anyone using any editor capable of creating HTML tables to be able to specify acceptance tests. (Programmer help is still required to plug an application into Fit’s acceptance test framework.)

Planning Game. Joshua says that it is very weird that some of the hybrid methods are throwing away the planning game. This practice is so useful that many of Industrial Logic’s clients, who did not adopt all of XP, did adopt the Planning Game. Still, the concept of “velocity” (work done per iteration) seems to elude some clients

Frequent Releases – frequent end-user releases — same as XP’s practice. Enables rapid return on investment. Releasing to end-users provides opportunity for feedback, to find issues in deployment, issues raised by real live users. “Without learning, feedback does no good”.

Small Teams — for large projects, set up networks of small teams, with their own code-bases and coding rooms. A 30-person project might consist of teams as large as ten people and as small as three. Sometimes there might be a testing team and/or refactoring team that join the each of other teams at various times and then move on. Industrial Logic practices Pair Coaching, which does not require that both coaches be together at all times. Pair Coaching does enable coaching larger projects than a single coach could cope with.

Sitting Together — Joshua says that the term “Open Workspace” turns some people off, but it is the same concept. He has seen a 40-person XP team in one very large room, but that’s unusual. He has also seen one or more people give up the office they worked hard to get, because pairing in the same room as other people let them focus better and learn more. Sitting together / pair-programming can be done via internet collaboration, so it isn’t limited to open workspaces. The gave an example of a team split in two time-zones, who decided to synchronize their hours to allow more “virtual pairing”.

Continuous Learning. I’ve always said that XP requires a Learning Organization, and this practice make it explicit. Examples… Study groups who are not just allowed, but encouraged to get together for three hours a week, during office hours, because they know this helps them advance in their careers. XP Coaches who assign practice drills to the programmers or QA testers. “Lunch Break” learning groups show that management doesn’t care enough about their employees learning. An XP coach in Italy spends an hour a day teaching his junior programmers — whose skills are rapidly advancing. I think an member of the audience said “If everybody isn’t learning, then learning becomes a subversive activity.” Joshua also said that “resume-driven-design” tends to happen because programmers are starving to learn, but not given opportunities to do so.

Iterative Usability. The UI must be usable and tested regularly. Management-Tests should be tied into Iterative Usability. Redesign the UI as soon as feedback shows its flaws. Paper-based GUI design was also mentioned.

Time was running out, so the remaining practices were discussed quickly…

Evolutionary Design. Drives all design. Their tutorial has ten practices for this. (http://www.sdmagazine.com/documents/s=7928/sdmsdw3d/sdmsdw3d.html.)

Coding Standard. Have one.

Pairing. As per XP, but not just programmers.

Collective Ownership. As per XP, supported by tests, pairing, etc.

Retrospectives are a critical practice. Some clients are reluctant to get 40 people together for 2 or 3 days for a full project retrospect, but they should do it for the unexpected learnings that come from it. Also do mini-retrospectives each iteration.

Refactoring. Early and often as per XP. Don’t let “refactoring debt” accumulate.

Domain Driven Design. Even though never officially a part of XP, it has been done by every good XP programmer that Joshua knows. The Model objects are kept separate from the rest of the code (GUI, etc.) The acceptance tests normally operate on the model objects, skipping the GUI. See the book on this subject at http://domainlanguage.com/. See also Erik Evan’s “Ubiquitous Language”.

Story-Test-Driven-Development. First write a failing acceptance tests. Then use the TDD cycle (failing programmer test, code to make programmer test pass, refactor) until the acceptance test passes. This is “top-down” TDD, and it best avoids writing unnecessary code.

Continuous Integration. As per XP.

See http://www.industrialxp.org/ for more information. Check out these papers, too: http://industriallogic.com/papers/index.html
Posted on

The Genius Organization

Is is possible to create a “genius team” using off-the-shelf Agile techniques like Kanban and Scrum? Can ANYONE create a genius team, assuming they and the team members are willing? Can McCarthy’s Core Protocols play a big role in the development of a Genius Organization? Is culture a gating factor in how organizations learn?

I think the answers are yes, yes, yes and yes.

The Genius Organization

The genius organization (aka a “learning organization”) is an organization that rapidly assimilates new knowledge. It rapidly converts tacit knowledge to explicit knowledge. It constructs and then consumes that knowledge, enterprise-wide, in pursuit of great results.

The genius organization:

  • Learns fast
  • Senses and responds at high speed and in super-rational fashion to change
  • Creates safe space for members to express what they want, think and feel
  • Works from principles and values, not practices.
  • Chooses practices that are informed by purpose, principles and values
  • Views differences as opportunities to learn and innovate
  • Views mistakes as learning opportunities
  • Values people over roles; does not view people as ‘resources’
  • Has an intentionally developed culture which is designed
  • Is in a state of Free Standing Agility
  • Almost automatically qualifies for WorldBlu certification

 

Agile Coaching

In my view Agile coaching has a huge and pivotal role to play here. We can either take the money of clients without imposing any standards on what they are requesting from us, or we can work in service to the building of an organization that can rapidly learn. And by learn I mean, learn after we exit the engagement. Learn to learn fast, without any external assistance.

Learn to be a Genius Organization. Agile coaches have a pivotal role to play in whether this outcome happens or not. At issue is what we are serving as we engage with client organizations around the world.

Kanban and Scrum

Kanban and Scrum are prefabricated plans and designs for teams that need some help creating and holding a set of shared understandings. Kanban and Scrum are simply entry points along the path to becoming a Genius Organization.

Discussions of one or the other being the ‘one true path’, discussions of which is ‘superior’ are at best immature and misguided. These social technologies help groups of people build substantial and shared mental models and the potential for a shared vision. That is the value of any Agile technique. Discussions of differences may be intellectually interesting but in the end miss the point: Agile is a gateway drug to a state of organizational bliss: the Genius Org.

A genius org can rapidly sense and rationally respond to opportunities. It has reached a state of Free Standing Agility. This requires an enormous amount of alignment on purpose and values across the entire organization.

A couple of my most progressive clients are very close to this ideal. In future posts, I plan to profile them.

Posted on

Moving Beyond IceBreakers!

If you are an Agile coach or Agile practitioner, YOU NEED THIS BOOK.

Not too long ago, in Boston, we discovered TEEN EMPOWERMENT. This non-profit is in the business of mediating conflict and violence between gangs and other groups of people in the inner city. They are in the business of building shared understanding between rival groups. They are in the business of helping young people in the inner city reclaim their identity, and their lives. TEEN EMPOWERMENT is in the business of serving others.

But wait…there’s more. The leader Stanley Pollack discovered that by using what he call ‘interactive activities’, (read: “agile games”) people can learn to build bridges, get learning, and develop shared understandings, even as they process differences.

Does this sound familiar?

I hope it does.

At www.AgileBoston.org, we are doing everything we can to promote the work of TEEN EMPOWERMENT and the amazing book, MOVING BEYOND ICEBREAKERS.

You want to examine this amazing book NOW,  and get a copy.

Interested? Learn more here.

Posted on

Agile: Gateway Drug to the Learning Organization

This post is how Agile is really just a gateway drug than can lead to a hard-core habit of Organizational Learning. However, that progression from merely ‘playing Agile’  to becoming a full-blown Learning Organization is by no means guaranteed.

 

In 1990-1991, Peter Senge wrote a book called THE FIFTH DISCIPLINE. In that book he describes the 5 characteristics of a ‘Learning Organization’. In my view, describing a Learning Organization is far easier than building one. Finding a learning organization as described by Senge is also quite difficult. In fact, it is about as difficult as finding an organization that has implemented and achieved real Agility, what I call Free-Standing Agility.

Agile is a culture hack, and the intent of the hack is to produce a small learning organization- we call it a Team.

What is Agile then?

Agile is a gateway drug to real organizational learning. All of the Agile techniques are in a sense very small A-B-C prescriptions  for learning how to be a Learning Organization.

Scrum.

Kanban.

Task Boards.

Information radiation.

Retrospectives.

XP.

Pair programming.

Iteration.

Burndown charts.

Work-in-process limits.

Test-driven development.

Etc.

ALL of these practices are nothing more than gateway drugs to the ultimate enterprise high: organizational learning.

Working at an organization that rapidly learns is the ultimate high. You are respected as you respect others. The space is safe for the best idea, asking for help, and calling bullshit when we start sidetracking. You love working with the people there, even as you strongly disagree with them.  Mistakes are learning events. Differences are raw material for innovation. You use specific techniques and behaviors to rapidly learn as a group. The people there value what you value. You feel in sync and are in fact highly engaged.

Participating inside a true Learning Organization is the ultimate career high.

We are in the late-majority stage with respect to Agile. Most organizations are “playing Agile”, in effect “smoking the dope” of Agile practices to get a quick buzz. These organizations are not focused on organizational learning as the end game. They are out in left field, missing the boat, asleep at the switch. The buzz you can get from Agile is nothing compared to the transcendent bliss of experiencing social membership in a genuine Learning Organization.

Team learning is by no means automatic. We must intend it as a group. Everyone and every organization gets what it wants. To know what an entity wants, examine long-run results. Intentions == Results.

The next chapter with Agile is business agility. A business that is truly Agile is in fact a Learning Organization. The primary tool for getting there is a focus on creating and maintaining a culture that is 100% conducive to extremely high levels of Tribal (group) Learning.

Culture hacking is one way to get there. Culture hacking is the intentional modification of culture, with or without permission…with intent to change the game. Agile is a great example. Agile is a total culture hack.

I explain ALL of this in great detail in my book, The Culture Game. It is a culture hacking tutorial and reference guide– the handbook for game-changers and innovators who live and work in the corporate “reality-distortion” field.

The Culture Game book explains the 16 learning patterns that, if implemented, can almost automatically generate much higher levels of business agility.

Summary

Is organizational learning addictive? It might be.

Scrum, Kanban and the rest….they are mere gateway drugs to the real deal: the enterprise-wide mainlining of the habits that lead to the ultimate organizational buzz: The Learning Organization.

Agile is a gateway drug to organizational learning and the blissful state and status that any rational organization must aspire to: the learning organization.

The Learning Organization: Argyris and Schon defined it. Senge popularized it. The Agile movement made it real.

But not at scale.

Agile is a convenient gateway drug to the ultimate buzz: participating in always-on, enterprise-wide organizational learning.

Who wrote this? Learn more here.

Posted on

Culture Hacking

Culture hacking is almost the same as software hacking. Culture hacking modifies culture, instead of modifying software. Software hackers in the 1970’s created code for personal use and for others to also use and enjoy. In the modern day, culture hackers actively modify culture for personal betterment and the betterment of others.

 

Hacking Culture- like it is software

What is significant here is the software view of culture. I have already written about how culture is a system, like software, and can be hacked like software. In my view culture is composed of stories, and stories are composed of language. If you modify language you are in fact culture hacking.

I credit Jim McCarthy and Michele McCarthy for emphasizing this link between culture and software,  in their book SOFTWARE FOR YOUR HEAD. The book describes structured interactions for humans. Likewise I credit the McCarthy’s with moving decisively to popularize the phrase culture hacking. My book  THE CULTURE GAME is literally a culture hacking manual.

Here is what Jim McCarthy says about culture hacking:

A culture is the set of shared attitudes, values, goals, and practices that both describes and shapes a group. Our era is increasingly characterized by an emergent “software culture.” Not only is software itself creating much of our global wealth, but the unique challenges of creating our software have demanded wholly new types of engineered corporate culture from us. 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.

Culture hacking is itself a distinct kind of culture engineering, and is faithful to the particular hacker ethos that originated in the world of software hacking. Good culture hacking will tend to protect personal freedom, extend openness, embody rationality and promote culture design elegance. Culture hacking takes into account the limits and uses of authority, is skeptical of incoherent institutional power, and is subversive of it. As our many cultures become increasingly (and fruitfully) hacked, we will likely grow in effectiveness, and ambition. This will bring more and more of the world’s problems into manageable scope. This will likely trigger an unprecedented Golden Era.

 

Agile in reality is a great big culture hack: a collection of processes and methods and specific actions that, when used together, influence culture at various levels: team, department, division, enterprise.

Agile is a culture hack. And over time, we may start to understand it as a relatively and historically primitive one at that.

Think of it like this:

culture hacking = agile++

 

 

Posted on

Management Is a Function, Not a Role

Management Used To Be a Role. We’re now DONE with that.

In the days of Frederick Taylor, management fit neatly in a role. A single skilled person directed the work of largely unskilled labor throughout the Industrial Revolution. Workers eventually became groomed through the education system to show up as cookie-cutter conformists who did what they were told. And they “checked out” and became unengaged “zombies” at work.

 

Fast-Forward to NOW:

Now we have “work/life balance”, a sanitized term for “unhappy, unengaged, split person” or “split personality”. (Dave Logan says if you love your work and your job, “Work/life balance is a crock“, and of course he is RIGHT.)

We still are dealing with a very broken and anachronistic education system that encourages conformity at a time when we need anything but. Innovators like Salman Khan have created self-managed learning spaces online, and are finally starting to get some traction.

Management is a function, not a role.

The World of Work Has Changed

In the new world, people do knowledge work. Even when they do not, they want to be respected. This respect is expected to show up as voice, choice and what we are coming to understand as self-management.

Ken Schwaber and Jeff Sutherland, in their book SOFTWARE IN 30DAYS OR LESS, say this:

“People are most productive when they manage themselves” (pg 29.)

Management is a function, not a role.

 

Management Is a Function, not a Role Occupied By a Single Person

The days of the management function being held by a person are surely numbered. If we look carefully at current examples like Scrum and the structure of MorningStar Company, we can see what is going on: management is more important than ever, and it is not embodied in a single person in a single (authoritative) role. Instead, employees execute mutual Client Letters of Understanding, which are essentially working agreements. Instead of a job description, these interpersonal agreements define the work.

Management is a function, not a role.

Inside product and software development, teams are self-managed. We call this “self organization” or “self organizing” teams. What we really mean is this: teams (in Scrum) and individuals (in organizations like MorningStar) are self managed.

We have entered the age of self-management. The old game is OVER.

Managers are becoming obsolete, even as management becomes more important than ever. The old Taylorist conformity is giving way to the rise of the self-managed worker. This has profound implications for just about everyone who works for a living.

Management is a function, not a role.

Time to get busy learning about what self-management means for your job, your department, your employer. Time to get some new beliefs about the world of work. Don’t wait.

***

NOTE: These and other ideas of mine appear in my latest book, THE CULTURE GAME. You can learn more about THE CULTURE GAME book here.

Posted on

Triumph of the City

The ultimate cause of Athenian success may seem mysterious, but the process is clear.

I’m reading TRIUMPH OF THE CITY by Edward Glaeser.  The aforementioned quote comes from this book. Friends are reading it, and recommending the book. The book is super-stimulating and is a truly great read. One of things that is hitting me about this book is the virtualization of city life. I’m plugged into some amazing FaceBook groups now. The people I am meeting and interacting with are all in the same ‘city’ so to speak. The experience is insanely stimulating. It’s like moving to and living in a very large city, and having a core group of stimulating friends who make the place friendly and fun.

It all starts with one connection. Let me explain.

I have a friend who uses http://www.couchsurfing.org/ to do travel. He goes to Madrid that way, 2 years ago, for 10 days. Or so he thinks. He loves it so much he stays for 6 months teaching English. You might wonder how he pulls this off. It is all based on that one personal connection he makes via CouchSurfer. His CouchSurfer host got him connected socially right away, and off he went. Six months in Madrid, and he barely knows Spanish going in. From there he gets an apartment, develops his wider network of friends in Madrid, and ends up having a completely awesome time.

Same thing here with the online city-space. The new cosmopolitan city is the online space: groups of people with aligned interests. When we get truly intimate online, we move beyond interests to a more general alignment based on experience, beliefs, values, behavior, and results. We get serious stuff done together after disclosing information and getting more and more genuine alignment.

We are rapidly coming to a time where people of like mind can rapidly produce amazing results. It is all based on social introductions, dialogue and blending at EPIC SCALE. For that to happen, you must have an entry point. That entry point is the introduction, or invitation from one person to another. From there, you have proximity… and the fun begins. Once you enter the online city-space via a group of people aligned on interests, you have access to most of the social benefits of living in a large city. You have a network of support, many introductions are made, you also make introductions, and the mixing of ideas begins. You also end up attending live events when people converge in a certain place for dinner or some kind of larger context like a conference or symposium.

I am willing to argue that the largest city on the face of the earth is FaceBook. All the basic social elements are there. Yes, the form is crude. The content is not. As socio-technical systems get better, the velocity of change and creativity can only increase.

I say:

We may be entering a Golden Age of creativity, especially in the way we implement what is called society, or civilization.

As I read Ed Glaeser’s book, I am mapping what he is saying about brick-and-mortar cities to the online city-space.

This is a rich and yeasty time to be alive. We are living in a time that is exuberantly creative.

Ideas move from person to person within dense urban spaces, and this exchange occasionally creates miracles of human creativity. – Edward Glaeser, TRIUMPH OF THE CITY