Posted on

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

 

 

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

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.

Posted on

Cognitive Recycling

I teach #Agile teams that when gathering requirements, it’s best to intentionally leverage the “back of mind” of all the participants. This is what I call a cognitive leverage point in team learning. To make use of this, you must restructure your meetings, to leverage the unconscious….the back of the mind.

…it works like this:

We have all participated in long, soul-sucking meetings without breaks, where we are on a kind of death march to complete the meeting. These meetings are highly demotivating…. and also completely ignore (and therefore do not leverage) the extremely powerful “back of mind” feature of human cognition.

The trick is to STOP having long meetings. Especially when working on sense-making!!

Instead, for any kind of important group sense-making task, like requirements-gathering, schedule several short 1-hour-or-less meetings, 1 per day. The first meeting is short, and highly focused, some work gets done….and then it ends.

However, we ALL KNOW that tomorrow we are doing this meeting again. This is where it gets interesting. The game is just beginning…

 

Cognitive Recycling

Everyone in the group keeps ‘cycling’ and working in the problem when in the elevator, when commuting home, when winding down at home, AND when sleeping. They “work” on the problem, “back-of-mind”, for 24 hours…even when sleeping. (Participants report dreaming about the work in between meetings.)

They anticipate and expect the next meeting the next day, and because of this, they tend to integrate learning, from the “back-of-mind”,  even when sleeping. They iterate and re-iterate…cycle and recycle…using the unconscious “back of mind”.

The next day, the deeply integrative learning goes to the front-of-mind, where it is accessed and used to advance the task at hand with the group during the meeting. This occurs at every meeting.

 

Cognitive Recycling and Permaculture

Cognitive Recycling is a way to get people “thinking” 24X7, even while doing other tasks. It leverages your “backchannel” or back-of-mind, by setting up a clear purpose for a meeting, and some anticipation…via a predictable and scheduled rhythm, or cadence.

As a practice it honors several of the 12 permaculture design principles:

  • Catch and store energy;
  • Use and value renewable resources and services;
  • Produce no waste; Use small and slow solutions;
  • Use edges and value the marginal.

My clients report the following:

  • A sense of control, stemming from a set of predictable, short, clear-purpose meetings
  • A sense of progress, stemming from increased daily insights and ‘ahas’
  • A sense of membership in the task at hand
  • Strong feelings of integration and satisfaction with the work and the people doing it with them

Simple Steps for Cognitive Recycling:

To leverage the effects of cognitive recycling, follow these steps:

1. Replace a planned meeting of N hours with N meetings of 1 hour each, on successive days. For example for a 5-hour meeting plan five or 1-hour meetings … on successive days.

2. Schedule the meetings for the same time each day. This is effective, because it establishes the regular period or cadence, which is essential.

Team and organizational learning is NOT random— I teach that we must intend it. Group learning is not automatic. What is nearly automatic is low levels of learning when people gather in groups. Group learning is no accident.

Learning leverage is what you get when you leverage the unconscious processes of the brain. When a group of people actively do this together, leveraging “back-of-mind”, the volume of excellent-quality results can be quite astonishing.

Cognitive Recycling. Give it a try. It’s a technique of  Organizational Permaculture.

(NOTE: This and other strong techniques for group learning are described in detail in my book, THE CULTURE GAME.)

 

Please investigate and consider joining the Organizational Permaculture Facebook group. In this group on Facebook we are mixing people from the agricultural permaculture movement with folks from organizational development, agile coaching, culture hacking and others tribes who are interested in this concept.

 

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

Pioneers in Thought Leadership

I am actively looking for people who have been linking Agile to the Learning Organization concept before 2012. Specifically, I am looking for folks who have written anything in books, papers and blog posts predating 2012, that explain how Agile practices are actually the A-B-C steps to building a small Learning Organization that we currently call a Team.

Here are some of the links I have received so far. These links show how pioneering thinkers have been VERY CLOSE to the idea that Agile practices actually are the A-B-Cs that get a group to start engaging in patterns of behavior (the Tribal Learning Patterns) that literally manifest the Learning Organization in small groups.

These are the pioneering thought leaders, the true trailblazers:

Chris Matts: 2003, web page:

http://abc.truemesh.com/archives/000107.html

“…Agile is Learning…All Agile principles and practices are based upon feedback and learning. ”

Chris Matts: InfoQ interview: 2010

http://www.infoq.com/news/2010/05/learning-machine

“…I want the the Agile community to know that the community is in fact a learning machine….. and it is broken. If something is not done to fix it, it will only last another couple of years before it fragments and something else will rise to replace it.” (NOTE: Please examine www.TheCultureGame.com and www.CultureConference.org)

“…I recently wrote a blog post where I state the Agile Manifesto is actually a call to arms to create a software learning community. This is not a recent view of Agile although it is a recent reflection on the manifesto.”

 

Keith Ray, circa 2003, via his blog:

http://homepage.mac.com/keithray/blog/2003/04/24/

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

NOTE: If the above link is broken, USE THIS ONE: http://newtechusa.net/agile/keith-ray-thought-pioneer/

Keith Ray: A link from Keith Ray circa 2003…

….that covers QUITE A FEW of the Tribal Learning patterns that Agile practices encourage…..no direct mention linking Agile practices to the manifestation of the Learning Org…

http://tech.groups.yahoo.com/group/extremeprogramming/message/82917

There’s a company that provides facilitators and arranges events for
other companies to help them think about their problems. They get a lot of people together in one room (they have places in various cities for
this purpose), and do various exercises not unlike some described in
Norm Kerth’s book on Retrospectives, and among other things do a log of
writing on sheets of paper on the walls.

 

 

 

 

 

Posted on

Agile Implements a Learning Organization

Senge wrote a description of “the Learning Organization” in his 1990 book, THE FIFTH DISCIPLINE. That book and subsequent books by him and others made it obvious:

Manifesting a Learning Organization is far more difficult than describing one.  (The Culture Game book, page 23)

In my book The Culture Game, I explain the following:

1. The software development environment is a complex and harsh place to actually SHIP anything, unless and until you get the “team” thing figured out;

2. The harshness of this situation, leading to colossal failures in software development, costing tens of millions in some cases, led to the Agile Manifesto and the Agile movement;

3. Agile practices, under the “cover story” and mandate of streamlining software engineering, have actually cracked the code on how to build a true Learning Organization, a small-sized unit we call a Team. The Agile movement has blessed the world with this work. We now know how to build a organization that learns….we know how to build a Genius Organization !

4. Agile practices actually build small Learning Organizations. We call them Teams.  If we distill and extract the lessons learned from Agile software development, we can build Learning Organizations at scale. This is the entire premise of The Culture Game book.

Now I am looking for others who have asserted this idea before 2012 in a book. I want to identify and interact with and HONOR these authors!

So…..

I am now asking you for help:

If you know of any book published before 2012 that asserts that Agile practices are in fact A-B-C steps for building a genuine and authentic Learning Organization, please send me the Amazon link.

Send it to:  dan [at] newtechusa <dot> net

I am very interested in honoring any book authors that have made this connection.

I believe we are on the verge of extending Agile ideas and genuine organizational learning from teams to tribes and eventually, to entire enterprises.

Thank you for your help !

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

Mandated Collaboration: The Recipe for Botched Agile Adoptions

Here is a sure-fire way to virtually guarantee a failed adoption of agile or Scrum:

Simply have an authority figure, preferably the CEO, announce with great fanfare to the entire organization  that we are “going agile”.

To really make sure you definitely create a colossal train wreck of truly epic proportions, be sure to specify a hard date, the date when the entire organization is “going agile”.

The folks may start rolling their eyes, making sarcastic and sour faces, crossing their arms, shifting their feet…in other words, disengaging.

Why would mandating FORCED COLLABORATION be a bad idea? Why is it a bad idea to CHANGE EVERYTHING on people without asking them what they think? Why is mandated collaboration a very bad idea?

1. IT KILLS OPENNESS. It signals that whatever people actually think, feel, believe and want is NOT valued. (If we value what you want, think and feel, we’ll signal that by asking you what you want, what you think, etc.)

2. IT KILLS INITIATIVE. The very people who can help spread good agile in your organization are not getting a hearing. By this I mean the people who are capable of thinking for themselves, and have an independent streak in them. By announcing the “agile adoption” without checking in on what people might think, you send a signal that is OPPOSITE the Scrum value of Openness and OPPOSITE the Agile Manifesto value of [Individuals and Interactions]. Good job !

3. IT KILLS ENGAGEMENT. By announcing like that, you signal that AUTHORITY remains where it currently resides: with the command-and-control higher ups. Good luck getting people to self-organize themselves in that scenario. You just told them it is OK to check out and DISENGAGE, since authority is not about to be getting shared.

4. IT KILLS ANY SENSE OF CONTROL PEOPLE HAVE. By announcing like that, you make enemies of the people who might be allies. The people who CARE actually complain a lot, usually 1-to-1 … to colleagues and friends. Do you really think you are going to score points with people when you reduce their happiness? Do you really think you make people happier at work by making all of the decisions that affect them… at work? When you announce change like that, you botch the agile adoption by reducing the perceived sense of control people have. Good job !

5. IT KILLS ANY SENSE OF PROGRESS. By announcing like that, you kill any sense of progress. You make agile look, feel, and smell just like every other FAILED change initiative such as Six Sigma, CMMI, re-engineering, et al. Announcing authoritatively sends the clear signal that ABSOLUTELY NOTHING HAS CHANGED.

Summary

You cannot get people on the bus by barking the agenda and signaling that feedback is not valued.

That is the very antithesis of agile!

You get them on the bus by asking them what they think. Agile is getting a huge black eye as it “goes mainstream”. The same old patterns of command-control are being played out as new ‘agile’ terminology is being used as a cover story for disrespecting the people who do the work.

Add to this the fact there is always an ‘Agile coach’ to help well-meaning but misguided or misinformed “leadership” do whatever it wants with ‘agile’ (provided the price is high enough) and we have a train wreck of epic proportions being played out in enterprises around the world– especially in the USA.

Especially in Boston!

You might be asking: what is the solution? It is really very simple: Create a space where the folks get HEARD. The folks know the work. Why not ask them what they THINK about AGILE before rolling it out? Since this almost NEVER happens, 99% of ‘agile adoptions’ are train wrecks that associate with diminished feelings of control, diminished feeling of progress and diminished feelings of teamwork with “leadership” and authority. Did I mention diminished feelings of being respected?

 

The Culture Game book has an entire chapter devoted to the idea of opening the conversational space as a requirement for a successful agile adoption. The folks that do the work are going to get a hearing one way or the other. The only real question is how leadership chooses to manage the inevitable expression of what people want, what people think and what people feel.

***