What I Do When Coaching

In the past few months I've seen more and more articles, discussion group entries and blog posts that talk about Agile Coaches using words such as charlatans, snake oil salesmen and '#@$!!!#$%$#' (I'm not exactly sure what that translates to, but I believe I can safely assume it isn't complimentary).

Of course, I have no control over what other people do to hang up their shingle as an Agile Coach, but I can talk about what I do as a Coach.

First and foremost, my job is to listen and listen a lot! From my initial meetings with a potential client to daily standups with teams with whom I've been working for weeks or months, I have to listen not only to what's being said, but how it's being said, and often what isn't being said.  Every coaching engagement starts with a discussion about what problem or problems the client is trying to solve.  Only then will I have the most vague idea of how to help, and even then I almost always don't have the full picture.  That leads directly to the second aspect of my job.

I ask questions... a lot of questions.  If you're annoyed by a toddler constantly asking, "Why", then there's a good chance I'm going to annoy you as well.  However, to be able to help I really need to ask all those questions.  Sometimes the answers alone are sufficient, but again I listen to how a question is answered, observe the body language, and look for avoidance or deflection in the answers.  Questions that are given direct, clear answers are usually things that either aren't problems, or at least the people are conscious of the problem and can find ways to solve them.  The hairy issues are the ones that are behind questions that people don't want to answer, or deflect the question using responses like, "It has always been like that here!", or, "That group never cooperates with us!", or one of my favourites, "It's above my pay grade to worry about that!".

The third aspect of how I coach is to challenge assumptions.  Again, this can annoy people, but I usually point out that someone has hired me because they believe there's a problem that I can help solve.  Why does your build take 15 minutes after a trivial one-line change?  Has anyone tried building on a local machine?  Has anyone tried optimizing the build scripts or partitioning the build such that you only have to rebuild a small fraction of the system after that one-line change?  Has anyone actually tried having teams work in a common work area?  Has anyone actually tried pair programming?  Did someone from management actually say to the teams that they shouldn't refactor code so that it's maintainable over the long term?  Has management actually said to the teams that they expect them to refactor the code in order to make it maintainable over the long term?  I could go on and on...

The fourth aspect is mentoring in any number of Agile practices.  I come from an XP background, so I'm often called upon to work with teams on technical practices.  I also do everything from provide ab initio training to teams and working with them directly for a few iterations, to simply acting as a sounding board for people who have been working in an Agile environment for a while and they want a different perspective on what they're doing.  In these respects, I'm an expert by virtue of my 10+ years experience, and I'm constantly learning myself!

Finally, the most important part of what I do as a coach is to work myself out of a job.  A single team should be able to fly on its own after a few iterations of coaching.  The most important things I help them with is learning how to reflect on their work and make their own improvements.  I can show them the mechanics of a process very quickly, but effective retrospectives are key to long-term and sustained improvement.  Lean principles are also a key aspect to this.  Essentially, I try to impart a mentality of "Things are good, but we can always find a way of doing better!"

On larger engagements with many teams, another way I work myself out of a job is to help develop an internal training and coaching capability for the client.  That allows the client to sustain the changes they have decided to make, and especially to tailor the training and coaching to their specific domain.  While I do learn a reasonable amount about a client's business domain during my engagement, there's no substitute for people who have been working in that domain for many years.  That perspective allows the internal coaches to provide better situational coaching that I might be able to do, because they already know the work, the people, the politics, possibly the code base, etc.  That said, looking back at my second and third points, my external voice can shake loose some assumptions about the current environment that an internal coach may see as issues or positions that can't be changed!

So, to summarize, here's what I do as an Agile Coach:

• Listen
• Ask boatloads of questions
• Challenge assumptions
• Teach/Coach Agile practices
• Work myself out of a job

The length of an engagement can anywhere from a few hours to many months depending on the situation.  I had one client where I spent about 6 hours going through the steps above, because their actual need was relatively small.  Other clients have taken longer due to the number of issues, the number of teams and a combination of both.  There's no set formula for determining how much coaching a client needs, although it generally becomes apparent once the engagement starts.

So, yes I call myself an Agile Coach, and yes I specialize in helping teams to use Agile values, principles and practices.  However, the actual work that I do may not be to teach a client Scrum.  It may not be to show them XP technical practices.  It may not be to talk about Lean.  It does, however, always follow the steps above.

Now that you know what I do as a coach, if you think I can help then give me a call! :)