Monday, July 25, 2016

So, I'm not an agile coach, after all ...

I recently applied for a Certified Enterprise Coach - and got rejected. It took me a while to get over the rejection, and I had some good discussion with one of the application reviewers. What I learned: My understanding of "Coach" is not the same as others. Then I found this post on LinkedIn about what a coach is, and decided: I'm not a coach. I consider that what others promote as "coaching" to be snake oil selling and therefore, unethical. As such, I will gladly refer to myself as "enterprise consultant helping others be more successful by becoming more agile" (short: agile consultant) instead.


So, what are my reasons for stating "I'm not a coach", then?

For now, I'll just sum this as a response to the "Top 5 Criteria of an Agile Coach" delined in the quoted article.

1. An Agile Coach must not own the delivery or the outcome expected from the team.

Would you hire a football coach who openly states that "I'm not responsible for how the team performs!"? Where would you get the idea from that a coach has no outcome responsibility?
There is a difference between short term, mid-term and long-term performance and one must definitely understand the concept of special cause variation. But when I see that my coaching engagement makes no significant difference in the team's performance, then I am not doing my job! Convincing my client that this is how it's supposed to be and that I deserve my paycheck even when my coaching makes no difference at all - is purest snake oil!
My take: An agile consultant keeps an eye on short-term, mid-term and long term capability of the organization and understands the systemic impact of specific choices. They understand that there is often an anticorrelation between short-term and long-term performance and understands when tradeoffs between the two make sense. They are aware that taking a short-term hit in performance might yield long-term learning and growth. Likewise, they understand which short-term performance boosts will lead to long-term disaster. They help agilists make informed decisions to understand the consequences of their actions.

2. An Agile Coach must not try to be a great coach or expect to be loved by the team.

Well ... this is dubious. Your job isn't to be everyone's best buddies, but if you don't want to invest into building a trust relationship, you shouldn't even start. Likewise, it's not about who you are as a coach, but about what you want to achieve with your client. If you put focus on your person instead of on the change you're guiding, you're the wrong person in the wrong place!
My take: An agile consultant is a trusted partner of everyone in the organization, and their greatness is the impact they make, not who they are or what they do. If your footprint isn't felt even years after you left, you're not worth the money. And if people don't reminiscence about your work admirably or positively, you're probably in the wrong business.

3. An Agile Coach must not solve the team’s problems.

I just can't get this image out of my head:
A child fell off the bridge and is drowning. A coach passes by, sees the frantically screaming child and helpfully states "Well, now would be a good time to learn swimming." - and walks off.
There is a time for everything! People who don't understand that and deny help in time of need are not just not coaches, they are inhuman bastards! Now, it's important to understand when is the right time for help in order to not fall into the trap of helper syndrome.
My take: An agile consultant is aware when is the right time for what. They understand that, just like you can't let a 4-year-old child figure out how to drive an SUV in the city center, there are situations which are beyond the teams' current level of expertise. They will take control to prevent irrecoverable damage, they will guide to steer away from disaster, but just like a parent, they will let teams take a few hits here and there in order to be more self-reliant later. In the same way, they might even create challenging situations for people to grow. And they understand when is the time for which approach.

4. An Agile Coach must not stay too long with the same team.

This was stated as maximum 3-6 months. In that time, you can hardly achieve meaningful, sustainable change. I am not even concerned whether that is sufficient to get the team to trust you, think a bit, run a few experiments and make a few changes. However, in challenging environments, this is hardly enough to drive out old habits. Hidden opposition to new ways of working can easily keep low profile for that timespan, especially when they know they just need to outwait you. What I see too often is that once coaches leave, within a few iterations, people are back to the former status quo.
My take: An agile consultant should focus on making an impact that lasts even long after they leave. They are not keen on leaving before the cookie crumbles. They want to contribute something meaningful, and they take as much time as it takes. Understanding Kotter's model of organizational change, they see the entire process of change through before they leave. They help in institutionalizing change, rather than taking off before sustainability is reached.

5. An Agile Coach must not make prior assumptions about the team.

We all make assumptions - all the time - and we can't even think without making assumptions! To assume that we can make no assumptions is ignorant! An agile coach who does not understand the nature of assumptions will not be able to make suitable assumptions and may not catch invalid assumptions in time. This plays right in line with point (4) above - be aware of the dangers that your own model of reality imposes on your work!
My take: An agile consultant must purposefully make critical assumptions and invest time into verifying them without bias using the Scientific method - preferably by finding evidence to discard them in favour of a better model of reality. It's actually good to have a certain set of assumptions and a clear plan how to reject them!
For example, "The people here are lazy" is a useful assumption in the sense that you now have to find a way to disprove it. Evidence-based rejection of this idea will become both the basis of your trust relationship (see 2) abnd the first small victory on your road to excellence. The art of the agile consultant is to find a effective experiments to disprove false assumptions quickly, completely and without a spark of doubt.

Conclusion

I've witnessed too much snake oil selling in the agile community and am pretty much fed up with it. When people try to define the term "coach" as someone who seeks absolution for their inability to make a difference even before engaging a client relationship, I can only advise: Don't hold your breath. Find someone who has the guts to take a stand for what they believe in!
I gladly reject the idea of being an "agile coach" when the idea of coaching is to not help people who need help, not make an impact and spending as much time as possible staying vague and undecided before taking a quick exit and not taking responsibility for their own work.
I do not want to be such a person. If there's nothing I can do for you, I will tell you. When I won't make a difference, I'm wasting your time. I'll jump into the river to save you from drowning, but only until you're out of danger. When you can swim by yourself, I've achieved my personal goal. But I'll be looking for evidence to see that you don't need me.

I am a consultant, supporting your agile journey. My job is done when you're more successful.
Sorry. I don't have snake oil for sale.

4 comments:

  1. Hi Michael,

    I have been browsing through your blog and decided to comment on this article (btw. this blog is exceptionally well written, very informed posts! :) ). I'm right how in CTC (certified team coach) process so I can relate to your experiences with CEC. I also thoughts that pure coaching isn't applicable to many situations and then I found ICA coaching competence framework, have a look maybe it will help you: http://www.agilecoachinginstitute.com/wp-content/uploads/2011/08/Agile-Coaching-Competencies-whitepaper-part-one.pdf.

    ReplyDelete
    Replies
    1. Thanks for your comment and the pointer to ICA, Maciek.

      I guess my real gripe and issue does not even have to do with the ScrumAlliance CEC program, but with the huge amount of quacks I have to put up with in my professional life.

      It is very difficult for me to sort out the bias caused by experience against the intentions of the CEC program - especially, because they give you very few pointers.

      Part of this blog is actually sorting out these things for myself - and letting others partake.

      Delete
  2. My experience is that a lot of people can't really explain what agile coaching is and how it's done. For Example from my comments exchanges with my ctc reviewer I got the feeling that for him agile coaching=personal coaching done in frame of work. If you don't do coaching you can't be agile coach. As you pointed out in your post, it's not really the case.

    At the same time there are professional team coaches that work this way and have good results (I recommend team coaching course for every agile coach, it makes way more sense in our type of work).

    That is why I really like work of ICA, they sum it up and create simple framework for everyone to use.

    ReplyDelete
  3. My experience about "agile coaching" is similar to yours.
    Oddly enough, the term is already a misnomer as it implies the goal of the coaching before engaging in a dialog on the direction of the change.

    As a consequence, I frequently have to put up with completely incompetent people who know neither "agile" nor "coaching" and have simply discovered the title "agile coach" as a way of participating in a market where demand > supply.

    Part of the CTC/CEC intention is to draw a dividing line between quacks and professionals. Unfortunately, it is not very clear for the applicant where this dividing line is and the SA coaching community isn't very transparent about it, either.

    We learn through trial and error.

    ReplyDelete