Enabling Enterprise Agility
Most (Group) Behavior is Unconscious (coming soon)
Agile Coaching Lessons:
[<- Previous Lesson] [Next Lesson–>]
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:
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.
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–>]
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–>]
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:
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:
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:
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–>]
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:
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 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–>]
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:
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–>]
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
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:
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–>]
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
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)
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)
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
Setup
Steps
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–>]
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