How do you identify a proper agile coach?

One of my personal pet peeves is the huge amount of "imposters", i.e. self-proclaimed, potentially even certified "Agile Coaches" who are jumping into a high-demand market.
The problem they cause: Not understanding what a coach even does, how to properly coach - nor what the intended outcome of coaching is supposed to be, they ruin teams rather than establish them.

A year ago, I myseld would have gotten a decent score on this list, and even today, I'm still learning. It is through my contact with a few select, truly inspiring coaches that I have learned the difference.
If you think you're a coach, you can use this list to reflect. If you are looking for a coach, this list is a non-extensive (potentially growing) list if things you want to look out for. Careful: A job interview may not be when you discover the signs. I observe my peers at agile conferences and meetups - and thus, this list was compiled:

How do you identify bad coaches?

When you notice these things about a "coach", proceed with utmost caution:

#1 Doing what the client asked

Most companies need agile coaching, because they don't know what agility is - and most likely also have little understanding on the power of growing people. As such, these clients can not be expected to understand where specific demands they utter are supportive or detracting agility. The agile coach should remain true to their role and also work with the very people who hired them, even when that means correcting the initial mandate.

- The Client doesn't need what they ask, but what they don't know.

Question: How can you understand the difference between what the client says and really needs - and how to get there?

#2 Calling Agile a method (or: process)

Many companies look towards "Agile" in the hopes of obtaining a better software development process. The "Agile umbrella" contains a whole bunch of methods, tools and techniques for improving both the way and outcome of development. Clients may believe that by changing the structure, adopting new roles and using new techniques, they will be agile. Bad coaches will go about doing exactly this and never realize that the systemic problems are caused by a philosophy that isn't consistent with agile development, therefore - never solving the root cause. The consequence? Yet another cargo cult. Lots of fuss, little benefit.

- Agile requires a mindset shift

Question: Can you identify the main reasons that might interfere with a new process doesn't yield benefits?

#3 Agile is considered a goal

Agility can never be a goal in and of itself. It's context sensitive and has to depend on the company's optimization goals. For example, agility in a fast-paced environment would look completely different from agility in a safety-critical environment - as agility accomodates the needs of the business, customer and market. It is merely a means to become more successful. "Being agile" isn't successful when the company can't meet the market demands.

- Agility is a means, not an end

Question: What is different once your client "is agile"?

#4 The Silver Bullet

Let's take, for example, Scrum. Scrum makes a lot of implicit assumptions on the team's environment for the team to succeed. When those assumptions aren't met, Scrum may potentially lead to disaster. Coaches need to be aware of what the success factors are, and then either first work to enable the conditions or choose an approach that is compatible with the current reality.

- Solution agnostic adaption

Question: How do you know that your approach will succeed?

#5 Preaching dogma

When you have a pressing problem in your organization, the last thing you want is a religious sermon on how you're not adhering to whatever dogma the coach subscribes to. This can get very irritating when the coach is unable to connect the current situation you are in with specific, actionable measures that will help you out.

- You need a pragmatic way forward

Question: How do you turn ideals into results?

#6 Hypocrisy

Advice given by coaches is doubtful when you don't see the coach themselves doing the very things they advise. The worst thing is "special pleading", claiming that they are exempt from the rules they want others to follow. The peak of hypocrisy is reached when they are pleading special on absolutes, for example: "Everyone must..."

- "Dogfooding" also applies to coaches

Question: Are you applying your approach to yourself?

#7 Narrow-mindedness

“Whatever the mind can conceive and believe, it can achieve.” - Napoleon Hill

Different thinking leads people to different conclusions. Speaking in terms of "right and wrong" becomes extremely difficult for an open-minded person who considers others' perspectives equally valid to their own. The faster a coach is in making statements like "No", "Wrong" or "Bad", the more likely they are narrow-minded. 

- People have reasons for their thoughts, words and actions.

Question: Will both participants leave the conversation with a sense of a broadened horizon?

#8 Preconcocted solutions

Maslow's "Law of Instrument" or "Golden Hammer" is a cognitive bias indicating that when you know only one way to approach a situation, you will rely on that way - regardless of whether it's a good idea or not. Similar to narrow-mindedness, the inexperienced coach will throw the one solution they know at the problem and hope that works out.

- Explore multiple feasible solutions before stepping into the solution space

Question: What will you do when you can't use any of your "Golden Hammers"?

#9 Change Push

Sustainable agile transformations rely on autonomy and intrinsic motivation. It is extremely challenging to find the levers within the organization where people *want* change and are willing to change something. It's much easier to push the change on others. This produces results much faster, but people will gladly return to old habits as soon as the coach is out of the building. Even "hard selling" is still pushing, so "convincing others to do what I say" doesn't count, either.

- Relies on "Pull". People must want the change.

Question: How will you approach change when met with resistance?

#10 Arrogance

I recently encountered a coach who literally said, "Everyone I work with is an imbecile." They may never have said this ad verbatim to their clients, but this coach carries the burden of the hidden belief that they are somehow better than the people they work with. This doesn't permit the coach to have a deeply rooted relationship of equals with their coachees. At some point, this attitude will become a barrier to coaching. This strikes as the Dunning-Kruger effect: " How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments"

- Radiate an aura of appreciation and humility

Question: How would you classify people with different levels of competence?

#11 Trying to change behaviour

There's an entire coaching approach called behaviouristic coaching, so behavioural coaching isn't inherently an issue. However, behavioural coaching doesn't focus on changing behaviours, it focuses on changing the beliefs which lead to the observed behaviours. The behaviour is *never* the problem - it's always a belief issue!

- Focus on beliefs

Question: What do you do when someone does things that should be changed?

#12 Process Change

Processes are external structures. They do have a strong effect on outcome, and of course, agile transformation is supposed to have an outcome. Any structural change is ephemeral - until people change what they believe, they will revert to familiar structures, and the longer a structure existed in the past, the more likely they will return. Once people understand how their old process was worse than what they can realistically do right now, they will drive the process change themselves.

- Change minds, then processes will follow suit

Question: How do you approach change to processes?

#13 Certainty

"I know that..." - Socrates would conclude this sentence with "... that I don't know anything."  The knowledge in the world grows faster every day than any human could learn in their lifetime. With new knowledge comes the revision of old knowledge - former beliefs no longer hold true. As Kant put it, "Reason puts to trial like a judge every statement presented and interrogates every witness to discover the truth." Our understanding grows as we learn to ask new and better questions. 

- Constantly challenge beliefs

Question: Which is the most fundamental belief you have changed recently?

#14 Blame-shifting

Even our very existence already affects the situation. When things around us go wrong, we always have a hand in it - knowingly or not. It's very easy to accuse or blame others for their actions, yet many people seem blind towards themselves and how they have affected the outcome. At a minimum, we need to understand that if we ourselves had done a little better, the outcome might have been better. Coaches are hired for leverage - and when the effect is undesirable, it's just not possible to fully abjure oneself of any form of responsibility.

- Be aware of the effect of yourself on the situation

Question: What do you do when a situation gets out of hand?

#15 Wallpaper Certificates

Certifications entitle people of being called something, more certificates entitle to better jobs. Or, so some feel. The difference between certified people and uncertified people may just be that certified people follow paths gone by others, while uncertified people do things that nobody else has done before. As agility is about finding new and better ways, the coach better have some experience which can't be minted into a certificate. If all the coach offers can be packaged in shined, stored, standarized boxes of certification, the coach isn't going to bring the team into new territory.

-Pioneer and discover

Question: What's the last thing you did that nobody did before?

#16 Relabeling

The easiest way to kill an agile transition is to reassign labels and keep the same structure. Product Managers become Product Owners, Team Leaders become Scrum Masters - and line managers become "Agile Coaches". There you go, transition done. That was easy. Nothing accomplished. Genuine change goes far beyond assigning new labels - the way of working is different and people may discover they aren't suited for the role that they were intended for. 

- Reframe the situation so that old structures don't stick any more

Question: If we remove any form of labels, new and old - how do you create a different structure?

#17 In it for the money

Certain certification bodies even advertise that agile coaches earn better money than traditional roles. Of course, this attracts people who are looking for easy ways to earn better money. They come, grab as much money as possible, then leave. Coaching, however, isn't about doing work as much as it is about making meaningful change. A good coach should have a portfolio of people who will tell stories how things have changed through coaching.

- Build positive relationships

Question: Aside from the money, what have you gained when you exit an engagement?

#18 Demanding trust

Trust is a precious and fragile commodity. You might consider trust like a porcelain vase: Once shattered, it leaves numerous shards that create a mess and leave deep cuts when touched. Demanding an upfront reserve of trust can leave people mortally wounded when exploited. Some environments make it difficult for the coach to build trust relationships, especially when managers are known to play a hidden agenda.

- Invite trust by extending it from your side

Question: How can you gain trust in a low-trust environment?

#19 Judgmental

It's easy to say that someone isn't coorperative or performing poorly. It becomes much more difficult to make such statements when you see that people are very good at adapting to their conditions and that their actions are the consequence of a very long history which formed them to become like they are. As coaches, we can't be fast to judge people without understanding why they are the way they are.

- Consider events, causes and circumstances

Question: What do you do when someone does a really poor job?

#20 Insistence 

The worst thing a coach can do is insist they know "what is right" and others don't. This is also the fastest way to create distrust and damage relationships. Those who insist on others following their lead aren't leaders in the first place. Real leaders make others *want* to go the right way, then offer help in moving forward. At the same time, they are forbearing when others choose a different route.

- Accomodate, provide leeway

Question: How far will you budge to make your coachee comfortable?

Bonus - Taking any job

A coach has better things to do than work with organizations who intend to abuse the coach for ulterior motives - or who don't even have an intention of receiving coaching. Roles such as "Delivery Manager / Agile Coach" should ring an alarm bell to serious coaches. Especially when the job description contains terms like "Responsible for the delivery" or "Reports individual performance", that's clearly a non-coaching role. In an interview, the coach would clarify what the real intention is, whether the job ad was written out of ignorance - and how this is supposed to turn out later. 

- Turn down offers that are in clear violation of a coach's identity

Question: How can you be a coach if you're expected to not coach?

Being a Product Owner

I am a Product Owner. I'm on a mission to create great products.

I don't have a title

Some clients call me "Agile Product Manager", "Agile Project Manager" or even "Agile Architect".
To be honest, I don't give a hoot what you call me. I'm not in it for title games. Titles don't matter.
Those who know me call me "Michael". That's me, and that matters.

I am the product

When I get up in the morning, I think about what the product needs. When I drive to work, I consider the challenges my product faces. While I am at work, I discuss the product with others. My discussions are centered around the product. While I eat, while I walk, while I dream - the product is there. I am the Product - you do something for my product, you make me happy. You mess with my product, you hurt me.

I am narcissistic

I identify with the product. I want the product to be great. I feel with my product. When my product suffers, I suffer. When my product succeeds, I succeed. I don't take criticism on my product lightly. If it's justified, I will do everything I can to improve. If it's unjustified, I will give you a chance to correct your opinion before you get a problem.

I don't accept "requirements"

I dedicate myself to making the product rock. You are allowed to explain to me why you think that the product should offer a certain ability, but you can't make me build it. If you manage to convince me how the product will be more desirable with your idea, I will place it in the backlog. Otherwise, you're short on luck. And no, I don't care for your job title. I care for the merit of your idea.

I don't work for you

I work to build a great product. If you have a need for which I have a vision, and you are willing to fund me to find excellent ways of turning your need into results, we can have a talk. I will dedicate my time, energy and every brain cell to making the product happen in a way that meets your needs and expectations, in terms of the product's content, price tag and its value. We will work together as long as I can bring the product forward and the product brings you forward. When either is no longer the case, we will part ways.

I protect my team

I need my team to make the product rock. I invest my time into instilling the vision into them and I enable them to do what they need to. I respect my team members, because I know they do the best they can. Without them, the product vision would remain a mental blob. When someone messes with my team, they have a problem with me. And I don't care what title or role that someone has.

I don't follow Scrum

Judge me or condemn me if you want for not living up to whatever agile bible you follow. I don't give a hoot, either. I'm not in it for a methodology. I'm in it for building a great product with a great team. I don't follow Scrum - nor anyone or anything else, for that matter. When rules and regulations become impediments to doing what needs to be done in order to succeed, I will stomp over them. As long as Scrum follows me, I'm fine. When it no longer does, it better get out of my way.

I am an extremist

I understand moderation, but I also understand that there will be no change without change. I am the PO because I want to make a difference - and since I can't get everything, I need to deal with extremes. From there, we will explore together how far we can go and what it takes to get there. If I didn't have radical ideas, my product would suck.

I don't insist

I am actually quite easy to convince that I need to reconsider my choices, except that I need evidence: Experiments that prove otherwise, business figures that point in a different direction, systemic causes which make other approaches more favorable. "I don't like it" doesn't cut it, I want hard facts. Solid, reliable information. In fact, as new information becomes available, I constantly reconsider my next steps.