Posted on

On Invitation

The act of invitation is fundamentally respectful.

Respect for people is a core, bedrock value of Lean and Agile thinking.

Invitation is therefore fully aligned with Agile and Lean.

We feel good when we feel a sense of control, and a sense of belonging.
Control and belonging make it easy to get (and stay) engaged.

Engagement is good.

When we are invited, we are in control of what happens next. The basic responses are some variation of YES or NO. Either way, the receiver is in control of that response.

In this manner, invitation delivers a sense of control to the receiver.

When we are invited and say YES, we experience a sense of belonging (and membership) with everyone else who also says YES to that invitation.

A sense of belonging is an important aspect of well-being.

Feelings of community (membership and belonging) are associated with health and wellness.

 

The Story

Almost every invitation is an invite to be in the story, and be an author of that story. If I invite you to a dinner with others, you are invited into that story and also invited into writing how that story goes.

Likewise for your Agile adoption. When your Agile adoption is based on invitation, you are inviting others to be characters in the Agile-adoption story and also to be an co-author of that Agile-adoption story.

Inviting others creates engagement, the very fuel of a genuine and lasting Agile adoption.

 

In Light of the Foregoing…

Does engagement actually matter?

Is engagement a critical success factor in Agile adoptions? Is engagement the “secret sauce?”

Is engagement essential?

If it is, you might consider invitation over imposition of practices.

OpenSpace Agility (OSA) is one way to do this. OSA provides a starting point for bringing invitation into your Agile program.

OpenSpace Agility actually works, and it works with what you are doing now. It is used to start new Agile adoptions, and address the issues of ongoing Agile adoptions that are in trouble.

 

Related Links:

OpenSpace Agility explained

OpenSpace Agility testimonial videos (15 minutes each)

 

 

Posted on

Open Agile Adoption: Why It Matters Now

This is a note to organizational leaders and my friends in the Open Space community, folks who want to bring Open Space to every organization that is stuck, and every organization that needs help in getting movement towards a more open culture, whether they actually know it– or not.

Open Agile Adoption and the Current (Uninviting) Workplace

Lifeless work with no meaning is a recipe for depression or worse. We all seek meaningful connection to each other, and our work. An inviting workplace connects us to the work… and each other. People all over the world are signaling that they are not longer willing to tolerate an uninviting workplace.

Creating an inviting workplace is a game. The best move now is to exploit any available entry points.

Where are these opening located?

A perfect and readily available entry point is the now-mainstream adoption of Agile software development methods. The perfect tool for cracking open the world of work is Open Space. By using Open Space meetings inside mainstream Agile adoptions, we can crack it wide open. This is because the Open Space meeting format is super-effective at generating engagement. Open Space meetings, as used in the Open Agile Adoption method, are attended by many key business people who are patrons and sponsors of IT. My experience doing numerous Open Space events inside Agile adoptions shows that from 50 to 65 percent of the attendance is business people with some connection to information technology.

Does that shock you? What might this mean?

These are the facts:

  • Organizations need IT to be more responsive, and correctly look to Agile adoption as a solution
  • Most Agile adoptions are far from robust. That’s the polite way to say it. The way these Agile adoptions are currently implemented does not produce rapid and lasting improvement. Many Agile adoptions are train wrecks.
  • Agile is going mainstream even as traditional ways of implementing Agile are producing marginal-at-best results on a repeatable basis
  • Open Agile Adoption (OAA), based on invitation (instead of mandates) creates at least the potential for much more robust Agile adoptions.
  • OAA is built upon the Open Space meeting design, a design that optimizes increasing levels of engagement.
  • Business people connected to the IT department attend the Open Space meetings via the Open Agile Adoption technique. These people can and carry back very positive and uplifting stories about what is going on in IT into the wider organization as a whole. They will carry and spread the open culture/ Open Space meme.

Open Space Small
This is the secret leverage point: once the business people experience the inviting vibe of Open Space and the good results that can come from a rapid & lasting Agile adoption, the cat is out of the bag.

The horse is out of the barn.

The genie is out of the bottle!

The wider conversations that need to be taking place actually start happening. Beyond the IT department!

The business people who attend tell very positive stories about that meeting.

Open Agile Adoption (OAA) with Open Space is the technique to help you make this happen.

OAA is a tactic in a wider strategy, a means to an end.

Our cover story is that OAA is about Agile adoption, when in fact Agile adoption is actually about cultural change.

Therefore, OAA is about igniting the start of enterprise-wide cultural change, starting in the IT department.

This is where it starts!

OAA addresses the crisis in IT, and the now-mainstream adoption of Agile methods, to usher in a new era of openness in organizations, using the IT crisis as an opportunity, and using Open Space to address it.

If We Cannot Do It Here, It Ain’t Gonna Happen

Now, what this means is very simple: if we cannot successfully bring Open Space into the huge opening created by failed Agile adoptions, it is unlikely any headway can be made whatsoever.

Agile has gone mainstream. Meanwhile, the crisis of weak and failing Agile adoptions represents a huge opening to bring in a new way of implementing Agiity. If we cannot exploit this opening, we probably have NO SHOT at bring more openness into the wider enterprise as a whole. We need to execute well in Agile adoptions if we are to have any shot at the enterprise as a whole.

On Wider Ambitions

We need to do this in steps. I’ve been talking to people who want to just flip some kind of switch, skip the 1st 10 steps, and change the world with Open Space. That just is not going to happen until and unless we are able to routinely get good results using Open Space in the obvious opening: the crisis of failed Agile adoptions. Which is occurring just as Agile itself is going mainstream!

We need to recognize this wave, and ride it.  Harrison Owen’s book Wave Rider pretty much spells this out. We need to identify the waves, and ride them.

If we can routinely improve weak and failing Agile adoptions with the Open Agile Adoption technique, the Holy Grail of enterprise-wide transformation (with Open Space) might be within reach. But: if we fail in using Open Space to successfully reform the way Agile adoption is currently done, we have NO SHOT at the enterprise.

For typical organizations with soul-sucking culture, Open Agile adoption with Open Space represents our best step now for beginning a wider process. A wider process of creating rapid and lasting enterprise-level change beyond software.

To be clear: the OAA technique is a tactical play, and a mere means to an end. It is the right way now, to get the right conversations going, across an entire enterprise. OAA has the potential to reliably and repeatedly bring rapid and lasting change into IT departments in organizations around the world.

Agile adoption as currently practiced gets very weak results, because culture change is hard. Open Agile Adoption represents a different approach: a people-first approach based on invitation… using Open Space. As such, it has the potential to get much better results than current approaches are getting.

It is very hard to argue with great results.

There is an Agile adoption wave. We can get on, and ride it. Right now.

Open Agile Adoption with Open Space is the way to get on.

 

Related Links:

Open Agile Adoption Home

Open Agile Adoption Explained

Deviation from the Norm

Wave Rider (book) by Harrison Owen

 

 

 

 

 

 

 

 

Posted on

Tribal Leadership: Is It a Game?

 

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

 

 

 

 

Here are the 5 progressive stories:

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

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

Games have 4 properties:

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

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

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

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

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

 

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

 

Summary

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

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

Culture, as it turns out, is a game.

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

 

The Relationship to Effective Agile Adoptions

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

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

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

 

Resources

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

Blog Post: How Games Deliver Happiness And Learning

Blog Post: Open Agile Adoption

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

***

 

 

 

 

 

 

 

 

Posted on

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.

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

Military Intelligence

It may come as no surprise to you that some of the most challenging work available in computer science is to be found in the USA military.

A less obvious fact is that some of the most interesting work in the social sciences is also located inside the military industrial complex. (Whether it is OK to take this work if you are ‘opposed to war’ is something we can debate later.)

The Department of Defense Command and Control research project has something to teach you about societal change.

I wrote about this topic some years ago on INFOQ and how it relates to software agility.

Here is a sample of what the military is actually saying now:

Agile people conceive and approach the world and their assigned tasks differently from those who are less agile. In general, agile people have a propensity to seek improvements, are more willing to consider information that is at odds with preconceived notions, and are more willing to be different and take risks. These basic characteristics can be enhanced or suppressed by education, training, and culture. Unfortunately, many organizations, both large and small, suppress agility-enabling characteristics.

 

The changes in warfare reflect the new reality of big data, information asymmetry and other important societal trends. You can browse books and publications on the DoD site and obtain them for free. The site is a stimulating source of interesting ideas about collaboration and societal change.

Resources:

Web Page: About the Dept of Defense Command & Control Research Project

My Article: (circa 2010) on INFOQ: “The Command and Control Military Gets Agile”

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

The Intentional Learning Organization

There is absolutely nothing automatic where group learning is concerned.

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

If learning in groups was automatic, we would already:

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

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

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

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

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

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

That is because learning is uncomfortable.

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

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

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

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

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

 

Posted on

Keith Ray: Thought Pioneer

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

 

 

Quotes:

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

and this one…

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

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

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

2003.Apr.24 Thu

What is Industrial Extreme Programming?

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

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

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

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

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

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

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

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

 

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

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

The new practices are:

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Coding Standard. Have one.

Pairing. As per XP, but not just programmers.

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

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

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

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

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

Continuous Integration. As per XP.

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

The Genius Organization

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

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

The Genius Organization

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

The genius organization:

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

 

Agile Coaching

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

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

Kanban and Scrum

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

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

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

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