This year at AYE Jerry Weinberg hosted a session titled “Coaching the Coaches“.   Jerry split the group up into people who self-identified as Coaches (coaches or managers who do coaching stuff), people who have been coached and people who didn’t feel they fit into either category.

Jerry asked the coaches how they received the title ‘Coach‘ and when it came to my turn I said it’s for marketing.  All the cool kids are doing it, that’s what the industry is asking for and it sounds a whole helluva lot cooler than ‘Business Process Consultant‘.

About a year ago while talking to a couple senior people at the organization I was working with, I realized there was a whole lot more to ‘Coaching‘ than I thought.  I was getting pressure to commit to having a project done with fixed scope for a fixed date and instead of trying understanding their perspective, I immediately went into ‘Agile Coach‘ mode and tried to explain to them why they were wrong.  Needless to say it failed miserably.   Over the last year I’ve had several epiphany’s about what a coach is and it all became crystal clear during a recent coaching session hosted by Michael Spayd.

Michael and Lyssa Adkins have been delivery “What is an Agile Coach?” webinars recently and Michael shared the model with our coaching circle:

The model is based on 4 pillars:

  1. Coaching/Facilitation: It’s always about the client, not you.  IE: don’t let Agile get in the way of success
  2. Education/Mentoring: Understand what level the client/teams are at to choose the best approach.  IE: more green teams need ‘how’ and a more directive approach.
  3. Agile/Lean Process Knowledge: When to use which one and the rationale behind it.  IE: Figure out what process suites the work being done.
  4. Domain Mastery: being able to coach AND do.  IE: An XP Coach who can coach AND write code.

What I love about this model is that it can help organizations understand what is expected of a coach and it can help coaches improve their skills by having some concrete details about what skills and knowledge are needed to help organizations become successful.  More importantly, it can help identify areas where the transformation may be falling down.  For example, if you’re focused on installing Scrum and ignore (or aren’t aware) of human transformation or organizational transformation you may optimize the team temporarily.  Once the Coach is gone, the transformation may not stick.

A team I worked with at a large enterprise company really understood what ‘being Agile’ really meant.  They didn’t have the process knowledge initially but they had desire and commitment to learn.  Simply put, these guys were awesome.  As their ‘Coach‘ my approach was very much non-directive as that’s what I believed would serve them best and they did not disappoint.  They outgrew me after a few months because I helped them be aware of their situation (often referred to as ‘holding up the mirror‘ to the team) and gave them the tools and knowledge to manage those situations.

At another client I worked for, they needed much more ‘how to‘ coaching so I took a much more directive approach where I would tell them how to apply the process until they learned it well enough to mold it to fit their work and style.    In this same organization, I was pairing with Alistair McKinnell.  He has super-mad skillz in XP.  He was very well-rounded in all pillars and was particularly strong in the Domain Mastery and Education/Mentoring pillars because he could get dirty with the teams and help them with code all the while helping them understand better technical practices.  I couldn’t do that.  I felt stronger in the Coaching/Facilitation and Process pillars as well as having deeper knowledge of Product Owner practices.  This combination of skills worked very well together.   Where we lacking, in my opinion, was deeper organizational change knowledge.  We knew that at the time and the focus was at a deeper level, however having this model would have been helpful as a communication tool to the client in the sense that we could point out where the train wreck was going to be.  We ‘knew’ and struggled with verbalizing it or creating a visual model to help them be aware of it.

This Coaching Piller is what’s missing from the Agile Community and I think it’s a more effective model for addressing the certification problem than all of the new programs surfacing today.  Certification helps with 1 of the 4 pillars, there’s still much more skills required to be an effective coach.  This model will create a new level of awareness for coaches and organizations and I think it relates well to the 4-step model I use when engaging with clients.  I would also argue this model can be applied to managers and leaders.  If they can understand what a coach can do for them, they can learn these skills and help their organization self-sustain their Agile transformation.

I’ve been participating in a couple of coaching circles hosted by Michael Spayd for about a year now.  In that time, I’ve learned various aspects of this model through what he has shared and what other members have brought to the table.  This has been much more valuable to me as a self-identified Coach than any process training I’ve done.  It’s helped me understand areas where I need to improve and also helped me understand how to find the best approach for the given situation I’m in.  I plan to use this model right away as a tool for me to visualize what an organization needs to be successful and where I can and cannot help them.

Are you a coach or coachee?  What do you think about the model?