My understanding of effective Agile Coaching
Since years I work as external Agile Coach. From the beginning I searched for a good definition on what is agile coaching and was never satisfied on what I found. In this blog post I want to describe my understanding of our way of agile coaching and what is makes essential for our success at our client.
So many people call themselves agile coaches. My impression is that the impression on what agile coaching is is quite divergent.
One definition of coaching: “Coaching is unlocking a person's potential to maximize their own performance. It is helping people to learn rather than teach them.” (by John Whitmore)
Some people say about a person, that the full solution lies already in the client itself and we just have to unlock it in our coaching. Others go more in a direction of a consult the expert, who knows the solution and should prescribe the solution on the new way of working. And again others just see agile coaches as another name for Scrum Masters. See also the comments by Sigi Kaltenecker & Bent Myllerup on Agile & Systemic Coaching.
From my experience both viewpoints doesn't fit to the way I do my job.
Coaching - just have to unlock the solution in the client and the sense of urgency
Most people don't do such a deep change on becoming agile just for fun. There is a sense of urgency that drives the need to change. Just coming from a coaching perspective on step by step discovering the solution takes too long for them.
Clients expect from me as the expert to help them to get faster to the benefits they hope to achieve. Often their even hope to get the solution, that they expect from an external expert/consultant. I can use parts of coaching approaches like systemic coaching, but at least I didn't saw it suitable to stick purely to this perspective.
Consulting - Prescribing the one solution and the risk by the unknown context and long term sustainability
Major part of my work is to help organisations or teams in a limited time. With teams I just work in a few weeks to get them started. This creates a pressure to get to quick results, but going to the client and defining the one solution sounds unsustainable, risky and disrespectful.
- Disrespectful - By my few days there I can't never know the things the client knows about his environment with their people, products, systems and customers. I find I disrespectful, that I know on how their solution looks like. Their are so many variables and they know so much more about their environment.
- Risky - By this lack of context it is likely to miss the point and make wrong/stupid suggestions, that could cause a lot of damage.
- Unsustainable - It should be their system, that with their help will emerge over time. Their environment will change and they need to be ready to adapt their system to their needs. Just placing their my solutions brings risks, that they would stick to the system blindly based on my initial suggestions or
that they are incapable on developing it on in a meaningful way.
First I thought the problem on just sticking on how your agile solution should look like is a problem just of Scrum Masters becoming Agile Coaches, that try to bring in the solutions from the one or two environments they know.
Looking for the one and only simple solution is far more spread. Customers expect it - because they are unaware of the consequences and Agile coaches do it - because it is so damn hard to help a customer in a focused way without giving him THE SOLUTION.
My understanding of Agile Coaching
I think agile coaching is a balance between the described points.
It's guiding without prescribing. We don't start from a blank page and we use our experience to accelerate their discovery process of their solution.
Effective agile coaching is the process of supporting the client to improve by becoming Agile.
My measure of success is that the client raised his skills to improve, not so much the things happened through our influence at our presence more that it never stops. I'm much more happy on the changes/improvements happening without our influence afterwards. For me this is a key motivator and driver, which I tried to summarise in the blog post I do my job for the email I get half a year later.
The true challenge is to help to client in an fast and effective way without taking unsustainable shortcuts by dropping THE ONE SOLUTION.
We experienced a focus on teaching, mentoring, advising and coaching in the right moments as best to help to client in an effective and sustainable way.
- coaching - the solution lies in them, support them to unlock it
- teaching - delivering the needed concepts/knowledge (to enable the client to work in one of the the other states)
- mentoring - role-modelling or pairing/partnering with the client to close the gap to get started
- advising - by requested for solutions, give options or advises to be finalised to keep the clients ownership high
Consulting in the meaning described above is from time to time expected or suiting best to the situation, but it doesn't bring us closer to our previous described goal of raising the clients capabilities of self-improvement.
What is suitable depends highly on the context and situation. In my experienced too many wanna be Agile Coaches have the tendency to focus too much on teaching and consulting towards the one solution. From my experience this is counterproductive, because the client doesn't increase his capabilities to improve on his own.
My preference is coaching or using the other forms of interaction to enable the client for it later on. While you coach the ownership is fully on the client. I think this choice isn't a matter of the personal style, it's a matter of sustainability.
This is my understanding of effective Agile Coaching. Would be interested in your opinions, if it fits. Looking forward to your comments.
illustration by the author