Posted on

Embedded/”integrated” coaching

Here is the definition:

Embedded Agile Coaching: Agile coaching that has a “coach” personally present, full-time, at the client site, for 3 business months or more, where the coach is often (but not always) observed taking up the Scrum Master and/or Product Owner role for substantial amounts of time.

Embedded coaching 5 days a week sets up at least the following potential dysfunctions:

  • Excessive projection of authority on the ‘coach’ by the client, leading to the coach inappropriately accepting responsibility for the client org’s learning.
  • A client desire to see the coach ‘doing something’, leading to the misguided idea that having the coach function as Scrum Master for all the teams is a useful and good idea. (It’s not.)
  • Diminished client learning, caused by the ‘coach’ becoming an authoritative fixture in the organization, the one who provides answers.
  • A tendency for the coach to support Mandated Collaboration

 

 

Posted on

Agile BS: The Productization of Agile

There is a preponderance of BS in and around the Agile community right now. Scrum has become productized, and ‘agile enablement’ firms touting that ‘agile is all we do’ are selling one or another variety of snake oil. Boston is a place where this is especially acute.

David Anderson, a guy who wrote a book called Kanban, is calling this out, and he is not alone. He spells it out here:

There is an initial assessment or appraisal…then some proposed future state envisaged…the new future state process is designed and it becomes the target outcome for the transition that is introduced and managed through the change management process.

This is a traditional 20th Century approach to change. It offers the reassurance of a defined outcome, and the outcome is envisaged either using a prescription from a text book, or by utilizing a model and designing a solution. The issue with this is that it assumes the problem exists in the complicated domain…

…It is ironic that the approach to Agile transitions has been a very non- Agile, big design up-front, make and follow a plan, approach. The fact that many Agile transitions are challenged and underperforming (and I’ve been saying this for at least 5 years now) may be that the approach being used is inappropriate to the domain of the problem. What we need is an Agile approach to change – an approach that incorporates feedback loops and evolves as new information emerges.

(See the full blog post here)

Andy Singleton, a friend of mine in Boston who makes great tools for distributed teams, is also on to something also, when he writes:

Pair programming:  Great for vendors, bad for customers.  Pair programming is like those girls that go to the restaurant bathroom together.  What are they doing?  If you are a vendor selling “pairs”, you have an awesome situation where you can charge twice as much, and you can easily churn guys on and off the pairs, one at a time, to steal talent for turnover or new projects.  If you are customer, you pay twice as much and you get churn.

(See the full blog post here.)

These writing from these two gentlemen are pointing to the productization of Agile. It’s a sad state of affairs that appears to be encouraged by the Scrum Alliance and the Agile Alliance.

Organizations need to think for themselves and be responsible for their own learning. Each firm must create a custom solution from practices that are based on solid principles. David Anderson and Andy Singleton are on to something. One size does not fit all.

The productization of Agile is happening now. The message is: one size fits all.

And it’s all BS.

 

 

Posted on

Agile Enablement: Now in a Spray!

“Agile enablement is all we do” is a phrase used by some firms that sell Agile as a product. The basic idea here is that this one firm with a designed, “proven” approach can solve all your Agile problems– can be your “panacea”– so long as you write a big check.

This is very misleading, since Agile is not a product. Some folks with a very creative sense of humor are bringing this to attention with “Agile In A Can“– in effect, delivering Agile in as a spray-on product. Imagine spraying Agile on your managers, your developers, or your task boards, like deodorant or cologne. You get the idea.

(NOTE: You can follow @AgileInACan on Twitter )

The notion you can write a big check and then get visible, instant Agile going is seriously misguided. Your organization must be committed to learning, UP FRONT, and take responsibility for that learning after a while being guided by an external coach. And in time, by going forward– without that external coach. This is your goal: self-sustained, “free standing” agility.

Some service firms out there are selling the idea that you need a coach present each and every day, 5 days a week, for at least 12 weeks. Otherwise, you may fail !

This is called “embedded agile coaching” or “integrated coaching”. It sets up an nearly-automatic, unhealthy dependency on your “coach”. The implication is, “We are the experts. We have loads of experience, look at our client list. We have the one true way, this is absolutely the right way to do it. You may fail otherwise. We are the experts, and we are here to help you.” Out comes the contract and when you sign it, you lock in legally to pay for five days a week for 12 weeks.

What this does is simple. It sets up the “coach” to be present 8 hours a day, every single day. After a while, it becomes very obvious to you, the customer: the coaching job is definitely not a full-time job, even when coaching 1,2, or 3 teams.

How to get the coach busy doing something? The obvious fix is to make the “coach” the Scrum Master for all the teams right? ….so the coach is “doing something”, and is “earning their keep”. Makes sense right? Not exactly. Now the dysfunction kicks in.

The coach is now the authority, the person your Agile adoption most depends on. What usually happens is, this person takes up the Scrum Master role while not really teaching this skill to others in your organization. This makes the “you will fail without us” theory a self-fulfilling prophecy. If that “coach” leaves, no one really knows how to be the Scrum Master.

This practice of “integrated agile coaching” is really just a gamed scenario for installing a billable person in your shop each and every day for 60 days in a row. At a high bill rate. To generate loads of revenue. That’s it. It’s about revenue generation. For them to keep it going beyond the contract term, you need to stay dependent.

Don’t think so? Consider this report that says many customers are reporting that “agile is a scam to sell services”. Are these practices I am describing fueling this trend?

Did the customers surveyed in this scathing analysis of agile  buy 5-days-per-week, “agile integrated coaching”?

Are you looking to buy some agile coaching? OK. Here is the pattern.

The rigged game presented to you by the  “agile coaching innovation” firm goes something like this:

The Goal: Maximize Revenue Generation

The Rules: The coach is going to set up camp in your shop 5 days a week for 3 months. You the customer must sign a binding contract for “integrated” coaching, which is 5 days a week, for a 3 month minimum (a legally binding, ironclad revenue guarantee. You cannot get out.)

Scoring: The game is scored by the minimum 3-month revenue generation and the ongoing creation of more dependency on the coach from the client. Primary device to do this: be there 5 days a week, and work to occupy/own the Scrum Master role on every team. (NOTE: A good coach will teach others in your organization this role, and vacate the Scrum Master role as soon as possible and without delay !)

Opting-In: You the customer are either in or out based on the 5-days-a-week-for-3-months contract. Did I mention the high bill rate? The insistence on this engagement structure as the terms of engagement tests your willingness to play the dependency game. If you go for the contract, that means you are willing play the dependency game. By signing, you are agreeing to much more than you bargained for…

And dependency IS the name of the game!

Here is a good article on agile coaching, from the Agile Journal. It is from 2009.

Look at what it says:

However a Coach works, and whatever approach they take they the Coach needs to avoid creating a learned dependency.  This happens when the team comes to depend on the Coach.  Coaches need … to withdraw when the time is right and let the team continue.

While many companies will have their own coaches on staff and some will work with teams day-in, day-out for months or even years, there is a lot to be said for…limiting the period of coaching.

Yes, some “agile enablement” service firms selling “integrated Agile coaching” are eager to set you up in their “agile enablement” game, a game that maximizes billing-revenue for them first, and enables Agile for you second.

 

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

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

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

Posted on

Agile Coaching and the Learning Landscape

In previous posts about Agile Coaching Values, I discuss how the lack of clear definitions for Agile and Agile Coaching create opening for all kinds of sorrows and abuses in the role of Agile Coach.

Once again, I reiterate: most people doing this kind of work have a genuine and passionate interest in creating a space for clients that leads to what I am calling Free-Standing Agility. That said, whenever there is money involved, we can expect abuses.

One way to curb current and future abuses is to be, as a community, self-policing. We can choose to encourage as normal the identification of actual and potential ethical abuses of the Agile Coaching role. Or, we can watch as the emerging profession dies a death of one thousand (ethical) paper cuts.

To be clear, I am not offering a definition of Agile, nor I am offering a definition for the role of Agile Coach. What I am offering is my participation in a wider conversation in and around the ethics of Agile Coaching.

I wonder how much longer we as a community can defer this essential conversation.

The Current Situation

A quick survey of the landscape illustrates the confluence of forces that are creating a crisis of ethics in Agile Coaching:

  • There is no ethical standard for the Agile Coach role. We are just starting this essential conversation. Some like excellent Agile leader George Dinwiddie are speaking plainly about what they are seeing. Quoting George’s well-reasoned post, “What is An Agile Coach?”:“…..The coach helps the team articulate the results it wants, and generate courses of action to achieve those results. The coach partners with the team on the coaching process, but allows the team to exercise its own judgement about the software development practice. The coach does not become a member of the team, but endeavors to wean the team off of the need to consult with the coach on a regular basis. There are consultants whose business model includes making the client more dependent on the consultant. That, to me, is not coaching. And that’s not the model of consulting that I choose.

 

  • There are some people in the Agile community that have a legitimate voice, who are presently unwilling or unable to articulate a public position on the essential matter of ethical concerns in the Agile Coaching space. This behavior is a non-starter and has the effect of dampening community-wide development of the dialogue. This in turn impedes a more rapid development of Agile Coaching into a legitimate profession.

 

  • The advent of the PMI Agile certification has the effect of complicating and widening the Agile conversation to include traditional projects and project managers. This creates more terms, words, and complex “noise” in the dialogue and debate about what is and is not Agile and by extension, and about what is and is not Agile Coaching. This in turn more greatly confuses what is and is not a good ethical standard for Agile Coaching. This at-time confusing noise becomes cover for potential unethical practices and borderline coach behaviors.

 

  • Some in the Agile Coach community are publicly asserting that embedded, 5-days-a-week Agile coaching, with he coach often occupying the Scrum Master role, is  legitimate in every way and in every case. There is a strong assertion, by some, that coaches can legitimately “consult” in the Scrum Master role, for “some time”, and this is actually a foundational element of good Agile Coaching. Not so fast. While there are specific cases where 5-days-a-week coaching makes total sense, in my view (and the view of many others who participate in this community,) these are the exceptions, not the rule. Those who seek to validate an embedded, ‘integrated’ Agile Coaching model are actually instigating this wider worldwide conversation about Agile Coaching Ethics. They do so by making strong public assertions that ’embedding’ an ‘integrate coach’ as Scrum Master for ‘some time’ is actually a foundational aspect of a comprehensive ‘model’ of Agile Coaching. Great! Let’s have this conversation without delay.

 

This conversation about Agile Coaching Ethics is starting. Has started. Is now underway.

And here is the very good news: This  is a very healthy conversation, ultimately leading to more community wellness. It is driven by a confluence of forces that are conspiring together, drawing in participants that have have a keen and legitimate interest in Agile Coaching.

 

Posted on

Agile Coaching Ethics: The Epic User Stories

Agile Coaching Ethics. Hmmm.

So, what are the requirements we are seeking to make real here?

What are the requirements for the users of a Agile Coaching Code of Ethics?

And why do you care?

 

Here are some candidate Epics for your consideration:

As an Agile Coach, I want to to understand the ethical boundaries of the profession of Agile Coaching, so I can deliver great service to my Clients, avoid ever doing harm to my Clients, and advance the state of Agility in my community and in the wider world.

As an Agile Coach, I want to to understand the ethical boundaries of the profession of Agile Coaching, so I can align and associate with other Agile Coaches who share and subscribe to these ideas

As an Agile Coaching Client, I want to to understand the ethical boundaries of the profession of Agile Coaching, so I can more fully understand what Agile Coaching behaviors are “in bounds” and which are out-of-bounds

As an Agile Coaching Client, I want to to understand the ethical boundaries of the profession of Agile Coaching, so I can ask questions about these ethical boundaries to prospective Agile Coaches, before I engage them

As a prospective Agile Coach, I want to to understand the ethical boundaries of the profession of Agile Coaching, so I can decide if this is a profession I want to actually associate with, and be a part of

As a Agile Community Member, I want to to clearly understand the ethical boundaries in the profession of Agile Coaching, so that I may map the actual behavior of Agile Coaches I encounter to this standard

As a Agile Coaching Community Member, I want to to clearly understand the ethical boundaries in the profession of Agile Coaching, so that I can determine if these standards are sufficient to encourage genuine greatness in our community, and work to improve them with others in the coaching community when these standards need more clarity of definition

As an International Agile Coach, I want to to understand the ethical boundaries of the profession of Agile Coaching which apply universally, so I can apply this universal subset to all of my Agile Coaching work throughout the world

As an International Agile Coach, I want to to understand the ethical boundaries of the profession of Agile Coaching which apply universally, so I can align with other Agile Coaching professionals opting-in to the application of these ethical standards throughout the world

Please add to these Epic User Stories for an Agile Coaching Code of Ethics; you may do so by adding a comment. Please use the User Story format if you do so.

 

See also:

Previous Posts on Agile Coaching Ethics

Posted on

Agile Coaching Ethics: The Definitions

There is plenty of money to be made in Agile Coaching. Wherever there is money involved in providing counsel and advice, there are ethical considerations to address.

When discussing Agile Coaching Ethics,we must first define our terms.

The real problem with defining Agile Coaching ethics is the fuzziness of the Agile Coaching role itself. And it is exactly this fuzzy definition  for Agile that creates opening for all kinds of unethical behavior, such as taking up the Scrum Master role and even the Product Owner role for a very long time as a ‘coach’. Remember, Clients know very little and are vulnerable.

When is it legitimate for a coach to be on an “extended-stay” with a client? When is is acceptable for someone in the Agile Coaching role to occupy the role of Scrum Master? Product Owner? For how long?

And in service to what?

Lyssa Adkins in her book Coaching Agile Teams, lists some of the varying roles that legitimate Agile coaches assume. These include:

Mentor

Facilitator

Teacher

Problem Solver (NOTE: this section does not condone ‘contracting’ or ‘consulting’ to solve Client problems)

Conflict Manager

Collaboration Conductor

I do not see anything here which validates the idea of the Agile Coach being on extended-stay, indefinitely,  in the Scrum Master role. In my view, that is not Agile coaching. Instead, it is plainly:  fee-for-service contracting.

So let’s call it that !

Agile Coaching is not contracting. Or is it? Some say this contracting is coaching.

How exactly have we come to include contract labor in a definition of coaching? There are some in our community who are promoting the idea of including ‘consulting’ in the Agile Coach definition. This includes taking up the role of Scrum Master for ‘some time’.  Excuse me?

Is it legitimate for a professional Agile coaching to take up the Scrum Master role for an undefined length of time? Or is this merely contracting? I assert it is the latter. Practices like this give Agile Coaching a black eye, as I have articulated earlier, in this post. In this situation, a dangerous and potentially harmful dependency on the ‘coach’ may be engendered. Such dependency has great potential to reduce the Agile-learning yield for the client, even as more money is being spent on this so-called ‘coaching’.

The deeper problem is the definition of Agile.

What is Agile? We have the manifesto, we have the Scrum values, etc. Where can the clear definition of Agile be found? Once we have located this definition, we may more properly address the question “What is an Agile Coach?” and my favorite question: “What are and where may I find the ethical standards for Agile Coaching?”

If you want to get confused quickly, simply Google “What is Agile” and examine the results.

And so it is here that the opening exists for the creation of many sorrows. “What is in” and “what is out” of Agile Coaching is fuzzy at best. That leaves the door open to all kinds of coaching abuses, including attempts to include contracting and “consulting” in the Agile Coaching definition, to justify doing for the Client what the client can and must do for themselves.

We might consider tightening up the definition of Agile Coaching. Since the role encompasses so many tasks, and the definition of Agile itself is so broad, it may be best to describe what Agile Coaching is NOT. This is a shorter list, and such a list clearly defines what behavior is out-of-bounds for legitimate and professional Agile Coaches.

What is striking as of 10/12/2011 is the total lack of conversation in the Agile community, worldwide, about this topic. That leaves the door open to all kinds of sorrows for coaches and clients alike.

See also:

Previous Posts on Agile Coaching Ethics