Posted on

Cognitive Recycling

I teach #Agile teams that when gathering requirements, it’s best to intentionally leverage the “back of mind” of all the participants. This is what I call a cognitive leverage point in team learning. To make use of this, you must restructure your meetings, to leverage the unconscious….the back of the mind.

…it works like this:

We have all participated in long, soul-sucking meetings without breaks, where we are on a kind of death march to complete the meeting. These meetings are highly demotivating…. and also completely ignore (and therefore do not leverage) the extremely powerful “back of mind” feature of human cognition.

The trick is to STOP having long meetings. Especially when working on sense-making!!

Instead, for any kind of important group sense-making task, like requirements-gathering, schedule several short 1-hour-or-less meetings, 1 per day. The first meeting is short, and highly focused, some work gets done….and then it ends.

However, we ALL KNOW that tomorrow we are doing this meeting again. This is where it gets interesting. The game is just beginning…

 

Cognitive Recycling

Everyone in the group keeps ‘cycling’ and working in the problem when in the elevator, when commuting home, when winding down at home, AND when sleeping. They “work” on the problem, “back-of-mind”, for 24 hours…even when sleeping. (Participants report dreaming about the work in between meetings.)

They anticipate and expect the next meeting the next day, and because of this, they tend to integrate learning, from the “back-of-mind”,  even when sleeping. They iterate and re-iterate…cycle and recycle…using the unconscious “back of mind”.

The next day, the deeply integrative learning goes to the front-of-mind, where it is accessed and used to advance the task at hand with the group during the meeting. This occurs at every meeting.

 

Cognitive Recycling and Permaculture

Cognitive Recycling is a way to get people “thinking” 24X7, even while doing other tasks. It leverages your “backchannel” or back-of-mind, by setting up a clear purpose for a meeting, and some anticipation…via a predictable and scheduled rhythm, or cadence.

As a practice it honors several of the 12 permaculture design principles:

  • Catch and store energy;
  • Use and value renewable resources and services;
  • Produce no waste; Use small and slow solutions;
  • Use edges and value the marginal.

My clients report the following:

  • A sense of control, stemming from a set of predictable, short, clear-purpose meetings
  • A sense of progress, stemming from increased daily insights and ‘ahas’
  • A sense of membership in the task at hand
  • Strong feelings of integration and satisfaction with the work and the people doing it with them

Simple Steps for Cognitive Recycling:

To leverage the effects of cognitive recycling, follow these steps:

1. Replace a planned meeting of N hours with N meetings of 1 hour each, on successive days. For example for a 5-hour meeting plan five or 1-hour meetings … on successive days.

2. Schedule the meetings for the same time each day. This is effective, because it establishes the regular period or cadence, which is essential.

Team and organizational learning is NOT random— I teach that we must intend it. Group learning is not automatic. What is nearly automatic is low levels of learning when people gather in groups. Group learning is no accident.

Learning leverage is what you get when you leverage the unconscious processes of the brain. When a group of people actively do this together, leveraging “back-of-mind”, the volume of excellent-quality results can be quite astonishing.

Cognitive Recycling. Give it a try. It’s a technique of  Organizational Permaculture.

(NOTE: This and other strong techniques for group learning are described in detail in my book, THE CULTURE GAME.)

 

Please investigate and consider joining the Organizational Permaculture Facebook group. In this group on Facebook we are mixing people from the agricultural permaculture movement with folks from organizational development, agile coaching, culture hacking and others tribes who are interested in this concept.

 

Posted on

The Genius Organization

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

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

The Genius Organization

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

The genius organization:

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

 

Agile Coaching

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

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

Kanban and Scrum

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

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

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

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

Posted on

Mandated Collaboration: The Recipe for Botched Agile Adoptions

Here is a sure-fire way to virtually guarantee a failed adoption of agile or Scrum:

Simply have an authority figure, preferably the CEO, announce with great fanfare to the entire organization  that we are “going agile”.

To really make sure you definitely create a colossal train wreck of truly epic proportions, be sure to specify a hard date, the date when the entire organization is “going agile”.

The folks may start rolling their eyes, making sarcastic and sour faces, crossing their arms, shifting their feet…in other words, disengaging.

Why would mandating FORCED COLLABORATION be a bad idea? Why is it a bad idea to CHANGE EVERYTHING on people without asking them what they think? Why is mandated collaboration a very bad idea?

1. IT KILLS OPENNESS. It signals that whatever people actually think, feel, believe and want is NOT valued. (If we value what you want, think and feel, we’ll signal that by asking you what you want, what you think, etc.)

2. IT KILLS INITIATIVE. The very people who can help spread good agile in your organization are not getting a hearing. By this I mean the people who are capable of thinking for themselves, and have an independent streak in them. By announcing the “agile adoption” without checking in on what people might think, you send a signal that is OPPOSITE the Scrum value of Openness and OPPOSITE the Agile Manifesto value of [Individuals and Interactions]. Good job !

3. IT KILLS ENGAGEMENT. By announcing like that, you signal that AUTHORITY remains where it currently resides: with the command-and-control higher ups. Good luck getting people to self-organize themselves in that scenario. You just told them it is OK to check out and DISENGAGE, since authority is not about to be getting shared.

4. IT KILLS ANY SENSE OF CONTROL PEOPLE HAVE. By announcing like that, you make enemies of the people who might be allies. The people who CARE actually complain a lot, usually 1-to-1 … to colleagues and friends. Do you really think you are going to score points with people when you reduce their happiness? Do you really think you make people happier at work by making all of the decisions that affect them… at work? When you announce change like that, you botch the agile adoption by reducing the perceived sense of control people have. Good job !

5. IT KILLS ANY SENSE OF PROGRESS. By announcing like that, you kill any sense of progress. You make agile look, feel, and smell just like every other FAILED change initiative such as Six Sigma, CMMI, re-engineering, et al. Announcing authoritatively sends the clear signal that ABSOLUTELY NOTHING HAS CHANGED.

Summary

You cannot get people on the bus by barking the agenda and signaling that feedback is not valued.

That is the very antithesis of agile!

You get them on the bus by asking them what they think. Agile is getting a huge black eye as it “goes mainstream”. The same old patterns of command-control are being played out as new ‘agile’ terminology is being used as a cover story for disrespecting the people who do the work.

Add to this the fact there is always an ‘Agile coach’ to help well-meaning but misguided or misinformed “leadership” do whatever it wants with ‘agile’ (provided the price is high enough) and we have a train wreck of epic proportions being played out in enterprises around the world– especially in the USA.

Especially in Boston!

You might be asking: what is the solution? It is really very simple: Create a space where the folks get HEARD. The folks know the work. Why not ask them what they THINK about AGILE before rolling it out? Since this almost NEVER happens, 99% of ‘agile adoptions’ are train wrecks that associate with diminished feelings of control, diminished feeling of progress and diminished feelings of teamwork with “leadership” and authority. Did I mention diminished feelings of being respected?

 

The Culture Game book has an entire chapter devoted to the idea of opening the conversational space as a requirement for a successful agile adoption. The folks that do the work are going to get a hearing one way or the other. The only real question is how leadership chooses to manage the inevitable expression of what people want, what people think and what people feel.

***

 

 

 

 

 

 

 

 

 

 

 

Posted on

Scrum Master Selection

It is at best misguided to send Project Managers to Scrum Master training and make them Scrum Masters. Here are some reasons:

1. Your new Scrum team is already doubtful they actually have authority (“right to do work”) per the rules of Scrum. Your culture is not supportive of the idea, and every signal the team is getting from higher-ups is telling them to hedge their bets on Scrum as described around the web and in the Scrum Guide. The team will therefore ask the Scrum Master (previously: Project Manager) what they “should” do.

2. The Project Manager-turned-Scrum Master is going to have a hard time not telling the team what they “should” do…..

a. The Project Manager-turned-Scrum Master is probably an authority-seeking type of personality. That’s why they they were drawn to Project Manager role in the first place!

b. Even if the Project Manager-turned-Scrum Master comes back from Scrum Master training an enlightened and transformed creature, THE TEAM has no clue about this and is still projecting authority on the Project Manager-turned-Scrum Master. This pattern might persist for some time.

c. Even if the Project Manager-turned-Scrum Master comes back from Scrum Master training an enlightened and transformed creature, this new Scrum Master is clueless about executing in the role. This person has no experience.

All of this works against success with Scrum.

Usually, the Scrum Master is selected by the higher-ups. This is why the selected person is usually a PMP, or a Project Manager. (The Scrum Guide is silent on who chooses the Scrum Master.)

Here is a better approach:

1. Train everyone in a 2-day agile/Scrum class. Have the course delivered by your eventual coach.

2. During training, make sure the Scrum Master role is clearly explained. make sure it is explained from a servant-leadership point of view. Make it plain the Scrum Master identifies and removes impediments, and does drive schedule, cost, quality or features like a traditional Project Manager.

3. During the training, do some simulations of Scrum where someone can play the Scrum Master role. Offer the role to all the folks in the class and see who self-selects to give it a try.

4. Have the coach model the Scrum Master role when Sprints kick off. Make sure that the purpose of the coach occupying the Scrum Master role is to mentor this new Scrum Master. As soon as possible and without delay, install this new Scrum Master and get the coach OUT of the Scrum Master role.

5. Have the coach keep mentoring and guiding this new self-selcted Scrum Master in the art of occupying the role.

Summary

Instead of having the higher-ups select the Scrum Master, explain the nature of the nature of the role and see who shows up. Realize that putting a Project Manager in the role is probably not a good idea. Project Managers are typically authority-seeking and are great candidates for the Product Owner role.

Posted on

Hacking Iteration: Rehydrating Your Wetware

Recently I wrote about a technique for gathering requirements as a group. The technique is called rehydration and involves a very short meeting every day for 5 days. The idea is that the people in the meeting actually think about the meeting topic during the entire 5 days, not just the one hour each day.

The basic idea is to get the group thinking together over multiple days. Each short meeting constitutes a rehydration event. Such as event refreshes the neural pathways of your wetware (your brain). When a group of people execute on this kind of thinking together, the result is a substantially higher level of group cognition.

My friend Dave Logan wrote about this about a year ago. I was just up on his Facebook and I found this link:

The Single Best Time Management Tip Ever

…your brain is brilliant at running processes in the background, but is awful at multitasking. While you’re driving to work, in the shower or answering email, your brain will be working in the background on the task, so that when you’re ready, it’ll drain through your fingers, into your computer or notepad, for about 20 minutes. The break allows your brain to restock the supply of brilliance. Each time you go through the process is a “productivity unit.”

This idea of a short burst of front-of-mind focus followed by a break that is much longer (and used for back-of-mind thinking) is a super-powerful technique for doing sense-making with a group of people.

The technique is really very simple:

1. Gather the group with the collective intelligence to make sense of the problem (example: the definition of software requirements)

2. Schedule a 1-hour meeting for each day for at least 4 days

This is a special form of iteration, where the break is much, much longer than the iteration itself. Use Rehydration when you need to make sense of something very complex with a group of people.

Posted on

The ICF Code of Ethics

Let’s get real. The International Coaching Federation has a Code. See it here. This document and the wording in it as written is inadequate for Agile Coaches in my view. It is missing a key set of  keywords.

The ICF wrote a generic Code. It is not intended for the Agile Coaching specialty. Agile Coaching probably was not even a real occupation when the ICF code was written.

Using the ICF code is dodging the issue. The issue is DEPENDENCE.

We need to include certain specific words in the Agile Coaching code.

They are:

dependence

dependency

dysfunction

codependence

These words need to be at the front of mind if you are an Agile Coach (big A, big C).

The reason is simple: there is nearly automatic dysfunctional, highly codependent relationship that can exist between external Agile Coach and client. I have ranted on this plenty in many previous posts.

(previous Agile Coaching Ethics posts.)

The ICF code is a good starting point. OK? It is a base class, also known as a abstract class. It’s good to use as a starting point, and for using that starting point to add more (minimal) features that tailor it for the Agile Coaching. Let’s stop pretending the ICF Code is adequate as a code for Agile Coaching ethics. It’s not.

Here is the idea: Agile Coaches must

1. Be mindful that dysfunction is nearly automatic;

2. Take steps to create firewalls that prevent co-dependence between coach and client;

3. Never knowingly encourage a dangerous and unhealthy  dependence on the coach;

Such dependency can create a nearly-automatic stream of revenue from client to coach. I’ve seen it. It goes on where I live. It probably goes on where you live.

That, and:

1. Client learns nothing; and has no clue this is true;

2. “Coach” ends up doing the same tasks over and over; making loads of MONEY

3. Agility gets a black eye when people observe the results; resulting in observers worldwide thinking Agile is some kind of gimmick;

4. The client trades one set of dysfunctions for another; and has no clue this just happened.

 

We can do so much better. Where I live, there is loads of this happening. And no one is saying ANYTHING about it. Where is leadership in the Agile space when we NEED it? We have a very weak immune system.

 

It’s time for the Agile community to:

1. Get a backbone and have this conversation now.

2. Develop a code of Agile Coaching Ethics that devalues the development of ANY dependency in the client.

3. Start discussing and identifying which behaviors that encourage a dangerous dependence, and call them out as out-of-bounds and not honored by the community at large. For GOOD reasons.

4. Wake up and smell the coffee. A lot of coaching is actually revenue generation with little or no learning taking place. The Agile community has no immune system and even honors this behavior.

It’s ludicrous and absurd to watch.

What’s up with this? Anyone can show up and promote ideas like coaches “occupying the Scrum Master role for some time” when we all know that is not coaching at all. What that is, is manipulation. Coaching is not manipulation and coaching definitely is not consulting, EVER.

Let’s all wise up. The ICF Code is a starting point. Let’s go to work.

What you tolerate, you insist on.

What you insist on will be supplied.

-Jim and Michele McCarthy, SOFTWARE FOR YOUR HEAD

Posted on

Agile Coaching, Client Learning, and Money (Part 1)

Is client learning inversely proportional to short-term coaching revenue?

If the client learns quickly … and gets to Free Standing Agility (FSA) … does this reduce or even terminate short-term coaching revenue?

I have to say, generally speaking, YES. However, like any good policy, after a delay, being a service-oriented, service-optimized coach is optimal for revenue generation. It ends up making much more money over the long term… after a delay. Contributing factors include the generation of successful case studies, development of the client’s FSA, and the development of close friends and strong reputation.

Let’s do some analysis by unpacking this graph:

The horizontal axis depicts levels of short-term (not long term) revenue. This axis can be viewed as depicting the collection of billing over time. This axis is labeled [Coaches Billing and Revenues]. The vertical axis labeled [Free Standing Agility] depicts levels of client ability to proceed without requiring a coach to help continuously. The term Free-Standing Agility refers to a level of ability to identify and respond to change, as an organization, without help from an external source like a coach.

What is the Responsibility of the Client?

Clients often ask for a authoritative prescription– in effect, projecting authority on the coach … and expecting the coach to tell them what they “should” do.

What is the correct response from the coach in this spot?

Clients must be told they are responsible for their own learning, and that the coach plans to completely help with that … by conveying as much knowledge as possible in the shortest amount of time possible. By mentoring, by assisting in skills development, and as much as possible, not authoritatively prescribing. The goal is FSA- Free Standing Agility- for the client.

I want to make it clear that the client organization co-creates the learning situation with the coach. However, all too often what the client asks for is an authoritative prescription, the very opposite of what Agile is all about. This opens the door to all kinds of dysfunction in the coach-client relationship. Coaches need to be ready to discuss this dynamic with the client, in effect assisting the client in the development of rapid organizational learning.

OK, on to the graph. The graph (below) depicts four coach types: Service-oriented, Competent, Average and “Zombie”. Let’s look at the first three of these:

Service-Oriented Agile Coach

Depicted in green. Coach has high integrity. Coach is reflective and has achieved day-to-day personal mastery over his/her own behavior. Exhibits high levels of awareness and self-control and is consciously intentional. Coaching approach is optimized on client learning. Coach is willing to limit short-term revenues in pursuit of wider organizational learning development. Coach understands the inverse relationship between client learning velocity and short-term revenue generation. Coach actively chooses client learning over short-term revenue generation. Coach employs various methods and relationship structures to accelerate client learning velocities. Techniques may include arms-length agreements, limited-authority role, short-duration engagements, formal and frequent coach-client retrospectives, and other techniques executed with client, all designed to rapidly optimize client learning levels and ongoing organizational learning velocities.

Coach understands the nature of delays in long-term revenue generation. Coach accepts these delays and takes the long view. The Service-Oriented coach tends to make less money in the short-term and much more in the long term.

Figure 1: Short-term revenue dynamics of client learning, by Coach profile type. The 'Zombie' coach generates FOUR times as much billing overall, but client learning levels are about ONE QUARTER of what a Service-Oriented coach can help create. What gives here?

 

 

 

 

 

 

 

 

 

 

 

 

 

Competent Agile Coach

Depicted in orange. Coach has sincerity. Coach has competence and potential for mastery. Approach is optimized on client competence in prescribed and improvisational ways of Agile doing and being. Coach is interested in pursuit of good agility levels, and wider organizational learning. Coach is aware of the inverse relationship between client learning velocity and short-term revenue generation. Coach usually  chooses client learning over short-term revenue generation. Coach may or may not various advanced methods to accelerate client learning velocities. Coach understands the nature of delays in long-term revenue generation based on reputation and results, and is beginning to take the long view.

Average Agile Coach

Depicted in red. Coach has sincerity. Coach has competencies and is growing them. Approach is optimized on teaching the client  standard, semi-prescribed ways of doing and being Agile, in standard formats. Coach is interested in seeing team velocity increase. Coach is starting to be aware of the inverse relationship between client learning velocity and short-term revenue generation. Coach has less than 2 years experience and is gaining in competencies. Coach typically does not use ground rules and techniques like arms-length agreements to accelerate client learning velocities. Instead, coach focuses on delivery of A-B-C techniques such as canonical Scrum, basic and sound implementations of Kanban, TDD etc.

Coach probably has not thought deeply about the dynamics of short-term and long-term revenue generation from coaching.

Summary

The Service-oriented Coach is the ideal. Getting there takes experience, and a valuing of client learning over short-term revenue optimization. After a delay, the Service-Oriented Agile Coach develops positive change, wonderful case studies, many genuine friends, and a great reputation. All of this leads to more long-term opportunities to do great things, with great people, and be paid handsomely for this privilege.

Let’s go to work developing the profession of Agile Coaching. Part of that work includes paying explicit attention to genuine service as we examine what’s normal in our community.

In the next part in this series, we look at the Zombie coach: the coach that values revenue over client learning.

Thomas Paine says it best:

“A long habit of not thinking a thing wrong gives it a superficial appearance of being right.”

 

See also:

Previous Posts on Agile Coaching Ethics

Posted on

On Retrospectives: Part 1

Retrospectives are team learning ceremonies and have the potential to create genuine team learning. Yet, I often notice that even after a great Retrospective, the team often forgets about the answer to question #3, “What do we want to change?” Jeff Sutherland once coached me in this and told me to focus the team on ONE and only ONE thing to change, so they have a better chance of actually remembering, focusing on it, and doing something about it. Since then I have used this technique to very good effect when coaching agile teams.

Another good technique is:  take pictures of everything. Usually in a retro we answer the three questions “What is going well?”, “What is going badly?” and “What do we want to change?”. Usually sticky noted and sharpies are used to get these items generated. Taking picture of the sticky notes-and-votes (the votes with dots) is a good way for the Scrum Master to recall what happened and remind the team.

I like to see the team to put up a poster of the #1 thing that needs changing. This visual management artifact makes it real that a) We had this conversation b) We committed to the act of doing something and c) We all know where we are with respect to this item we SAID we intend to change. Consider prompting the team to create a poster and put it up on the wall (in a prominent place) for the entire Sprint. That makes it real.

This next picture below depicts the act of deciding on that one thing you may eventually depict in a poster:

 

Question #3, "What do we want to change?". We used voting dots to get to one item.

 

This is the RESULT of the retro, the decision on what to change.

The above figure show 2 columns. Each column is an topic, with multiple notes from earlier. The notes in a column are related and come from the answers to retro question #2, “What’s not working?”. These have been voted on and the top two are depicted: changes to team composition and the pulling of people from the Sprint work during the Sprint. This team is experiencing both. As facilitator, I guided them to identify these top two items. Then I placed a blank sticky note under each column to receive votes. I gave each team member one (red-heart) sticker each, and asked them to place a vote on which of the 2 columns mattered most to them, in terms of what to change.

We came out of this retro with the decision that the team wants to address the issue of authority outside of the team making changes to team composition constantly.

Remembering to Remember

OK, now assume teh team is in the next Sprint and is doing a remarkable job of working on the one thing, that one impediment that they want to change. fix, edit, re-factor, etc. They do a good job, and now we are doing another retrospective at the end of this Sprint.

As facilitator of that meeting, it is a good idea to recall and re-depict the OTHER items that were candidates for change. By this I mean, the #2, #3, #4 candidate items etc from the LAST retro. Look at those as a start for the 3rd question “What do we want to change?”

By bringing these items back to full attention, the team recalls what other items may still be in the way, from 1 retrospective ago. This important sentiment is often lost from retro to retro, Sprint to Sprint.

Summary

In general, retrospectives are the single best source of substantial team learning. How much learning the team actually gets is a function of many factors related to team-recall and team-remembering. As the facilitator of retrospectives, keep this in mind. Be mindful for the team. Remember, and help them remember. This post provides some techniques. They are summarized below:

1. Come out with ONE thing to change, not many things. Use dot-voting to get the team to choose the one item. Structure the voting to yield ONE and only ONE item. As facilitator, steer them towards ONE thing.

2. Take pictures of everything on the wall if you are the facilitator. Use these images to help yourself remind the team of what it says it wants.

3. Coming out of the retro, suggest that the team make a poster that depicts the one thing they are committed to changing. Consider making this a group activity during the end of the retro.

4. In your current retro, recall and remind the team about the other candidate-items-for-change that came up at the last retro. Use the pictures and notes you kept and show the team these artifacts as you answer teh 3rd question “What do we want to change?”

I have experience doing Agile coaching that dates back to 2008. If you like this post and want to see more like it, leave a comment to that effect and I’ll compose another with more content on retrospectives. I have a few other tips you may find useful.

 

Posted on

Free-Standing Agility

The goal of any legitimate Agile Coach is what I am calling Free Standing Agility:

Free Standing Agility is that characteristic of a group of people, which allows it to at once identify, and rationally respond to, environmental change. Such changes may be both intrinsic and extrinsic in nature. By definition, Free Standing Agility is free of dependence on anyone who does not have group membership.

This Free Standing Agility (FSA) is that property that allows a team, group or organization to adjust, moment by moment, to forces and influences that alter their current environment and situation. This is typically a business environment, but need not be, to satisfy the definition. Any group or organization, for example a hockey team, or an orchestra, can be in state of FSA.

Agile Coaching

‘agile coaches’ who insinuate themselves into a group of people who they are purportedly coaching are doing a serious disservice to that group. The coaching relationship must not be polluted with dysfunctional structure. Embedding and ‘integrating’ into a group of people who are learning how to be a group is a most insincere act.

Such insinuations may take the following forms:

  • Occupying the Scrum Master role for “some time”, certainly more than 7 days, with no intent to teach the role, thereby robbing the group of important experience in that role. Note: Scrum Masters must learn by doing. If no one else is “doing” the SM role, there is no intent to teach it on the part of the “coach”.
  • Engaging in Extended-Stay (embedded) “coaching”. In almost all cases, engagements of this type have at least the potential to engender a serious dependency on the “coach”.
  • Occupying the Product Owner role for longer than 2 days, with no intent to teach the role to anyone else.

Free Standing Agility is possible when the Agile Coach engages in an arms-length relationship with the client group. In this manner, dependencies that are dangerous to both Client and Agile Coach are intentionally avoided, in service to the development of Free-Standing Agility in the client group.

See also: Previous Posts on Agile Coaching Ethics