Ending In Open Space

(NOTE: This lesson assumes you understand the Open Space meeting format.)

 

At the 2016 AGILE ISRAEL conference event, I was honored with an invitation to keynote. Six hundred people in one room. Kind of scary…

….I asked for a show of hands: “…how many of you here have ever attended a meeting of at least one day, where the progress of the Agile transformation itself was inspected by everyone in the room?” About 40 hands went up.

Then I asked “…please keep those hands up. Next, how many of you have attended such a meeting, where absolutely everyone affected by the Agile transformation was invited, not just the ‘higher ups’ ?? ”

Thirty-four hands went down, leaving only 6 people remaining. In other words, in Israel, about 1% of all Agile adoptions are ever inspected by the-group-as-a-whole.

Is it smart to include and engage everyone in the overall process of changing?

Consider these fundamental aspects of Agility:

  • Empiricism
  • Experimentation
  • Iteration
  • Inspection
  • Adaptation
  • Pull
  • Self-management and self-organization

 

This kind of begs the question: how is it that we can successfully implementing Agile in an enterprise, without applying these Agile ideas to the enterprise transformation itself?

The answer of course is that we can’t actually be successful without taking an Agile approach to Agile transformation.

 

The very best way to get valid data on the progress and status of the Agile “transformation” is to invite everyone to inspect the progress.

A very excellent idea, and the one I am suggesting now, is to make sure you are periodically “ending in Open Space.”

In a previous lesson I told you to Start in Open Space and I gave you good reasons why. Now let’s discuss ending in Open Space.

 

If you get in the habit of “ending in Open Space,” the following good things are going to happen:

If the whole organization knows that an Open Space (“all hands”) meeting is going to happen in a few months, and that the whole Agile thing will be inspected there, by everyone, they will “suspend disbelief” and “act as if” and “pretend” the experiment with Agile practices could actually work. (If you are several years into your “transformation,” then the inspection is about your current state and the experiments you are doing. You are doing experiments- aren’t you?)

Because Open Space is an invitational (“opt in”) meeting, you’ll be able to see who attends and who is absent. This is very valuable data.

  • At the Closing Circle, you’ll be able to see who is really feeling passionate and responsible about the process. Many (if not most) of the people present at the Closing Circle are the very people who care the most about the success of the Agile transformation effort. These are the people who can and will propel the effort forward.
  • The Open Space meeting will generate a tremendous level of self-management and self-organization. Discussions in the meeting will provide rich detail on what impediments need to be removed at the enterprise level.
  • The Open Space “all hands” meeting provides a closure point for an “enterprise iteration of learning and progress.” Without that punctuation-point, the group can and will suffer from one.endless.experience.that.never.ends.

People are junkies for progress. So create a punctuation point. And an ending. An enterprise-wide iteration that begins and ends in Open Space.

An ending ends one thing, and starts another. Endings create beginning. And then we go again.

Iteration. Inspection. Adaptation.

At the enterprise level.

With everybody.

 

Agile Coaching Lessons:

[<- Previous Lesson]   [Next Lesson–>]

[Table of Contents]

 

DanMezick_CC_2-281x300

If you find value in these essays and find yourself curiously drawn to them, consider investigating OpenSpace Agility, and/or  following me on Twitter and/or joining the OpenSpace Agility group on Facebook

Only The Engaged Can Actively Self-Manage

The self-organization of teams is a tremendously misunderstood topic. The writing on it tends be inconsistent and yes, even incoherent at times. This brief lesson takes a swing at being both consistent and coherent.

Lessons 04, 05 and 06 gave you a basic understanding of some key concepts and the relationship between “self organizing teams,” self-management, and decision-making.

Every KPI (key performance indicator) that you are measuring is dependent on the level of self-management that the teams and the wider organization are exhibiting. No self-management, no KPI improvement. This is simple correlation and is not complicated.

You already know how to test for high levels of self-management from lessons 04, 05 and 06: just personally ask a few individuals from a team or group how they make decisions. If you get the same very consistent and coherent answer, you can be sure they are self-managing. This is because self-management is about managing decisions, not people.

Repeat: self-management is about managing decisions, not people.

This is all very nice. It all sounds so good. Doesn’t it? But wait: what are the common impediments to achieving self-management, and how do we remove these impediments?

The #1 Impediment to Self-Management

The top impediment to self-management in teams is a lack of engagement. If the team members do not care about what they are doing, self-management (and lasting KPI improvement) is NOT going to happen. There is no such thing as a “self managed team” without very high levels of engagement by and between the members. Pushing Agile practices on teams cannot help you here. Pushing practices on teams without their full and informed consent is not advised.

So how will we engage these potentially disengaged teams?  If the teams are not making decisions, or if most of the team’s decisions are made for them, you are going to have a very difficult time achieving self-management.

Teams need to be making decisions to stay engaged, and there’s no such thing as a self-managed team that is not engaged. In other words, “decision making by teams” and “self organization of teams”  are both intimately connected.

They are practically the same thing. One follows the other.

A primary way of generating a team-level decision is to invite the team to do something.

An invitation is a request for a decision.

Decisions are engaging. And only the engaged can self-manage. And self-management is where all the “continuous improvement” comes from.

Therefore, inviting is a necessary and essential tool of the trade in Agile coaching.

 

Can you see why?

 

Agile Coaching Lessons:

[<–Previous Lesson]    [Next Lesson–>]

[Table of Contents]

 

DanMezick_CC_2-281x300

If you find value in these essays and find yourself curiously drawn to them, consider investigating OpenSpace Agility, and/or  following me on Twitter and/or joining the OpenSpace Agility group on Facebook

Agile is a Game. Agree About The Rules

In the previous lesson, I taught you about how word definitions are agreements, and how agreements are essential to success with Agile. Once you get everyone involved to agree on the definitions for Agile and Scrum, you are in position to go all the way by seeking and obtaining everyone’s commitment to success with Agile. It’s all very simple but you have to go step-by-step and do all the steps just like I tell you.

So here is what you do: you already have everyone’s agreement that the Manifesto is the definition of Agile (2 pages) and the Scrum Guide (less than 20 pages) is the definition of Scrum. That is Step 1.

Step 2 is to go and ask (ASK) everyone involved to play by the rules of Scrum (which is a GAME by the way) for 6 or 7 iterations. If they are unwilling, ask (ASK) for them to agree to play by the rules of Scrum for 3 or 4 iterations. Or 2. Or ONE. Ask (ASK) for their agreement.

These are the roles you need to have very specific conversations with:

  • All the stakeholders
  • All the execs, directors, and managers
  • All the Product Owners
  • All the Scrum Masters
  • All of the Teams
  • Anyone else you can possibly think of

It is essential that you do this. Do NOT rush this Step and DO NOT skip it. Get it done. With each person in each role, explain clearly what is expected, what is permissible, and what is out of bounds. Clearly explain the boundaries of each role, and the specific tasks. Make sure everyone understands. Ask them to ask questions. Do not rush this.

It is best to scope the agreement to a specific period of time, like 7 or 8 iterations. This way, it is easier for everyone to commit. Making it temporary (and inspectable later) also teaches some core ideas about iteration, experimentation, inspection, adaptation, and so on.

Just go ahead and live these things out. That is your very clear message to them. Live it out. See how it feels. Give it a try, this Agile thing. For real. Tell them no one will get hurt, that you have led people through this many, many times. Because you have.

 

It is usually a very good idea (no joke) to GET IT IN WRITING as Step 3. After they signal they are OK agreeing to this. Get it in writing if you can. Make it very real. Make it kind of scary.

Now you are in position to really be successful. Here is why:

  1. There is a sense of community now– everyone shares in the same basic agreement. The agreement is about THE RULES OF THE GAME. Which everyone is about to play.
  2. There is clarity. Everyone is clear on roles and responsibilities. Or so it seems, for now (!!)
  3. You and the Scrum Masters you are teaching can now assert yourselves, strongly if necessary, by reminding executives, directors, managers, stakeholders, Product Owners, Scrum Masters, Teams and everyone else involved….about their commitment to the rules. About their commitment to their AGREEMENTS with you and everyone else.
  4. When the Teams start Scrumming, you can remind them that they AGREED to do a Daily Scrum Meeting.
  5. When the Teams start Scrumming, you can remind the executives that, per the Scrum Guide, they must signal and execute on real and deep respect for the decisions of Product Owners.
  6. When the Teams start Scrumming, you can remind stakeholders that the scope of work in a Sprint cannot be changed in an ad hoc way. Ever.

Now when it gets crazy, YOU CAN REMIND PEOPLE OF THEIR AGREEMENTS. This is Step 4. And because it is time-boxed with an end-date, you can very firmly remind them of how very reasonable the entire arrangement is.

The next Step is to coach everyone through the experience. This is Step 5.

The last Step is to inspect everything. Especially the great results everyone is getting.

Summing up:

  • Step 1 Get agreement on definition of Agile and Scrum
  • Step 2 Get agreement to play by the rules of Scrum (for teams that are doing Scrum)
  • Step 3 Get the agreement in writing
  • Step 4 Remind people about their commitments when the trouble starts
  • Step 5 Coach them through it. You have permission now. GO FOR IT
  • Step 6 Teach them how to inspect and adapt

 

The alternative– starting in some other way– is almost guaranteed to FAIL.

This procedure, in six Steps actually works.

Especially those FIRST THREE Steps.

Can you see why?

 

Agile Coaching Lessons:

[<–Previous Lesson]    [Next Lesson–>]

[Table of Contents]

 

DanMezick_CC_2-281x300

If you find value in these essays and find yourself curiously drawn to them, consider investigating OpenSpace Agility, and/or  following me on Twitter and/or joining the OpenSpace Agility group on Facebook

Definitions Are Agreements

Language is important, especially when everyone is being triggered by changes in the way authority is distributed. Agile “transformations” are no exception.

Also very important are agreements. Without agreements, nothing good can happen. So start your coaching by testing the willingness of the team(s) and the wider organization to make some agreements with itself. Agreements are commitments.

And all of this is very big deal, I assure you.

So here is what you do. You start by presenting the Agile Manifesto and explaining it. Use your imagination. Teach the 4 and the 12.

Once your audience receives this teaching, ask them to agree for say, the next N months (something reasonable for N, like “six) that THIS Agile Manifesto THING is the definition of Agile. That, when we discuss “Agile”, we are discussing “this.” That the definition of the word “Agile” when we use it….IS the Agile Manifesto. That when we say “Agile,”, THIS is what we mean. Those 4 values and 12 principles.

Then, so the same exact thing for the word “Scrum” and use the Scrum Guide as the definition of “Scrum.”

As a coach, you will quickly learn:

  • How much confusion there is in the organization about these fundamental terms;
  • How little (or how MUCH) the people in the organizations are actually willing to actually agree on;
  • How little willingness there actually is to execute on good Agile and good Scrum;
  • Who is “in” and who is “out.” Who is supporting, who is resisting. Very simple.

As you coach, always frame the use of these definitions as “temporary” and “just for now.” This way, you reduce the objections by being reasonable. By being kind. Be being a good teacher. A good leader. A reasonable person: it’s not FOREVER. Just for now, lets use these definitions. Let’s “agree” to them.

If anyone disagrees and absolutely cannot get in, ask them what has to change (what has to be TRUE that is not yet TRUE) for them to get in. Ask them what it will take to get them in. Work it out. Get them in.

Now, when you get everyone in, when everyone agrees to these two definitions, you have really achieved something: something very GREAT:

  • There is a shared agreement, and everyone is accountable to that agreement;
  • You now speak with much more clarity when you say the words “Agile” and “Scrum;”
  • You have set up the entire organization to be much more clear about what it says to itself;
  • You have helped them achieve an agreement ABOUT SOMETHING VERY IMPORTANT to success with Agile;
  • You have greatly expanded the “adjacent possible” for this organization’s transformation.

There is a method to your madness here. In the next step, you will invite them to play a game.

A very serious game. A game you can all win together. A cooperative game.

 

Agile Coaching Lessons:

[<–Previous Lesson]    [Next Lesson–>]

[Table of Contents]

 

DanMezick_CC_2-281x300

If you find value in these essays and find yourself curiously drawn to them, consider investigating OpenSpace Agility, and/or  following me on Twitter and/or joining the OpenSpace Agility group on Facebook

The PUSH of Agile Causes “Trance Formations”

AGILE COACHING LESSONS: “Trance Formations” and the Hawthorne Effect

Push-style “transformations” look good at first, and do not last long. What is actually going on there is this: the Hawthorne Effect. It turns out that when you make a change in a workplace, like changing the brightness of lights for example, the productivity goes up temporarily and reverts back to the mean. It is not lasting. If you wait awhile and dim the lights down a little, same thing. Changes like this cause short-lived increases in productivity. When people are being observed as changes are being made, they temporarily change their behavior.

What’s being sold as “Agile transformation” today are mostly short-run productivity increases that do not actually last. Temporary improvement, based on the Hawthorne effect. New procedures, new consultants, new teams, new practices, etc. Observation. The productivity increases from the Hawthorne effect are very misleading. They do not actually last. They are 100% temporary. There is no actual “transformation.”

Starting with Lesson 4, I explained to you the dynamics of self-management. A little later on (in Lesson 14) I explained how making decisions triggers very high levels of engagement. And how engagement is where all the improvement actually comes from. All of these topics are related: decision-making, engagement, self management, and great results. One begets the other.

Engagement is the name of the game here, and you get it by inviting teams to make some decisions that affect their work. Scrum defines some decisions that only the teams are authorized to make. There’s a good reason for that.

If you are “helping” the team to make these decisions, you are discouraging self-management and self-organization. And this is where all the improvement (if any) is going to come from.

So stop doing that. You are generating disengagement and causing team members to “check out.”

You are creating “trance formations.

 

Push

If you are party to the PUSH of Agile on teams without consent, you are part of the problem. You’re pushing Agile practices, and making most all the decisions for them. Or even worse, you are literally “looking the other way” while authority figures in the organization make decisions that the teams literally need to be making to stay engaged.

So stop that. And do these things, instead:

  1. Encourage executives and managers to refrain from making decisions for the teams that Scrum very clearly defines as belonging to those teams.
  2. And then, encourage teams to make the decisions that Scrum says are theirs (and theirs alone) to make.

 

And after a while, everything will start to improve. In a lasting way.

Because the teams are actually engaged in the difficult work of making decisions as a team.

 

See also: The Hawthorne Effect (link)

 

Agile Coaching Lessons:

[<–Previous Lesson]    [Next Lesson–>]

[Table of Contents]

 

DanMezick_CC_2-281x300

If you find value in these essays and find yourself curiously drawn to them, consider investigating OpenSpace Agility, and/or  following me on Twitter and/or joining the OpenSpace Agility group on Facebook

Engagement Is Everything

 

Self-organization in the enterprise context is self-management, and self-management is primarily the management of decision-making. There is no self-management without decision making. Self-management IS decision-making.

Decision-making is engaging. As more and more engagement is created, more and more of the “cognitive capacity” of the group becomes dedicated and focused on the work at hand. All of the KPI (key performance indicator) measures tend to improve when levels of engagement improve. Results and engagement are correlated. You cannot have one without the other.

This means the central concern of the executives (and the coaches they hire) must be the question of how to raise levels of employee engagement. This is the central concern. All other concerns are secondary.

The primary way to get more engagement is create more opportunities for employees and teams to be making decisions that affect them directly. As it turns out, making decisions is very engaging.

The Gallup polling organization issues a report every year that the workforce is about 20 to 25 percent engaged while at work. This is the same as saying that 75 percent of the payroll expense is a complete waste. That money is up in smoke. Poof. Gone. Raising the level of engagement at your company might be worth tens of millions of dollars per year in new productivity. Engagement and productivity are correlated.

The primary way to raise engagement levels is to do three very specific things:

  1. Very clearly define what decisions the teams are authorized to make. Be blunt and very clear and specific about this.
  2. Always trust them to make those “authorized decisions;” always encourage these decisions and never interfere from outside.
  3. Whenever and wherever you can, look for spots where you can invite the team to make additional decisions.

Item (1) is easily delivered when everyone in the situation (stakeholders, team, etc) agree to work under the rules of Scrum.

Failure to achieve item (2) is a primary reason why most Scrum implementations have BIG problems. Failure here is the cause of a very common Scrum-implementation problem, namely: executives and stakeholders do not play the Scrum game according to the rules. They routinely override team decisions, or even worse, they authoritatively make all decisions for them. To “help” them. This kind of “leadership” behavior KILLS self-management and engagement. It’s stupid. It works against your goals. Don’t do it. (NOTE: If you are not using Scrum but you have “authorized” teams to make certain very specific decisions, you cannot later interfere, and expect anything good to happen.)

We can push Agile practices on teams without respect for what they think or feel about. This is the standard way “Agile transformations” are “rolled out” today. This is a terrible idea. It does not work. It never did.

Can you see why?

 

Agile Coaching Lessons:

[<–Previous Lesson]    [Next Lesson–>]

[Table of Contents]

 

DanMezick_CC_2-281x300

If you find value in these essays and find yourself curiously drawn to them, consider investigating OpenSpace Agility, and/or  following me on Twitter and/or joining the OpenSpace Agility group on Facebook

“Just Say No” to Platitudes

There’s this common pattern of behavior from some outspoken people in the Agile industry. And the consulting firms, of course.

And it’s all particularly subtle.

If goes like this:

1. A highly desirable ideal is identified. For example, “motivated individuals” or “flat hierarchy” or “self-organizing teams” or “self-management.”

2. Flowery language is be used to describe the ideal, and it’s wonderful effects on teams, on organizations, the virtue of it, etc.

3. Absolutely ZERO guidance is given in terms of how to actually achieve the objective in the real world.

In other words, there’s quite a lot of saying and not much guidance (if any!) on the actual doing.

If you are paying attention, you can see it in various quips from various outspoken consultants.

And it all sounds so good!

And then, there is zero discussion of:

4. How to achieve the ideal;
5. What specific impediments are in the way of the ideal, and how to remove them

From my point of view, it’s very good PR and a total non-starter to:

6. Extol a virtue,
7. Not name the impediments to that, and then
8. Offer absolutely nothing in terms of tactics to achieve the virtue.

Here’s an example:

Description of highly desirable virtue:
“Teams need to be able to do their own planning, make their own commitments, and organize their own work.”

Description of organizational impediments: none
Description of tactics for impediment removal: none

 

 

See what I mean?

And now, the summary question:

Question: Who are the Agile leaders that routinely offer all 3 pieces of the puzzle?

Here are the 3 pieces:

1. Description of the virtuous ideal,
2. Description of the typical impediments to that ideal, and
3. Specific guidance on how to remove those impediment(s).

 

Moral of story: (1) without (2) and (3) is just a platitude. It’s not actionable and as such, it’s not very valuable. It’s useless. It’s not actionable.

Because truth be told, we got the “why” and the “what.” Now we need some guidance on the “how.”

So here’s my guidance: “Just say no” to platitudes from Agile leaders.

When a virtuous ideal is described, ask them how to actually get there.

Demand a description of the common impediments, and then the specifics on how to eliminate them.

 

If you are growing weary of do-nothing platitudes and want genuine actionable guidance, you might want to investigate OpenSpace Agility. Because truth be told, it’s offers you the keys to success: all 3 pieces of the puzzle: the ideal, the impediments to the ideal, and how to remove them.

Related Links:

OpenSpace Agility (link)

The Agile Industrial Complex (link)

Saying One Thing Doing Another (link)

Saying One Thing, Doing Another

Agile leaders routinely extol the virtue and value of “self organizing teams” and “motivated individuals.” As well they should, since these exact phrases appear in The Agile Manifesto.

The primary impediment to both of these wonderful ideas is the imposition of Agile practices on teams without their consent.

Without their voluntary engagement.

Without actually manifesting “respect for people,” you know, that “very small aspect” of Lean.

 

Let’s unpack this.

 

 

“Self Organizing Teams”

Self-organizing teams are self-managing teams. Specifically, these teams manage decision-making, at the team level, on their own. Self-organizing teams know how they make decisions. The process of deciding is usually all very explicit and well understood by all team members. Teams at this maturity level often have explicit rules they use when making a decision that affect the whole team.

It’s very easy to see how the imposition or “push” of Agile practices on teams without their consent can make the “self-organizing teams” ideal just about impossible to achieve. It’s self-evident: external authority is calling all the shots with the “do these Agile practices until further notice” decision. There are no decisions for the team to “self manage,” let alone “self organize.”

“Motivated Individuals”

Pushing a solution (“do these Agile practices until further notice”) on a solution provider is a fundamentally dumb idea. Developers tend to be intelligent, creative, independent-minded, and introverted. Developers identify as “solution builders” and “solution providers.” With the imposition of Agile practices on teams we can expect some real disengagement and resentment from the most independent-minded developers.

We could threaten the developer’s job in response. Question: is that “motivating?” Are people who are afraid of losing their jobs the “motivated individuals” the Manifesto is referring to? Very doubtful indeed!

Agile leaders

Agile leaders routinely say all the right things about motivated individuals and self-organizing teams. Then they say and do absolutely nothing in protest of the Agile-industry’s standard of pushing Agile practices on teams. This is all very misleading!

Agile leaders cannot have it both ways. They cannot claim solidarity with Agile principles and also say absolutely nothing in protest about the deplorable pandemic of “imposed Agility.”

To remain credible, these Agile leaders need to be sounding the alarm about the harmful push of practices on teams. These leaders need to be issuing protective warning and protests about imposing practices on teams. It’s harmful, it makes “self organizing teams” next-to-impossible to achieve, and it makes “motivated individuals” much less plentiful, or even nonexistent.

Moral of story: Agile leaders who sing the praises and extol the virtue of  “self organizing teams” and “motivated individuals” while remaining silent on the #1 impediment to manifesting both is a kind of deception.

If you are an Agile leader, and you engage in this pattern of rhetoric, it strongly implies you are for something that you are really not.

If Agile leaders actually want “self organizing teams” and  “motivated individuals” to manifest worldwide, we will hear them loudly sounding the alarm about the deplorable status-quo of forcing Agile practices on teams without their consent.

As of today, protective warnings and protests on this topic from Agile leaders are very hard to locate. Hard to come by. Nearly nonexistent.

To learn more about the worldwide scope of this insidious problem, please examine the essay “THE AGILE INDUSTRIAL COMPLEX.”

THE AGILE INDUSTRIAL COMPLEX (link)

The Agile Imposition (link)

The Agile Manifesto (link)

Align Teams on Values with the CV-1 Exercise

The individuals on most teams usually have only one thing in common: they work for the same employer.

When you work with teams, they often need something more, “some thing,” to help them genuinely cohere. “Core values” is that thing. An explicit and short list of core-values that are explicitly agreed-upon can and will accelerate team-learning, by creating an environment that actually encourages it to happen.  It is essential that everyone on the team has a hand in creating this core-values list. That’s all I’m telling you about it for now, except for this one last thing: if you do not focus your teams on core-values, nothing truly great is going to happen right away.

After 10++ years of coaching teams and studying core values and culture, I’ve boiled it down to the essentials. I’ve created an activity I call “CV-1” or the “Core Values #1” exercise and activity. With this very fast 90-minute exercise, any team you coach can and will know, and understand, the actual values they actually share.

Here is how it goes:

Core Values #1 Exercise: “CV-1”

Setup and Materials: someone who is not a team member (like a Coach) facilitates this for the team. You want privacy for this exercise. You’ll also ideally want these materials and this setup:

Materials

  1. A big white board the whole team can stand in front of. Use flip charts on tripods if you must.
  2. Flip chart pad. The team will be making art on some of the sheets at the end of the exercise.
  3. Juicy dry-erase markers in several colors. Make sure they are juicy. Dry markers are the sign of a mediocre coach and facilitator.
  4. Optional: Sharpies in various colors for Step #8 (see below.)

Setup

  1. Get everyone in one place without distractions for 90 minutes. Team members only. Find and maintain privacy.
  2. Explain what core values are, and why they care.
  3. Make it clear you are facilitating and not participating. If you are a team member, you are prohibited from facilitating this. This is for them, not you.

Steps

  1. Have them stand up and stand in front of a blank white board, as individuals, shoulder to shoulder. Make markers available.
  2. Ask them to write down in one word the things that truly PISS THEM OFF. Really irritating things. Everyone knows what irritates them. Ask them to write those things down as one or two words. These are the things in life that the individual DISLIKES when they see it or experience it. Examples include “pushy people,” “blowhards,” “bureaucracy,” “laziness,”  “repetitive work,” etc. There are no right or wrong things to put down here. In all cases, instruct them to write down things that truly IRRITATE them. Make sure they write one word per line, and make a list in one big stacked column of words, one column of words (on the white board) per person. Make sure there is white space on one side or the other of each item in this list.
  3. When they are done, ask them to write THE OPPOSITE of each item, next to each item. This is what they actually value as an individual.
  4. Notice and eliminate duplicates, so only one of each item remains on the board.
  5. Now give everyone 10 votes (or whatever number of votes can reveal what’s what.) Have them look at everyone else’s list and apply their votes, 1 vote per item.  They are voting on what values they hold in common. Use initials or just “tick marks” to vote for the items that they are most willing to most strongly hold as a value in this group. The items with the most votes are the items held in common as values. As “value-able.”
  6. Now harvest the top 4,5,6 or so. The items with the most votes. These are the TOP and common core values, shared by the group. Copy them to one clean spot on the white board. No more than 7 is a good idea. Ten is a lot and may be too many.
  7. Now invite them to write a single sentence that explains the value, using some of the words that were voted “up” but did not have enough votes make it into the final list. Words that were not voted are also OK. Have them just kind of self-manage this step. It might take awhile. You the facilitator can mostly stay out of it, unless they get stuck. Try to stay out of it. Hold your fire. Don’t try to speed them up, or otherwise manage them. Just supply the steps and rules. Then shut up.
  8. Now they have N core values and a brief sentence describing each. They are almost done. Have them render this list to 1, 2 or 3 flip-charts sheets. Try to get everyone to participate in the creation of the art. Tell them that these hand-drawn sheets are going up on the wall in a prominent place on the team-room wall and/or work area. Position them prominently on one of the walls in the space.

The CV-1 or Core Values #1 exercise is the fastest way I can think of to identify a team’s common, shared, “core values.” It goes really fast. I hope you give it a try.

 

Agile Coaching Lessons:

[<–Previous Lesson]    [Next Lesson–>]

[Table of Contents]

 

DanMezick_CC_2-281x300

If you find value in these essays and find yourself curiously drawn to them, consider investigating OpenSpace Agility, and/or  following me on Twitter and/or joining the OpenSpace Agility group on Facebook