When we think of coaching we typically think of a relationship between coach and client where the client undergoes some sort of change, whether that's learning a new skill or something more developmental. But what about the coach? What happens to them in the coaching relationship? Where does the change come from? Does the change come from within the client? Does the coach change the client? Does the coach get changed as well, or are they separate?

I have been talking to a lot of other coaches recently and asking them how they see their relationships with their clients. I typically get one of four answers. I have started calling these the compulsion model, the crucible model, the catalyst model and the constituent model. Or, if you prefer, the 4Cs.

I am a biased person. I will freely admit it. I have plenty of biases. So are you by the way (if this is a human reading this, of course). If you are an algorithm, then you probably have biases as well depending on your training data. If you are some alien tapping into our internet to work out your invasion plan, then I can't say whether you have biases or not, but I do welcome you as our new overlords. The thing is, we all have biases. Some that we recognise and some that we don't.

When presented with solutions to a problem, I will generally pick the one that is best for the environment, or the one that is best for growing community. You may pick the one that makes the most money or is cheapest. Or you may pick the one that conquers the native population of the planet the fastest. The problem is that as coaches we are supposed to help our clients achieve their goals. Not ours. We are supposed to put our own biases aside and give the client what they want. But how can we? If we are filled with biases ourselves, can we really put them aside?

As coaches, we have it drilled into us that coaching is about results - help people and organisations set goals and achieve them. We get fixated on getting the result we (and hopefully our clients) want. Particularly in the agile coaching world, we want our clients to "be agile" and we work hard to get to that result. The problem we have is that we are looking for big changes and big results - make this whole organisation (or BU or Team) agile. That requires a lot of change and the one thing we know about change, any change, is that it's hard and slow. Big change is even harder and slower. Big change that not only changes the way people work, but changes the way they think as well, is just about the hardest thing you can imagine doing. Especially at any sort of scale.

So we are often looking for particular results, but not achieving them. The system is changing but not enough to get us our result. So our instinct is to push harder. Drive the change more to speed up the result. The big problem with that, as we saw last time, is that pressure drives resistance and the harder we push, the harder the system pushes back. By trying harder to achieve our result, we make our result harder to achieve. So what do we do?

I have been thinking deeply about my approach to coaching over the last year or so. Out of that has come my own personal coaching approach. I happened to mention this approach in a LinkedIn conversation with my good friend, Dan Prager, and this generated some interest. So, it’s time for a blog post on my approach to coaching. To be clear here, this isn't a collection of techniques. It’s not a way of structuring conversations. It’s not a set of categories for coaching interactions. It isn't any of the things you usually see in coaching approaches. It’s more my philosophical underpinnings of what makes for good coaching.

I call my approach the two C's model. Those two C's are Curiosity and Compassion. Those two things underpin my approach to coaching. To me, a great coach approaches the coaching with a spirit of open curiosity about the subject. They should also approach from a position of compassion for all those involved. For me, those two things are what distinguishes great coaching from good coaching. You can be a good coach without those things, but to be a great coach they must be at the heart of your practice. Let's look a bit deeper into why.

I was talking the other day with Peter Lam - a fellow agile coach - and, as conversations between coaches often do, the conversation turned to coaching. We were talking about the idea that the coach should not have an agenda when coaching - the coach is a facilitator for someone's personal growth. They are there to help the person with whatever it is that they want to work on. They aren't there with their own agenda. They shouldn't be there with their own agenda. Their own agenda gets in the way of the subject's personal growth. 

That's the idea anyway. But Peter said to me " that's all very well... but most of the time I do have an agenda. It says it right there on the label - Agile coach. I am there to get you using Agile techniques. That's what the organisation has hired me to do. I have a very clear agenda". So how does this sit with the idea of an agenda-less coach? Are Agile coaches, or any other "system" type coaches - devops, Human Centred Design, lean, change management, etc - doing their clients a disservice by coming in with an agenda?

Last time, I started talking about complexity and uncertainty, and how the rapid increase in both has made the world a very hostile and confusing place to many people. Why would a rise in these two things cause the world to look hostile? The study of adult development gives us the reason - people only develop the ability to understand and deal with complexity and uncertainty at later stages of adult development. Until people reach those stages, they will seek certainty, or at least the illusion of certainty. 

When that illusion is shattered, as it so often is these days, people need to re-form their illusion of certainty around different things - maybe my job is no longer certain, but at least my family is stable, and so on. When this happens again and again, people feel that their defences against the world are constantly under attack - the the world is against them. Their view of the world, one that might have served them perfectly well in the past, is now constantly under attack. All the old certainties that people used to rely upon - job, family, community, identity - are being continually challenged.

I thought I'd kick the year off with a few thoughts on coaching. I should make it clear at this point that I mean proper coaching - helping people develop themselves and not the "showing people how to to agile" type of coaching that should really be called agile process consulting rather than agile coaching. Over the last couple of years, I have been moving away from "agile" coaching and towards a more developmental style. As I have made that shift, I have seen that typical agile coaching is fundamentally limited. I'm not saying that it has no value, just that it has real value only to a relatively small subset of the population. 

I remember when I first found agile techniques and they felt intuitively right to me. They felt natural. They felt liberating. Many (if not all) of the agile coaches I have spoken to about this had a very similar experience. As coaches, we have all had the experience of an individual, or a team, or even an organisation that just "got it". They got what agile was about and just went for it. But we have all had the opposite (and far more frequent) experience of individuals, teams and organisations that just fail to grasp what agility is about. For whom agility is just following a new set of rules. Having different meetings. Doing standups and retros. When I speak to those people about agility they have a very different reaction to my first reaction. For them, agility is confronting, wrong and even suffocating. Why would that be? Why would people have such diametrically opposed reactions to the same thing?  My journey into developmental coaching has given me a hint of the answer - it’s our relationship with uncertainty and complexity.

Last time we started looking at the drama triangle - the three roles of victim, persecutor and rescuer - that people tend to adopt during a conflict. We saw that although the roles may shift over the course of a conflict, people remain stuck in that triangle, unable to break out, continually swapping roles but unable to resolve the conflict. We also saw the first hint of a way out of the triangle, by changing roles, not into one of the other classic drama triangle roles, but into something completely different.

Those different roles are creator, challenger and coach. To break out of the triangle, the victim needs to become the creator, the persecutor needs to become the challenger and the rescuer needs to become the coach. These three roles, although quite similar the victim, persecutor and rescuer (because after all they are the same people in the same conflict) have a shift in mindset that allows them to break free of the drama triangle and resolve the conflict.

You have walked into a firestorm. On the first day, management takes you aside and tells you that the teams just aren't up to scratch. They are always late, they don't have the skills, they don't care about business outcomes. Don't they realise that If we don't make the date, the company will struggle? Can you please go in and fix them?

On the second day, the teams tell you about management's unreasonable demands and how they are working late nights and weekends, with no recognition, struggling with poor equipment and environments, slow processes and constant micromanagement. Can you please get management off their backs and let them get on with it?

Day three you turn up and have both sides looking at you with pleading in their eyes, expecting you to come to the rescue and solve their problem. Welcome to the Drama Triangle. The Drama Triangle comes out of the family therapy area and was first described way back in 1968 by Stephen Karpman. The Drama Triangle states that in many interpersonal conflicts, people will assume one of three roles - the victim, the persecutor and the rescuer.

Vampires are lame. There it is, standing at your front door, cape, fangs, the full works. You have opened the door, it's looking at you, getting hungrier and hungrier. It's starting to drool. You are looking at it from inside. Giving it the finger. Perfectly safe. Why? Because according to the stories, vampires need permission to enter. You are perfectly safe as long as you don't say "please come in". Of course if they catch you out in the open later without a front door to give you protection, you might just regret giving them that finger.

So why am I telling you this? Because coaches have something in common with vampires. Capes? No. Because we descend on organisations and suck them dry? No. It's because we also need permission before we can do what we are there to do. We need permission to coach. But surely, I hear you say, you have permission. After all, you have been hired to coach, therefore you have permission to do so. Sadly, it's not that simple. What we usually have is permission to be there, not permission to coach.

"Come and have a look at my team" says my new stakeholder. "We have been doing agile for a few years now and while we started well, I think we have slipped back to old habits". How often have you heard this when starting a new engagement? Quite often? What do you see when you take a look? It's usually lack of planning, absence of meaningful retrospectives, ineffective standups, lax WIP limits, poor metrics, mini waterfalls. Yep. They have slipped all right.

When you ask the team why they think they have slipped, you will usually get answers like "we scaled up and things went wrong" or "the rest of the organisation is pulling us back" or "some key people left" or something like that. In my experience these are never the real reason. They may have contributed, but the underlying problem is something else entirely. That underlying problem is almost always the same - they never had the basics right in the first place.

We were having a discussion about coaching teams at work a few weeks ago, in particular how deeply embedded a coach should be, so I naturally got to thinking about teaching kids to ride bikes. I know that sounds like a stretch but stick with me. Back quite a few years ago when I was teaching my kids how to ride, I did a lot of observing of other parents and, being a geek, did a bunch of reading online about how to go about it. There are generally two accepted ways to teach kid to ride and the difference is on how long to leave the training wheels on.

Method one leaves the training wheels on for a long time - until the child is "fully confident" and the second leaves the training wheels on for the shortest possible time (there is a third radical method that rejects the training wheel altogether but we shall leave such heresy out of this discussion for now). I was, for the record, a method two parent but I observed a lot of parents using both methods. Method one is the intuitive one - leave the training wheels on until the kids knows how to ride then take them off and away they go. Easy. Trouble is, it quite often doesn't work out that way because training wheels have some significant disadvantages.

There seem to be two camps of agile coaches, those that advocate deeply embedding into a team and essentially becoming part of the team, deeply involved in the day to day stuff that the team does, and those that prefer to take on more of a mentoring role rather than being an active part of the team's day to day activities. For a long while, I was very firmly in the coach as mentor camp, and to a large extent, I still feel that that's the most effective coaching style long term. However, I have changed my opinion somewhat on the value of deeply embedded coaching for new teams.

I am now of the opinion that a coach needs both styles available to them and to be able to choose which is best in the situation they find themselves in. As both approaches have their strengths and weaknesses it is worth taking a look at both to see where they can be applied best.

One of the main technical practices that we recommend for teams is pair programming. Under pair programming, two people work on the same piece of code, with each checking the other's work in real time. It's a great way to boost the quality of the code delivered. It's not just code either. It works for testers (one of the most effective pairs is a developer and a tester pairing on something), UX designers, business process folks and so on. Any sort of work can benefit from a second pair of eyes.

Why then do agile coaches tend to work alone? It's very rare to see two coaches working together on anything. While we teach pairing, we coaches tend to work solo. I think this is unfortunate. On the few occasions where I have had the opportunity to work closely with another coach, it has always been a really good experience. So why then don't we do it more often?

Agile coaches help teams. Right? Having a coach to help guide a team means they are more likely to become a successful, high performing agile team. Right? That's why organisations are prepared to pay for agile coaches. But is there a down side to coaching? Can coaching hinder a team, rather than help it?

Imagine, if you will, a team. They are on about sprint 20, you are their new agile coach, taking over after the last one left. You are observing a retrospective and they are doing what they should be doing - working out what went well, and what didn't. "Why", you are thinking, "do they need a coach after 20 sprints? They seem to be doing fine". Then they get to the "what should we change for next time" bit, and all eyes in the room turn to you. "This is where you, as our coach, tell us what to do so we can get better" they say. "Work it out", you say, "Self-organise around the problem and solve it". "No", they say, "you have to tell us what to do". Then you notice that there is no sprint planning scheduled for the next sprint. "That's your job" the team says. "You tell us what to do and we do it". Welcome to the dark world of coach addiction.

Faster, Better, Cheaper. That's the way agile is usually sold. Faster delivery, with better quality and lower cost. That's the pitch I hear over and over from people trying to get organisations on board with agile. It's an attractive pitch too. Who wouldn't want something faster, better and cheaper? The only problem with the pitch is that it's not really true. Not initially anyway. Agility will eventually get an organisation delivering faster, better and cheaper but, at least initially, it will be slower and more expensive (it will usually be better quality though). It may well stay slower and more expensive for a long time if the organisation has to overcome a lot of legacy (not just code but culture and processes as well).

So when the organisation goes to measure its new agile initiative and finds that it's not getting what it was sold, questions get asked. And well they should. The first is usually "Why?", to which the standard answer is "cultural change is hard....", the next is usually "When?", to which the answer is usually a shrug and some more about how hard cultural change is. This is often the point where the senior leaders that were really keen on agile, suddenly stop being keen on agile and organisational support vanishes. Given the length of time it takes a big organisation to get to faster, better, cheaper with agile, we really do ourselves no favours by using that as our selling point. What we need is something we can have an immediate (or at least relatively quick) impact on, that is also going to have a positive impact on the business. Fortunately it exists - risk. Agility should be sold as a means of reducing risk.