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)

 

 

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

***

 

 

 

 

 

 

 

 

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.

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.

How Surprising Service Makes You Happy

I’m proofing a book for a friend and the book is amazing. It’s on culture. I told you before about the Agile Culture Conference and how Agile is a Culture Hack.  In the book, there is a story about really bad service. It’s this story about trying to get a deposit made at a bank by using an ATM that does not work. When I read this frustrating tale of woe, it hit me: no sense of control. No sense of progress.

Now I am telling you straight about why bad service makes you unhappy: it is because bad service associates with a low sense of control and low sense of progress. When your feelings of  ‘no control’ and ‘no progress’ hit a certain level, you completely disengage! It’s like hitting the [OFF] button on a human being when control=0 and progress=0. This is a critical lesson for Agile teams. Agile teams do well when sponsors and Product Owners are feeling a strong sense of control and progress.

Anyone who has examined the DELIVERING HAPPINESS book from Tony Hsieh of Zappos knows about his 4-part Happiness Framework found in the Appendix. I’ve already explained it to you in the post on Gaming Happiness At Work.

This table sums up why bad service makes you unhappy:

Type of Service Sense of Control Sense of Progress
BAD SERVICE… Little or None Little or None
GOOD SERVICE… A comfortable and expected sense of control Comfortable and expected feelings of progress
WOW SERVICE ! A surprising sense of being honored A surprising sense of leaping forward (leveling up) very quickly

 

Remember, we expect a certain level of service. Expecting something comes from experience. When you expect something, it matches your model of reality. When you are surprised, it doesn’t.

Ok, why do you care? How does expecting something, and sense of control and sense of progress play out in business? Simple:

GOOD SERVICE is the expectation! No one gets a gold star for merely good service. Good service delivers the expected sense of control and progress.

WOW service makes you feel good by OVER-DELIVERING on a sense of control and a sense of progress.

BAD SERVICE is irritating precisely because it delivers a sense of control and progress that is far less than expected.

MORAL OF STORY: Under-promising is a good idea. Do it. It allows you to over-deliver and that makes people happy.

MORAL #2: If others in your market space are always over-delivering, the definition for ‘good service’ goes up. If you do not notice this, you have been checkmated. Your customers automatically disengage and do not tell you why. They just LEAVE.

MORAL #3: If you make over-delivering (WOW) your standard, you change the game for your competitors. They have to constantly “level-up” to compete, and they are always chasing your (re)definition of what is expected!

Summary:

Great service makes customers happy by delivering a strong sense of control and sense of progress. That makes customers feel good. When they feel good about your product or service, they feel good about you.