Blog

Most (Group) Behavior is Unconscious (coming soon)

Agile Coaching Lessons:

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

[Table of Contents]

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

(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]

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 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]

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

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]

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

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]

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 COACHING LESSONS: “Trance Formations”

Push-style “transformations” look good at first, and do not last long. What is actually going on there is this: TEMPORARY EFFECTS. 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.

The cost of these effects is very real, however. And permanent (non-refundable) in nature.

What’s being sold as “Agile transformation” today are mostly short-run productivity increases that do not actually last. Temporary improvement. New procedures, new consultants, new teams, new practices, etc.

Observation. The short-run productivity increases from these temporary effects are all very misleading. They do not actually last; they are 100% temporary. There is no actual “transformation.” Furthermore, it is often highly prescriptive programs that produce these effects. When those highly prescriptive and authoritative (and expensive!) coaches vacate, the improvement goes with them. It’s all very temporary.

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 those who are affected. 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.

Agile Coaching Lessons:

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

[Table of Contents]

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