In my last article, I explained what I think agile coaches do in practice. But I did not reveal some of the complications and messy bits that get in the way of adopting the model in any sensible way.
So in this article I will explore some of the complexities and messy bits.
Where we got to
I went through these two models as a conceptual basis for coaching:
Based on that I came up with the idea that coaches ask three questions.
The answers to these three questions determine their coaching approach to use:
- Who am I helping?
- What do they need help with?
- How can I help them?
So, if it is that simple, then what could possibly go wrong?
Should we use planned or emergent coaching?
The first problem is that some coaching is planned while some is emergent:
- Planned coaching means that you assess the situation, plan an approach and then go and execute it. For example you decide to help a team by facilitating all the meetings for 6 weeks. Then you will look at mentoring someone else to take over.
- Emergent coaching means that you learn as you go and your coaching strategy emerges from the process of coaching. As you work with the client, opportunities arise for you then coach people in the moment, based on what happens.
You can probably use many of the same tools and approaches in both situations by paying attention and then deliberately focusing your energy. But I find that it is sometimes useful to think through how emergent or planned you hope to be.
One way to do this is to decide what percentage of your time to spend on each – for example I will assume that I will be 60% “emergent,” seizing opportunities as they arise and 40% planned – executing according to my planned coaching approach.
For some reason people don’t seem to like percentages so I often use dollars or brass razoos. If you are not familiar with a brass razoo, is a mythical currency that is actually not worth anything.
If I am buying some coaching for the team, I will spend 40 brass razoos on our planned coaching approach and 60 brass razoos on responding to what ever opportunities present themselves.
This may seem like a trivial exercise but I have often been caught out planning my coaching approach and then realising people wanted random help, that I was not expecting. It is called a predictable surprise – I did not know what the surprise would be but I should have known something would come up.
Similarly, I have often found myself being really customer focused and responsive and then realised that I was just reacting each day to whatever came up, without following through on the areas that needed the most focus.
Can you really focus on one thing?
In my simple model, you choose what to focus on. But in fact the real world is always messier than that.
So in fact you might be partially working with the team and partially coaching some key players in the team. You might also start with some consulting and then move to a mixture of mentoring and facilitating for the team and mentoring/coaching for the key players. It all gets a bit confusing.
So I use the brass razoo approach again (or $100 approach).
- I might say that I will be working 50% with the team and 50% with key player one.
- I might also say the team need 60% of their focus on better technical practices (which I can not help with) and 40% on agile team practices.
- Finally, I could mentally state that I will be 80% mentoring and 20% coaching
All this sounds complex and it can be overkill. But sometimes I do find it useful to get people to bid on where they would spend their money if they had to choose. If helps to clarify where we want to focus our energy.
Of course you might just say that
I will use a combination of coaching and mentoring to help with team practices and I will be spending about half my time with Jo and Bo who are the facilitator or product owner.
Does the team really need a coach or a coalition of people
One of the things that I often find disturbing is that there is one super-agilista coaching the team and then also coaching th emanagers and the customers in all things agile. I guess this is possible but it raises two concerns for me:
- Will the coach really be flexible enough to provide everything needed, or will their bias mean that they default to their comfort zone and coach the team in that; and
- If there is one guru and a village of followers then it is often hard to hand the power over to the team. Instead the team become addicted to the coach and then the team needs them involved all the time. This means coaching has actually failed because the team did not learn to own their own journey.
So a focus for me is always to find the coalition of people within the team, and outside where necessary, who can contribute to different parts of the journey. If I can do that then I usually find that the team can take on more of the journey than I expected.
In fact a potential measure of coaching effectiveness can be taken from a metric that teachers use …
How much of the effort in learning is being expended by the teacher and how much is being expended by the student?
Apparently when you start teaching kids, they often want to kick back and rely on the teacher to teach them. But far more effective teaching comes from encouraging the kids to do their own learning.
So senior teachers will sometimes observe a junior teacher and assess whether they think the teacher is working harder than the kids or the kids are working harder than the teacher.
I use the same approach with junior coaches – how much of the effort is up to the team and how much are they relying on the coach. The more the team are doing it themselves, the faster they learn. This is true even if it then looks like the coach is doing less. In fact the ultimate goal of the coach is to become expendable.
A bit of a rant
As an aside – I believe that this is one of the reasons that organisations with less coaches sometimes progress faster than organisations with many agile coaches.
Where there are many agile coaches, they will all step in and find something to work on, but this means the teams can leave the coaches with the effort and accountability for change, which never works.
But if there are not enough coaches then people in the team get annoyed that they are not not getting enough help and people then step in to take on some of the accountability and effort for change before they feel that they are ready.
So people are working outside their comfort zone, with the coaches feeling guilty that they are not able to help people enough. Mistakes happen and things take longer than they should. But the burden of taking things on before people are ready is actually accelerating the learning and building resilience.
This leads to an odd idea – the inverse law of agile coaches. The more agile coaches you have, the slower the journey. The fewer you have, the sooner people adopt the agile mindset.
I say its a law – its more an opinion that is unsupported by empirical evidence.
Back to our story
All this discussion eventually leads me to the conclusion that we need the coach to build a culture of coaching rather than just coaching people.
Some coaches will talk about this as “release 2.” First they will coach the team and then at some point in the future they will hand coaching over to the team when they are ready.
But actually – you can get people coaching each other early on (ie from day one) if you remove the mystique of the guru.
Most of the team will fall short of “confident to teach agile” if they have never done agile before. But that can be a distraction.
A senior developer can “coach” in coding practices and a communications person can “share their secrets” when creating communication plans.
Not all the coaching should be about the agile mindset or the practices of scrum or something “agile.” Instead we should do what teachers do with school kids – encourage the crew to teach each other.
Some might mentor others in how they do stand-ups or the basics of agile.
However, the does not only need to focus on agile practices. You might learn in a retrospective that the team are single point sensitive in “SQL for testing data stuff.” For the next couple of weeks the person who knows what they are doing (“SQL stuff”) mentors or coaches others so they become self sufficient.
Or you might find that an SME (an expert) knows a lot about one business area than anyone else. Then instead of just grilling them, that person facilitates the work done by others and provides a safety valve when they get things wrong. It is slower going but the team become more resilient and better skilled.
You can argue that this is not about agile but I believe that it is coaching and that it leads to the team being more agile.
Do all agile coaches actually coach?
All of this waffle and pondering began when I had an argument (err … an in-depth discussion) about what agile coaching is and when someone is an agile coach.
One of the points of disagreement came when I mentioned that some agile coaches I know (and respect) are actually not spending much of their time coaching.
They are less hands on and more involved in co-coordinating other coaches. They are a kind of an “agile coach deployment system” rather than an agile coach.
These “Agile coaches” meet with people and then send in a coach, or they debate the best way forward for the organisation and then work with the coaches to actually coach people in it.
I claimed that this meant that they were not actually coaching.
Then one of the gang asked if I would call someone an agile coach if they were not coaching.
I said no.
Then they asked me if I would call them an “agile coach deployment system” or a “traffic warden” instead of calling them a coach and I said:
I don’t know – maybe I would call them an agile coach
So that means I am confused. I don’t want to say that they are an agile coach if they are not doing any coaching. But nor do I really want to refer to them as deployment systems.
So now I believe that I could say – she is an agile coach:
She is helping the broader organisation to go agile by facilitating the resourcing and the research needed for effective agile coaching
Of maybe I could say
He is helping the wider organisation to find better ways of working (by using a consulting approach) to identify and help people tackle the current issues that stop teams being agile.
I am happy with this – You can be an agile coach where you are not technically “coaching” but you are helping the crew to go agile.
I’m not sure if you agree but I think this is fine, even if it means I must now agree with the people I was arguing with 🙂
Do all agile coaches actually teach agile?
At one point in my career I missed out on several coaching assignments in a row because I found out they did not need me – and worse, they did not need me for the same reason each time.
In each case I did an assessment of the team’s needs and found that they really sucked at testing. There was little point in getting better at anything else because testing was the one thing that was clearly holding them back.
This is a problem for me because, although I think testing is great, there are other people much better suited to helping teams improve their testing practices than I am. So my recommendation was “get some help with testing, then call me later if you want to.”
The coaching agreement process really helped us realise that they should agree not to use me. I guess you would call it a coaching non-agreement.
Similarly I think it is good to write good code, but I have no idea how to do it. So if the challenge is to do better technical work, then maybe you need a senior developer, architect or master craftsman to coach you.
But that raises another question. If the goal is to get better at testing , so that it becomes quicker and easier to create value (ie be more agile) and you bring in a test guru to help, can you call that person an agile coach?
Is someone who helps you with testing an agile coach, or are they just a helpful tester?
My friends all said no, they are not an agile coach. They are a testing coach or a testing consultant but not an agile one.
But then what if they are a member of the coaching team, or they are adopting agile practices to improve testing, or they just want to be called an agile coach because people think testing is only done by testers.
I think you could call yourself an agile testing coach even if you are just improving basic common sense testing. But not everyone agrees with me
Let’s play it out here – I think you could say that
I am helping the team become more agile by consulting to identify the major opportunities for improvement in their technical testing
If this is the case, then helping with testing can be part of the agile coaching journey.
This is useful, because it means that you can adopt the same approach to setting up a coaching agreement, or you can integrate “agile coaching” in team practices or mindset with me and support to “improve testing” with Bob the builder. Alone we help the team to partially become great, but together we provide a cohesive approach to team improvement .
My conclusion
I can be a bit too pedantic about the definition of coaching, so maybe a better approach is to be flexible in the approach I take, based on what the team need, rather than a correct and pure definition of coaching. This is my lesson to focus on for the moment.
But it is good to be deliberate in your coaching. It is useful to observe and consider when you are ad-hoc (emergent) and structured (planned) in your approach.
It is also good to stop and think about how much time you are spending with different people on different things. Because this will again improve your focus.
I also think it is arrogant to assume that one coach will be able to help a team with everything that they need in order to improve.
What that means is that a core role of the good agile coach is to facilitate the team’s learning so that they identify their next challenge and find the right person to help them meet that need.
I think this is a critical skill that separates the “agile coach” from the “really good coach”.
Especially if you help the team look inside the organisation (and especially inside the team) in order to find their next step. And especially if a lot of the coaching is being done by people who would not see themselves as real agile coaches, but rather as as people who can help the team improve in some area.
If you can get this happening then it means that you can scale your effort up and down with a team over time – hopefully finding yourself expendable much of the time and really focused when you are needed at other times.
James King 