THE CULTURE GAME Chapter 8

(Note: This is sample text from CHAPTER 8 of THE CULTURE GAME BOOK, available on Amazon here)

CHAPTER EIGHT: FACILITATE YOUR MEETINGS

Facilitated meetings tend to be focused, organized, and well defined. When you clearly describe who qualifies to attend, what the goal is, what the boundaries are, and how you will manage the meeting, you create an invitation to explore the topic or issue. The convener has the luxury to participate more fully and observe without the additional responsibility to run the entire meeting. Facilitators are there to keep meetings flowing and to end on time. A facilitated meeting requires you to organize yourself in advance of the meeting.

Facilitated meetings are essential if you intend to become great as a group. Meetings are useful only when the objectives, agenda, and duration are all clearly stated and in alignment. Use facilitators to stay organized, complete meeting agendas, and learn faster as a group. Leverage facilitation to attain group focus while pursuing greatness inside your teams as well as in the wider organization. Develop a norm of focused meeting greatness.

History and Origins of the Practice

Scrum is the world’s most popular framework for high-performance teams to build software and other complex products. Someone facilitates every meeting in Scrum, and there is a clear reason why. Facilitated meetings tend to encourage learning and the mixing of ideas, because facilitated meetings tend to create a space where everyone gets a chance to be heard, even the genuine introverts in the room.

How This Helps

By establishing a clear goal, a clear set of rules, and a clear way to track progress, you make any game enjoyable. A good game makes for good learning, and meetings are no exception. Facilitated meetings tend to be well planned, have the right participants, and a clear set of rules. Meetings for brainstorming and dialogue are especially well suited for facilitation. The facilitator can defer any movement towards the premature end of a discussion and too early a decision, and keep the space open for inquiry. When the time is appropriate for the group to decide, the facilitator can assist in moving in that direction.

A good meeting serves a stated purpose through its structure. To structure a meeting to be more divergent, focus primarily on generating ideas. Meetings focused on the need for decision-making tend to be convergent. A good facilitator helps by structuring a meeting to match the purpose. When one meeting needs to accomplish both purposes, a good facilitator can help deflect premature movement of the group from dialogue to decision-making.

Costs

There are no hard-money (cash) costs for this step. You can choose to start using facilitated meetings formats immediately. A good practice is to have a person from outside your group to facilitate your meeting. Later you can return the favor, and send over one of the people from your team to facilitate the meetings of the other group. The net cost is zero in terms of time, as you will be swapping people to perform facilitation services for each other. This technique begins to generate a facilitation culture and creates a mixing of people and ideas and information. This mixing is a form of socialization that further increases sharing of information across departments. Search the web to develop your organization’s facilitation skills inexpensively, to get familiar with facilitation techniques, and experiment with them. The International Institute for Facilitation offers facilitation certification credentialing for those who want to dig deeper into specific facilitation competencies and practices.

Results and Related Delays

A well-facilitated meeting tends to have a clear purpose, stays on track, and is productive with just the right level of structure. Facilitated meetings tend to be enjoyable and productive. These benefits tend to manifest immediately.

Details

Facilitated meetings are generally better than meetings that are not. Participants learn to enjoy having someone besides the convener in a role that is responsible only for steering. Breaking out the responsibility for facilitation from the sole authority of the convener will smooth out a meeting and free up the convener to listen and observe.

A decent facilitator can smooth out a meeting by making sure everyone is heard, making sure that loquacious people make space for others, and managing a meeting’s sense of progress and tempo. A facilitator can also encourage greater respect inside a meeting by creating and holding space for dialogue. A facilitator can handle making sure that the convener honors scheduled breaks, as well as the start and stop times. This also supports respect, commitment, and focus on the part of all participants.

A skilled facilitator can also make small adjustments that help the group more easily achieve objectives. Sometimes a group of people meeting to make decisions are actually not ready, and are better off continuing with the dialogue a bit longer, before moving to decision-making and action. A skilled facilitator can sense this situation, and encourage dialogue during that meeting.

Challenges

Results can vary based on the skill of your facilitator and the complexity of the meetings you are trying to streamline.

Meeting conveners need to be willing to delegate responsibility to the facilitator to run a meeting. When conveners do this, they are not giving up any authority. You may need to elaborate on this theme with some conveners. Facilitators serve meeting conveners, not the other way around. The convener needs to meet with the facilitator to make these boundaries are explicit and well understood.

The facilitator is serving the authority in the room rather than being the authority in the room. A heavy-handed facilitator can unintentionally limit the space for dialogue and turn people off. In general, do not choose an organization’s central authority figure to serve as a facilitator.

Steps and Options

Implementing this practice involves the following steps:

  1. Socialize the idea of facilitated meetings. Send out some emails about the advantages of facilitated meetings. Purchase some books, and make them available and visible.
  2. Identify a facilitator. The best facilitator candidate is a person who begs you to try it. Facilitation is an art form and a skill grounded in sociology. Listen and watch carefully for the people who willingly opt-in to try facilitation. Watch out for those who seek authority – the facilitator role is that of a servant-leader, not a boss or autocrat. An overly authoritative facilitator can unintentionally limit the space for dialogue and turn people off.
  3. Gather some resources for learning. The book GameStorming provides a great set of meeting facilitation ideas and tools. This and other resources can help you develop facilitation skills and ideas. Investigate the International Institute for Facilitation website and related resources.
  4. Experiment by convening a facilitated meeting. Start facilitating some of your meetings and inspect the results. Let those who express interest in being the facilitator give it a try.
  5. Inspect the results. Periodically inspect the results and find out if the participants at these meetings are finding the meeting more valuable. Do not assume they do. Inspect the results.
  6. Develop a culture that includes facilitated meetings. Offer other managers a facilitator from your group, and then switch. Swap facilitators. If you work in a larger organization, develop a community of practice around facilitation.

Takeaways: Facilitate Your Meetings

  • Facilitated meetings help increase learning by creating and holding space where everyone can be heard
  • Meeting conveners who delegate to facilitators can engage in observation and participation more freely without the burden of running the meeting
  • Facilitated meetings tend to have a clear goal and well-understood ground rules and working agreements. This increased safety transforms a meeting into a good game, and increases levels of engagement.


[1]       Learn more about the International Institute for Facilitation at: http://www.inifac.org/

 

[2]       See Gamestorming: A playbook for Innovators, Rule breakers and Change makers by David Gray, Sunni Brown and James Macanufo

The Global Scrum Gathering Keynote: Paris 2013

I am grateful to have been invited into (and have accepted) the opportunity to deliver a plenary (keynote) address at the Global Scrum Gathering in Paris, France. The event runs from September 23-25 and the keynote is scheduled for Tuesday, September 24. I am honored to be part of this event with Henrik Kniberg and Dario Nardi, who also are delivering keynote addresses on Sept 23 and Sept 25 respectively.

You can learn about the 2013 Global Scrum Gathering in Paris here. If you click the [Keynotes] tab and then the right-arrow, you can examine the three keynotes, including the description of my talk.

I also list it here, for your convenience:

Open Agile Adoption 
The Agile journey may be best characterized as a rite of passage. Those who are taking the next step always do so as a group. During the journey, all the participants share the same basic status. Successful participants find themselves in a new and very unfamiliar place. And lastly, anyone who wants to complete the journey must also be willing to leave many things behind.

  • In tribal societies, passage rites from start to finish are facilitated and in fact led, by a “master of ceremonies.” What has changed?
  • Is the modern journey into agile actually a passage rite… for modern tribes?
  • Is the Scrum Master in fact the master of ceremonies in a modern rite of passage for teams and organizations?

In this session, together we explore the surprising answer. We also explore how to specifically leverage Open Space as a tool for helping to create authentic and lasting Agile adoptions.

I plan to explain Open Agile Adoption, an approach to implementing Agile that I have developed over a three-year period during which I have coached inside over 20 organizations. I have coached Agile since late 2007 and began experimenting with new approaches in 2009. At that time I noticed how some very intelligent people became disengaged during Agile adoptions. I began to ask why.

I began experimenting with the use of Open Space to help encourage more engagement, in service to rapid and lasting Agile adoptions. These Open Space experiments  generated some very surprising results. I’m grateful to the many organizations in and around Boston that have allowed me to experiment with sociological approaches to solving the Agile adoption puzzle.

Sociology First, THEN Practices

For my part, I value practices…because sound practices are very important. Yet solid, sound practices implemented with disregard to what people want, what they think and what they feel is, at best, misguided. It tends to generate disengagement.

I have learned the hard way, through experience, that the people who do the work are telling themselves a story. And that story is:

  • I get paid for thinking, and
  • I get paid for solving problems, and
  • I get paid for being creative.

That’s the story. This is one reason why it is essential to value sociological factors: if we mandate specific practices, the thinking and the problem-solving and the creativity that people bring to work is suddenly dampened. Squelched. Discouraged. Even killed off. Further, and more importantly, any sense of control is diminished. A sense of perceived control is essential for any sense of well-being.

Result: The prescription of specific practices becomes a topic for resentment…and eventually, disengagement. In my experience, it doesn’t take too long for people to “check out” on mandates and prescriptions. This disengagement is death to any honest attempt to bring improvement to an organization.

In Paris, I plan to tell you the wider story of Open Agile Adoption. The story includes many interesting people…and more than one courageous leader who took a legitimate shot of greatness with their Agile adoptions. I’ll tell the stories, and present several case studies. I’ll also provide a toolkit, free to the world… that anyone, anywhere can use to repeat the Agile adoption results I am getting.

I hope to see you in Paris. If you cannot attend, you can follow the Open Agile Adoption story on Twitter and here on my blog. As we head into September, I’ll explain more and more about the concepts and facilities of Open Agile Adoption. I’ll also explain the specific components, which are firmly rooted in sociology and cultural anthropology. On September 24 in Paris, I’ll present the actual case data and experience reports, and numerous testimonials on video.

More importantly, on September 24 2013, the date of the Paris keynote, I will make available to you and everyone, worldwide, a free, comprehensive, open-source toolkit for implementing a rapid and lasting Open Agile Adoption.

Frank Zappa, the offbeat musical genius, once said: “Without deviation from the norm, progress is not possible.” I believe he is correct.

I hope you will join me in learning more and more about the details of the Open Agile Adoption technique, incorporating Open Space Technology, as we head into September. You can stay up-to-date on my writing about it by bookmarking this link.

Perfect Agile Coaching

Imagine if it was possible to for an organization to reach a state of self-sustaining, freestanding agility after just 5 coaching days.

Just FIVE.

What might that mean for the spread of agility throughout the world?

I met Chris Rufer, Paul Green and Doug Kirkpatrick last May when I presented a session on Gaming Happiness At Work at the Self-Management Symposium. One of the things I learned was that MORNINGSTARCO uses this concept of stepping-stones. Here are the steps:

  1. For a given task or job, define perfection. For example, at MORNINGSTARCO, for maintaining machinery that processes tomatoes, “perfect” is defined as a maintenance cost of ZERO for processing an INFINITE volume of material.
  2. Next, figure out your current performance numbers. For example, for machinery that processes tomatoes, the current score might be “one dollar of maintenance expense, on average, for  every 10 tons of product processing.”
  3. Now define a stepping-stone goal, in the direction of perfection: How about trying to get the maintenance cost down to 92 cents per 10 tons of processing, instead of 1 dollar?  89 cents maybe? That’s a stepping stone. 89 cents. Its a small, achievable goal, in the direction of improvement…in the direction of perfection.

In golf, “perfect” is eighteen hole-in-ones. That’s it.  “18” is the perfect golf score. Now, no one can actually achieve that. This actually does not matter. What does matter is that the ideal– the perfect—  is very clear.

Every golf pro is thinking about 18 as the ideal– as perfection. And they make small moves to get closer and closer. Thinking about perfection when aiming to improve is a very interesting idea. This idea from MORNINGSTARCO got me thinking about Agile coaching and perfection.

Perfection in Agile Coaching

What constitutes perfection in Agile coaching? How do we apply the MORNINGSTARCO stepping-stone concept to the execution of Agile coaching?

I think it has to do with client organizations reaching a state of self-sustaining, freestanding agility via the ABSOLUTE MINIMUM coaching engagement. What is that minimum exactly? Can a coach help get an org to a state of self-sustaining, freestanding agility with 30 days of coaching? 20 days? 10 days?

How about FIVE days?

I am actively seeking and working with clients who want to  explore this idea with me. We are working from the premise that “perfect” is no more than FIVE TOTAL DAYS  of coaching to reach a goal of org-wide self-sustaining Agility.

Is this definition of perfect even remotely possible to reach? We are finding out.

Currently, we in the Agile community consider it normal for a coach to set up camp at an organization and “embed” or “integrate” there for months on end. Sometimes even years. This makes absolutely no sense to me given the lack of genuine and lasting results these client organizations are actually getting.

So instead, I am working with clients, and doing many small experiments, in service to the idea of absolutely minimizing the number of coaching days required. To do this, radical new techniques have to be identified, developed and completely tested out. The old ways of doing things that are getting poor results have to be thrown out in favor of a all-new and radical approaches that can help get us there.

Current techniques are obviously deficient, because coaches are setting up camp, for YEARS in some cases, supposedly enabling an ‘Agile transformation’. These ‘Agile transformations’ are obviously NOT HAPPENING. Meanwhile, no one is sounding an alarm. Companies seem willing. Money is changing hands. Everyone is happy.

The problem of course is that there is no progress. In some of these organizations, dozens of coaches are working for years with results that are dubious at best. Something obviously has to change here.

Without deviation from the norm, progress is not possible. That’s what Frank Zappa once said. We need to embody this idea. We need to throw out old assumptions, define perfection for the task of Agile coaching, and define and then achieve stepping stones in the direction of perfect. That’s exactly what I am doing with some of my clients in Boston and it is super-interesting to try out some of these new and radical ideas.

I plan to report the results to you, over the summer, as events unfold.

OFFICE HOURS concall for Q&A on The Culture Game Book

Starting in May 2013, you can get direct real-time answers to your questions about implementing the patterns and practices in THE CULTURE GAME book.

Every week, you can now hop on a ‘Office Hours’ conference call where I will take questions, provide guidance, and help you use the book in a bigger way. Perhaps most importantly, you’ll also hear directly from other readers who are implementing the 16 Tribal Learning patterns and practices.

Users of the book are having great success testing the hypothesis that all meetings are games, and that these meetings can be improved by tuning up the game mechanics of meetings.  You’ll hear some success stories on these calls, from readers getting real traction using the guidance in the book. You’ll also hear about what is not working, and participate in dialogue around solutions. We are actually implementing these Office Hours calls as a meeting, one that implements many of the very patterns and practices from the book that we are discussing.

Please watch @DanMezick on Twitter and also this blog post for details on the date and time of the next call. Please save the date of Wednesday April 1 at 630PM Eastern Standard Time for the first CULTURE GAME Office Hours conference call. I plan to post the link for signing up here.

The CULTURE GAME Office Hours calls are limited to just 25 participants. Therefore, do not register casually. Registering is an explicit commitment to attend and participate.  We’ll be doing serious work on these calls, and hearing stories of how readers are employing the book at work, and getting questions answered.

I look forward to speaking with you during the 1st Office Hours call on April 1. Check here and on Twitter for the details on how to dial in!

Next Call:

Wednesday, May 1 at 630PM EST

Phone number and credentials:

Learn More Here and REGISTER

 

 

Engagement & Disengagement Part2: Perceived Progress

In the previous post, I explained how when we are denied a sense of control over our space or environment, we check out, aka “disengage.” When taken to extremes, we might even disassociate. This can happen for example when we experience a trauma.

Knowledge workers need to have a sense of autonomy. Mandates and prescription kill any sense of freedom, autonomy and control. I think there is a pandemic of disengagement at work.

Engagement does require a sense of perceived control over one’s space or environment in my view.

Progress

Even with a sense of control, if there is no progress, then the typical person will disengage and “check out” on you. They usually will not physically exit the room. If you are an authority figure, they may even work hard to appear they are with you. They are not.

We all want perceived progress. If you have ever got off the highway during a traffic jam, to take your chances navigating the side roads, you know exactly what I am talking about.

Without movement and a sense of progress, it is easy to feel frustrated and stuck. Without a progression and some sense of movement, I think it is easy to disengage. And that’s exactly what I do.

Therefore: to kill engagement, refrain from paying attention to creating any sense of progress whatsoever.

Therefore: to kill engagement, do not iterate, because that might provide an opportunity to feed a sense of progress by ending the previous step, reflecting on it, and starting another.

Therefore: to kill engagement, don’t depict progress visually with a burndown chart, task board or other visual device, since that might provide a sense of progress and therefore increase at least the potential for engagement. Never depict the current state of progress in any visual way. To kill engagement, don’t provide a progress bar, checklist of completion, or any kind of scoreboard.

Therefore: to kill engagement, never bring time to the attention of the group, since awareness of the passage of time might arouse people to notice that no progress has taken place since last Tuesday.

I think you get my point.

There is not even the potential for engagement without a sense of progress combined with a sense of control. The good news is that it is really, really simple: deliver a sense of control and a sense of progress and you deliver the conditions under which engagement can happen. And yes, engagement can be designed.

Experience design. It’s a big deal, and can be simple, if you get the fundamentals right. If more and more of us start thinking of ourselves as experience designers, we can create engagement where we live, were we play and especially where we work. It starts by acknowledging that everyone wants and needs a sense of control before they can authentically engage. Then it continues by acknowledging that we all need a sense of progress before we can continue to engage in any sense of that term.

Perceived Control + Perceived Progress = Potential for Engagement

en·gage

/enˈgāj/
Verb
  1. Occupy, attract, or involve someone’s interest or attention.
  2. Cause someone to become involved in a conversation or discussion.

See also:

How Good Games Deliver Happiness and Learning

Engagement & Disengagement, Part1: Sense of Control

Everyone knows what engagement is, even if it is hard to define precisely in words. We know when we are experiencing it. It has to do with immersion and focus and “being there”. Engagement rarely has negative connotation. It’s almost always associated with good feelings.

While the exact recipe for generating engagement at work may be subject to debate, we know for sure how to kill engagement: simply reduce any real or perceived control that people have inside their environment. For example, a simple recipe for killing engagement is to simply reduce the level of liberty and the freedom to choose and decide. When prescription is the norm, we can reasonably expect disengagement. This is exactly what goes on in most knowledge-workplaces. Prisons also create a prescriptive environment that is low on freedom of choice. I’m being flip here.

The productivity increases from agile processes like Scrum come from elevated levels of engagement. It’s really that simple. Productivity and engagement are correlated. Same exact people, higher levels of engagement. Scrum properly implemented helps this to happen.

When Jeff Sutherland talks about doubling team productivity and then doubling it again, in my view the workers were about 20% engaged at the start. Then engagement went to 40% (a double) with the introduction of Scrum and then 80% (another double) after a few more months. This assumes of course people are willingly opting in and not compelled to do Scrum.

In summary: To kill engagement, simply remove any options to decide or to  choose, and make everything a prescription and a mandate. That eliminates any sense of control and with it, any legitimate engagement. The reality of this is self-evident. To reduce engagement, reduce liberty. Liberty means choice, choice means at least the perception if not the actual experience of control. Reducing engagement is a simple matter. Simply replace the option to choose with a mandate. The founding fathers referred to this as ‘tyranny’.

See also:

How Good Games Deliver Happiness and Learning

How to Botch Perfectly Good Agile Adoptions

 

Culture Hacking, Organizational Permaculture & Kanban

I explained to you in a previous post how Kanban supports 12 of the 16 Tribal (team) Learning Patterns [1] found in The Culture Game Book [2]. That post also contains a link to an interesting post that connects Kanban to the Agile Manifesto’s 12 Principles.

Culture Hacking, Permaculture and Kanban

This post identifies an agricultural technique (actually an agricultural-sustainability hack) called permaculture.

Permaculture principles and practices associate with culture hacking in general, and Kanban (in particular.)

A full set of links for all footnotes are provided at the end of this post.

Kanban

Kanban is a method for managing work and work flow. It is visual, and exposes certain things that are going on within a group doing work, and makes those things explicit. In the canonical form of Kanban, it imposes at least SOME structure by also making policies explicit, limiting work-in-progress, and so on. (If you need a primer on Kanban you can reference link [3] to catch up).

Organizationally, it’s hard to object to Kanban, in part because it does not ask very much of you– at least at first. There are few if any  anxiety-triggering changes in current roles, goals, meetings, and artifacts. This makes it easy for everyone to relax, and opt-in to the Kanban game, because Kanban, at least at first, does not seem to demand very much of you. Kanban is something that is easy to insert into the situation. And that ‘something’ is a refocusing of attention on things that matter to work groups, things like “the type of work we are doing”, “the flow of that work”, “the regulation of those flows”, and the like.

Now I want you to notice that when you introduce Kanban, you are actually engaging in the introduction and composition of new elements with existing elements in ways that are complimentary. Repeat: With Kanban, you are engaging in the introduction and composition of new elements with existing elements in ways that are complimentary.

Which brings us to the fascinating topic of permaculture.

Permaculture

Permaculture is a form of agriculture. It is a discipline of design and composition that leads to the sustainable extraction of value from the resulting system. Rather than make wide-scope changes, permaculture practitioners compose complimentary elements in service to sustainability of yield:

Permaculture asks the question, “Where does this element go? How can it be placed for the maximum benefit of the system?” To answer this question, the central concept of permaculture is maximizing useful connections between components and synergy of the final design. The focus of permaculture, therefore, is not on each separate element, but rather on the relationships created among elements by the way they are placed together; the whole becoming greater than the sum of its parts. Permaculture design therefore seeks to minimize waste, human labor, and energy input by building systems with maximal benefits between design elements to achieve a high level of synergy. Permaculture designs evolve over time by taking into account these relationships and elements and can become extremely complex systems that produce a high density of food and materials with minimal input. (Source: Wikipedia [4] )

It’s drop-dead obvious that Kanban is an application of permaculture applied to low-producing social-systems instead of low-producing tracts of land.

Intrigued? Check out these 12 Principles of Permaculture…as you examine the list, map the permaculture concepts listed to what is going on inside Kanban implementations as described in the book KANBAN by David Anderson [5]:

Permaculture Principles

  1. Observe and interact: By taking time to engage with nature we can design solutions that suit our particular situation.
  2. Catch and store energy: By developing systems that collect resources at peak abundance, we can use them in times of need.
  3. Obtain a yield: Ensure that you are getting truly useful rewards as part of the work that you are doing.
  4. Apply self-regulation and accept feedback: We need to discourage inappropriate activity to ensure that systems can continue to function well.
  5. Use and value renewable resources and services: Make the best use of nature’s abundance to reduce our consumptive behavior and dependence on non-renewable resources.
  6. Produce no waste: By valuing and making use of all the resources that are available to us, nothing goes to waste.
  7. Design from patterns to details: By stepping back, we can observe patterns in nature and society. These can form the backbone of our designs, with the details filled in as we go.
  8. Integrate rather than segregate: By putting the right things in the right place, relationships develop between those things and they work together to support each other.
  9. Use small and slow solutions: Small and slow systems are easier to maintain than big ones, making better use of local resources and producing more sustainable outcomes.
  10. Use and value diversity: Diversity reduces vulnerability to a variety of threats and takes advantage of the unique nature of the environment in which it resides.
  11. Use edges and value the marginal: The interface between things is where the most interesting events take place. These are often the most valuable, diverse and productive elements in the system.
  12. Creatively use and respond to change: We can have a positive impact on inevitable change by carefully observing, and then intervening at the right time.

Source: Wikipedia Permaculture Design Principles [6]

Is understanding the language of permaculture a key to understanding and implementing effective culture change in organizations? Probably!

What’s interesting is how the language of agricultural permaculture supports the best incremental-culture-change ideas found in my book THE CULTURE GAME book [2] and the KANBAN book from David Anderson [3].

 

Kanban…is permaculture…applied to knowledge workers. — Alexis Nicolas (France)

 

The Organizational Permaculture Approach

Here is even more support for the incremental, here-and-now permaculture approach, from a blog post, by noted complexity-science authority David Snowden [7] :

So if you want to change organizations, three basic principles:

  1. You don’t lecture management on how they are old fashioned in their thinking, instead you put them into situations and give them tools where old ways of thinking are not sustainable and they have to act differently. If they work it out for themselves its sustainable.
  2. You pick off areas where the pain threshold is the highest, for example (to pick up Agile themes) the interaction between approaches such as Agile and the measurement and management practices of the HR function.
  3. You then create approaches that change the measurement and feedback mechanisms that work in parallel with existing methods.

Implications of Organizational Permaculture

  1. Client organizations, coaches and other culture hackers can probably benefit tremendously by studying and applying the core concept of permaculture to the design of interventions. Kanban is an element for designing and composing permaculture learning solutions inside existing organizations.
  2. The most effective culture hacks are probably those that strongly align with the 12 Principles of Permaculture. This likely explains (in part) the success of Kanban [3] and the 16 Culture Game Tribal Learning patterns [2]
  3. We probably need to pay particularly close attention to Kanban case studies, since Kanban is actually a particularly good example of how to introduce and apply permaculture techniques and permaculture thinking to culture change in organizations.
  4. We probably need to search for and find more easy-to-introduce permaculture technologies like Kanban and repeat the pattern. Techniques that can co-exist with what is already there and substantially improve team learning quickly are what we are looking for.

Summary

Kanban implementations are significantly aligned with the 12 core principles of agricultural permaculture. Culture change via the incremental permaculture approach is an interesting idea whose time has come. Most effective culture hacks probably have very strong alignment with the 12 Principles of Permaculture.

 

Footnotes:

[1] Kanban and Tribal Learning (link)

[2] The Culture Game Book (link)

[3] Kanban Explained (Wikipedia entry) (link)

[4] Permaculture (Wikipedia entry) (link)

[5] KANBAN: Successful Evolutionary Change for your Business (link)

[6] Wikipedia: Permaculture Design Principles (link)

[7] David Snowden Blog Post with 3 Big Ideas: “Rose Tinting” (link)

 

Kanban and Tribal Learning

The book THE CULTURE GAME names 16 patterns of learning and describes a means to socialize them throughout your organization. These are called the Tribal Learning patterns in the book. One of these patterns is [Manage Visually]. The book devotes an entire chapter to this powerful learning device. Kanban is referred to frequently in this chapter.

Kanban is more than a simple manager of visual information. When policies are added to Work Item types via the Class of Service feature, Kanban as described in the book KANBAN by David Anderson becomes a powerful interactive game whose goal is to regulate the flow of work and thereby increase overall throughput. Getting into this in detail is beyond the scope of this post. If you are unfamiliar with Kanban I suggest you buy the Kanban book.

In my book THE CULTURE GAME, I describe interactions, meetings, Scrum, Kanban, and membership in social groups (such as teams) as games. But not the kind of games you may be familiar with.  This post summarizes what I mean. The book lays out a framework for “gaming happiness at work” and provides specific steps for doing so. Once again, these topics are beyond the scope of this post. You can learn more about THE CULTURE GAME book here.

This short post looks at Kanban through the lens of the 16 Tribal Learning patterns found in the THE CULTURE GAME book. Exactly how many of the 16 Tribal Learning practices does Kanban implement? The answer may surprise you.

I have identified no fewer than 12 of the 16 Tribal Learning practices implemented directly by Kanban. Not only that, but 3 of the remaining 4 Tribal Learning practices described in THE CULTURE GAME book are indirectly supported by Kanban!

This means Kanban is a very serious device for generating social learning in your organization. It means you have to look at it closely.

Let’s take a look at the rundown:

 

Tribal Learning Pattern as Described in THE CULTURE GAME book How Kanban Implements the Pattern
Facilitate Your Meetings The periodic Operations Review meeting (described on page 159 in the book Kanban by David Anderson) is a facilitated meeting.
Examine Your Norms Kanban looks at how long things normally take, and calls that ‘cycle time’. This is an explicit examination of actual, normal delivery times
Be Punctual Not applicable, although most teams doing good Kanban value the keeping of commitments, for example commitments to deliver, appointments etc.
Structure Your Interactions Kanban structures interactions with upstream and downstream partners through Policies, Classes of Service, Work Item Types. Internally, the team structures the columns and swim-lanes depicted on the Kanban board.
Announce Your Intent Teams using Kanban announce intent via the Cycle time connected to Classes of Service. Cycle time states the amount of time for delivery to the customer.
Game Your Meetings Kanban has a daily meeting where the ‘Kanban’ game is discussed.
Conduct Frequent Experiments Teams using Kanban experiment with adding columns, swim-lanes and new Classes of Service.
Manage Visually Kanban is many things. It is obviously at least a Visual Management tool, and a very sophisticated one at that.
Inspect Frequently Each day the Kanban team meets in front of the Kanban board, discussing the work, and inspecting it visually.
Get Coached Kanban as defined by the book of the same name does not mandate coaching. In practice however, this is often the case. Teams coached in Kanban use may get benefits more immediately. Here is some proof: a rather authoritative blog post from KANBAN author David Anderson on what Kanban coaches do, and do not do.
Manage Your Boundaries Kanban depicts the beginning and the end of the work flow under consideration. Kanban defines and manages input and output boundaries.
Socialize Books Not applicable, although many Kanban implementations use substantial learning library
Pay Explicit Attention This is ‘the name of the game’ in Kanban. Kanban plays a direct role in manifesting a shared mental model of the work, the work flow, and related subjects.
Open The Space The very act of depicting the work flow explicitly in Kanban tends to open the conversational space about what is true, what is false about important, previously un-discussed topic, for example: work-in-process and related limits
Be Playful Every Kanban board is a custom thing that develops over time. Columns, column names, swim lanes, work items types and more are all up for discussion and experimentation.Users can playfully choose certain stickers (insignia) to mean certain things, etc. Kanban is open to playful experimentation.

 

Summary:

Kanban directly implements 12 of the Tribal Learning patterns. As such, Kanban is a serious device for generating Tribal Learning, that is: social, or group learning…or team learning, in your organization.

Kanban is useful for building a shared mental model of the work and work flow. As such, it is serious culture technology and a culture hacking tool for encouraging team learning and innovation in the current culture of your organization.

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.

 

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