Posted on

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)

 

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

Agile Coaching Values

Agile Coaches are familiar with the patterns of naive and vulnerable client organizations that are new to Agile. In my view, Agile Coaching pros have an obligation to help clients understand what is best for them. This always includes helping the client take 100% responsibility for their own learning. This usually means the coach must refuse opportunities to play a larger role.

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

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

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

 

In serving our clients, we have come to value:

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

 

We use these Principles to guide our work with clients:

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

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

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

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

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

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

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

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

Posted on

Estimating and Team Learning

There is a big debate out there about the value of estimation on Agile projects. There are two items that need to be distinct when we talk about this. The first is estimation as a Team Learning activity. the second is estimation as part of the basis for planning.

Let’s look at team learning first:

Estimating as a Team Learning Activity

The primary value of estimating (as a group) is in the team learning. The estimate “deliverable” is secondary. Repeat:  The primary value of estimating (as a group) is in the team learning. The estimate “deliverable” is secondary.

Planning poker in particular provides a structure for making sense of the estimating task and the learning that comes from that. When teams estimate with planning poker, they are learning about the work, and EACH OTHER.

Not Understanding Requirements Creates Anxiety

Agile processes are patterns and practices that increase sense-making at the level of group. When we do not know “what a requirement means”, we worry about it. When we know what something means, like a requirement, that reduces anxiety by increasing the perceived sense of control. A sense of control makes us feel good. We know what it means. That reduces worry about what to do next.

All Learning is Change, All Change Creates Anxiety. Therefore: Learning Creates Anxiety.

All learning is change. Change is stressful because the process of change reduces the “known” and/or increases the “unknown”. The ratio of “unknown items” to “known items” goes up when the process of learning is taking place. The initial process of learning creates a progression from the known to the unknown.

Knowing where you are is very comforting. Not knowing is stressful. Learning is de-stabilizing and causes stress. Learning causes you to shift from the known towards the unknown as you engage in the learning process. The process of learning creates substantial instability…until your new learning is fully integrated.

Lack of Structure Creates Anxiety

As if the process of team learning was not already problem enough, we also have the structure problem. This is a social problem. People feel stress when structure is lacking. We also tend to feel a sense of control when we are participating in well-structured social activities.

Ritual Creates Safe Space for Learning: Planning Poker As Ritual

Now let’s discuss estimating using planning poker. As stated previously, the primary output from the activity is learning, not the estimate itself. The act of estimating using planning poker is a ritual activity whose goal is manage the sense-making, and the subsequent integration of the know-how.

Planning poker is a ritual. A ritual provides known A-B-C steps for beginning, experiencing and completing a journey through the learning. A planning poker session that is facilitated can be viewed as a ritual of learning that manages the state of “not knowing”. The planning poker ritual provides structure and a predictable experience of dialogue and structured learning.

In summary: team learning creates instability. This ambiguous state of being is best managed with predictable rituals that help in getting from here to there.

With the discussion of team learning behind us, we can now talk about a very basic problem: using estimates for planning.

 

Almost All Estimates are Wrong

Estimates are usually wrong. Especially early in a project, not much at all is known. Any estimates are flawed. Pretending this is not true does not make the reality go away. What usually happens is, we take these flawed estimates, use them for projections of cost, features, delivery date, and quality. We then make commitments that are binding between the development team and the product owner and/or project sponsor. This is a serious error in many dimensions.

Almost All Rituals are Good

That said: we can argue that Agile methods manage the instability inherent in all team-learning. Planning poker, for example, is a well-understood ritual for generating team-learning as a primary side effect of producing an estimate. We can say that each Scrum meeting is a kind of team-learning ritual.

Are Scrum Ceremonies Actually Rituals That Help Manage the Instability of Learning?

Yes. Jeff Sutherland and Ken Schwaber refer to Scrum meetings as ‘ceremonies’ in the Scrum literature. This is very telling language.

Could it be that Scrum is actually implementing a repeatable series of rituals that are managing the in-between, destabilizing nature of team-learning?

What is Planning Poker Really?

Planning poker is a team-learning ritual that is focused on understanding software requirements. The planning poker ritual is predictable, repeatable, and structured. While maybe 3% of all agile teams are comfortable in total ambiguity, the other 97% need rituals to help them impose some structure on the  process of generating (destabilizing) team learning.

We can argue that Scrum ceremonies like the Retrospective are also rituals that are managing states of uncertainty. They provide structure to help navigate the often ambiguous states of being that are created during team-learning.

What Can We Do?

We can do the following to advance the state of the art:

  • Admit that group-estimating procedures like planning poker are actually rituals that are helping to provide structure during learning states;
  • Admit that the true value of estimating is the generation of team-learning and not the estimate itself;
  • Admit that estimations are tremendously under-rated precisely because estimates (even when incorrect) serve reduce the “sense of ambiguity” that comes from not knowing the ultimate cost of a project;
  • Design useful, customized and tailored agile-learning rituals , beyond planning poker, which manage the ambiguous nature of team-learning.

The moral of the story? It ain’t as easy as it looks.

Related Links:

Sense-Making: http://en.wikipedia.org/wiki/Sensemaking

Posted on

Authority Explained

I told you before about the difference between authority and power. Now that we are holding these working definitions, we can drill down…and deconstruct authority in more detail.

I’m drawing from Group Relations work here, and providing actionable guidance for thinking about authority. I am purposely being minimalist here, providing the essentials only.

Remember, authority is defined here as “the right to do work“. Also, keep in mind that authority is always something conferred. It is given, and can be taken away.

Formal Authority

Formal authority is what is conferred when you occupy a formal Role, for example, when you become Treasurer of a non-profit organization. That role comes with a Title, and a collection of Tasks (“work”) you are formally authorized to do. Police for example are formally authorized to enforce the law.

Personal Authority

Formal Roles are well-defined in theory and actually have much more that is undefined and ambiguous. How far can I go? What are the limits of my authority around a task? Etc. It is here that your approach comes into play. Personal authority is your personally held, “perceived right” to do the work a certain way. 

The policeman that pulls you over can let you go without a warning. That policeman makes a decision about how to handle his role in a given situation.  That’s personal authority.

We are all familiar with ‘overstepping’ authority and the related dysfunctions of that. Like a policeman who tries to make you let him into your home when he knows for a fact that he can’t make you let him in, unless certain other conditions are true. That cop is attempting to over-step the formal authority boundary of a role.

 

Understepping and Overstepping

We are far less familiar with ‘understepping’, that is, not fully “taking up” a given role.

This is a bigger and far less understood problem!

When your sense of personal authorization prevents you from fully occupying your formal Role, serious dysfunction results. Why? Because you leave what I call “scraps of authority” lying around. If you do this on the job, for example as a Manager or Director,others are unusually quick at picking these these scraps up, and using them outside of the Role they are intended for– the one you are occupying!

The distortions created by this cause a range of organizational illnesses- a.k.a. “dysfunctions.”

 

Informal Authority

Informal authority comes without formality: without a formal Role and related title, etc. It is the authority that most of the others confer to you. Most of “the others” may or may not occupy formal, highly authorized Roles.  (Usually it is a mixture of people in various Roles.)

The source of informal authority is the willingness of others to have you do some specific work.

We all know of people who get loads of critically important work done, yet they do not occupy a “higher-up”,  formal Role (with formal authorization) inside the group. Yet these folks seem indispensable to how the team or organization functions.

What gives here?

Informal authority shows up as influence. It’s the conferred right to do certain kinds of work. It is conferred from others. It’s based on reputation, and a certain kind of willingness on your part. It is offered to you, and can be accepted by you…or not. It can be given, and taken away.

Summary

I just defined the following for you: formal authority, personal authority and informal authority…subcategories of “authority, the right to do work.” I hope you find these definitions useful. In the next post, I will deconstruct influence, that available-to-everyone, “always-on” ability to literally cause a shift or “change in state” in our socially constructed universes. I plan to discuss willingness, roles, and being “drafted” into roles…with and without your consent.

social construct:

a perception of an individual, group, or idea that is ‘constructed’ through cultural or social practice.

 

Related Links:

http://newtechusa.net/agile/authority-and-power/

http://akriceinstitute.org/displaycommon.cfm?an=1&subarticlenbr=34

https://twitter.com/DanielMezick