Extending the coaching agreement – what do agile coaches actually do?

In my last article, I discussed what I think is NOT actually agile coaching.

This time I will tackle the tougher challenge – what does a good agile coach actually do?

A quick word of warning though – this simple question seems to have resulted in a long article. I apologise for not making this as short and to the point as it should be, but at least I have warned you.

I presented the following model to some agile people and they seemed happy enough with it, at least until we discussed it in detail.

So let me walk you through it and see if it all makes sense to you or not.

How does the model work?

When I coach people, I like to form a coaching agreement (sometimes I even do a contract with the person paying and a separate agreement with the victims that I am coaching).

So the conversation usually starts like this:

Client – I need some good agile coaching

Me – Do you mean you want me to coach you personally

Client – what?  Er, no.  I mean we want some agile coaching. But its not for me

Me – cool – who needs help then?

Who needs help?

My new client and I always discuss who it is I am helping.

It might be a particular person, or a couple of people.  I love coaching a couple of key players because then they can go and coach everyone else.

Instead though, it often turns out that I am coaching a complete team, or a group of teams.  This is fine, but it means that I need to take a slightly different approach – more workshops and more observation, but less cups of tea.

Sometimes I am also engaged to help “The organisation” rather than a specific team.  I love this work too, because I love tackling the annoying impediments that stop a team going agile.

But it is important to know the answer to this question:

Are you helping a team to be more agile within the current constraints of the organisation, or are you helping the organisation to change in order to let the team be more agile?

I often find that, while I am officially helping the organisation change, the early stages are focused on getting the team moving within the existing organisational constraints. This then puts pressure on the organisation to drive further change and gives me credible ammunition to use when suggesting wider changes.

Assuming though, that I am helping the people find ways to do understand how to work in an agile way, we continue.

The question of “whom am I coaching?” sounds simple but I usually find that it takes me time to find the answer and that the answer shifts as the journey progresses.

None the less, knowing who you are helping right now is critical to you if you want to focus your energy in the right place.

What do they need help with?

The next thing I want to assess is where my help is needed the most.  So the conversation often goes like this:

Me – Great so I am helping “them,”  what do they need help with?

Client – being agile I guess

Me – that’s lucky because I am an agile guy.  What is stopping them being more agile?

Client – err, the lack of agility I guess

Me – Oh, OK – great, let’s explore that in a little more detail

Sometimes people know exactly what they want, but more often than not, they are asking for help because they are still unsure about what they need.

I find this is true for me too – when I ask for help I am often not sure what I need until I see it.

When I coach, my sweet spot is product ownership, product and process innovation, governance and cross-team collaboration.  But that might not be what is really needed by my client and their team.

So I like to assess which particular areas they want help with the most.

For example it might be to improve the technical practices, or to adopt the team practices of, for example, Scrum, design thinking or lean operations.

Either way, the client and I are looking for those potential areas of improvement that are likely to have the greatest impact right now.

Sometimes we can form a hypothesis very quickly and sometimes we need to do more work.  I have found that it is often better to guess, try something and then get it right … or just as often get it wrong.

Based on what we get right and wrong, we then adjust our approach and try again.

This seems to work better for me than doing a detailed assessment that will give me a great deal of confidence of exactly where to focus.  I am not sure if my approach is more agile or just my own preference due to my cowboy like background.

Me – So I am off to help the team

Client – great, let me know how it goes

(2 days goes by)

Client – how is it going?

Me – wow, your team suck at testing and they have so much technical debt that they cannot write good code.  They are very sad

Client – I heard that.  Lucky you are here

Me – yes, I think we should start doing some stand-ups

Client – Will that help with testing and code writing

Me – no, but I am good at stand-ups

Client – are you sure that is what we need to focus on?

Me – um, no.  I guess some help with code writing would be more important

 

How can an agile coach help?

This brings us to our final question – how can I help?

But there is another problem that I often encounter.

I want to help people with their teamwork, their goal clarity and their problem solving.  But what I often find is that they really want and need help in is testing, code writing or something else.

Where this is the case, I am the wrong coach.

So rather than continue to coach them in things that will probably help a bit, I would rather get out of the way and let them focus on the things that will allow them to make real progress.

Then I can come back later, if needed, and focus on the things that I think matter.  I’ll go into more detail on this in a future article, but this is a common finding of mine:

These people need help.  I can help with some things that will make some difference.

But if I am honest, what they really need right now is not me, doing not what I am good at.

The best coaching support I can give them right now is clarity and permission to focus on what they believe is needed and then get out of the way.

So one of the best things about good coaching is that it can create clarity, which then empowers people to tackle their own problems, leaving the coach with time to read a good book or something.

In theory this should mean that you will run out of work pretty quickly.  But for some reason I find the opposite is true. In fact iy leads to one of the inverse laws of coaching –

If you help people understand what they really need, they usually won’t need you.

But since they don’t need you, fun work will come and find you through the magical karma of good coaching and you will be ready to start on it.

Even though we often claim people should act on evidence, this is one area where I just think it will turn out well and it always seems to. This is probably more superstition on my part that hard science.

Speaking of superstition and magic, that brings us right back to the same question – if we can help, how can we help?

I have met quite a few people who believe that having an agile coach on-board is similar to having a rabbit’s foot in your pocket. The coach seems to bring you luck even if nobody is really sure how it works.

Thus, having agile coaches wandering around helps teams become agile, even if we are not sure how. In line with this belief, we send coaches off to work with each team and then wait for agility to appear.

So my initial conversation with the client often gets a little messy at this point:

Me – So “these people” want help with “this stuff”

Me again …

The Rabbit’s foot theory of coaching suggests that having a coach around will bring the team luck and they will therefore become agile through radiated agility.

But there is mixed evidence as to whether this actually works.

There is another theory that coaches need to be deliberate in how they help the team and that they need to work with the team to co-create a specific and deliberate approach to coaching, rather than just turning up and hanging around with the team.

Client – OK, lets go with the rabbit’s foot approach

ME – Cool, or, let’s just explore another option first and then decide

Client – Sure, and then we can go with the rabbit’s foot approach

Me – err, anyway, lets look at the other option as well and then decide

When an executive coach talks coaching, they actually use a specific definition of coaching.  But when an agile “coach” talks “coaching”, they mean a combination of different things.

Let me demonstrate with a diagram:

I guess I had better explain this.

When I was speaking to some agile friends we all agreed that a coach might mentor or coach a team and that these are different things.  Unfortunately we seemed to disagree on what both the terms actually do mean.

So this diagram shows my take on things.  This is not supported by the agile community and is “James King” practice rather than best practice.

A better description of how most people see things can be found here:

https://www.agilealliance.org/resources/sessions/mentoring-vs-coaching-show-me-the-difference/

There is nothing wrong with that understanding an mine is similar.  But I deviate a little here.

From my perspective, the coach can focus on one of two goals.  Either:

• Focus on helping the team get their work done, identifying and tackling the issues they face; or
• Focus on building the capability and the resilience that the team have, in order for them to be able to identify and tackle whatever issues arise next time.

Of course, each of these approaches supports the other one.  If you help someone solve an issue then they are better equipped to apply a similar approach in the future and if you help someone build a skill, they will probably look for examples of where they can apply it.

But regardless of your goal in coaching, you can achieve it by:

• Helping them solve their problem – helping them do it right this time, so they learn how to do it and then they apply what they learned; or
• Helping them identify and explore their needs so they understand their problem so they can find their own solution this time, learning through the struggle of solving the problem themselves..

Of course, you might move between these approaches. But I find that it is better to deliberately start with one approach and to try to be deliberate when deciding how to help.

Putting all of this into a diagram creates four distinct “ways of helping:”

• Mentoring – providing expert advice based on your experience and knowledge.  The team or client can then consider this advice and follow it if they want to.
  • This should equip them with the skills to tackle problems.
  • As the saying goes – you can learn from your own mistakes but it is better to learn from the mistakes that others have made in their journey.
• Facilitating – making it easier for them to solve their problems or complete their mission.
  • For example, the coach might act as the scrum master or tester for a period of time so the team can learn while seeing how the experienced coach does things.
  • This also has the benefit that the team can get things done while they are learning.
• Consulting – observing what is happening, investigating and asking questions to uncover the real issues and opportunities.
  • Then using this information to provide options that the client can choose from.
  • Note that this is my definition of consulting and it seems to differ from what some people say.
• Coaching – Observing, asking questions and providing feedback for the client to explore in order to identify their real needs and opportunities.
  • Unlike consulting this is focused on their capability to solve problems, not on discovering and fixing their problems.
  • As the saying goes – it is not the right answer you seek grasshopper, but the right question
  • Unlike mentoring you are not providing advice, you are just torturing them with questions and comments like “look within for the answer.”

In agile, people often talk shu-ha-ri, which I think matches the mentoring and facilitating patterns.  People learn from a master craftsman and then become experts in the craft themselves.

But coaching and consulting have the advantage that you respect the possibility that the client is actually better at their job than you are.  I have found that often, the team really know how to be agile, they have just forgotten.

The person or team doing the work usually knows how to do the work better than any outsider.  I have seen evidence because:

• Every project ends in a sprint – so the end of the project is often agile
• People often adopt tight collaboration and fast feedback loops to validate their assumptions in a crisis.  Then they forget how well they performed and go back to their bad old ways until the next crisis

If this is true, then people know how to be agile, they just get distracted somehow and need reminding

Based on this belief, I have a bias for coaching and consulting.

Often, however, what people really need is just to see how someone else does things and then to apply their own thinking, rather than having me give them options to consider while they are still unsure what is going on.

Or they need someone to facilitate the process so they can focus on the work while they also observe and learn.  After that, they are better placed to find their own solutions.

So there is no best approach. There is only “what looks like the best approach for this team at this point in time.

My conclusions

Start with some questions rather than with trying to provide answers

So what does that mean?

It means that when you are an agile coach, the work you do will depend on the context within which you are doing it.  Rather than going in with the answers, it is better to start with some questions:

• Who am I coaching?
• What do they actually want or need help with the most?
• How can I help them with that?  Or even Should I be the one who tries to help them with that?

Also – you will need to shift gears a few times

We are not just helping the team learn a new way or working, we are helping the team find their own resources for them to use in learning new ways of working.

This sounds hard but it usually makes the journey a lot easier than if you have the burden of guiding everything yourself with one approach …  that you have been told is the correct way to coach.  I will go into more detail on this in a future article.

The key is to not just focus on the things you want them to do, but to focus on building and leveraging the concepts of self-sufficiency, empowerment and cross-functional collaboration that create the environment needed for an agile mindset.

To do this, you can apply different approaches.

Then you can let the team drag you along with them as you all go on the journey together.

At least that is my opinion and it is easier to argue the case in a blog when nobody can contradict me.  It is still a conversation I am having with some of my peers who have different, but well-reasoned views to me.

Next time I will explore some of the complications and issues in trying to adopt this simple approach.