This is the first in a series of posts about finding and keeping your balance as an agile coach or change agent. I introduced the topic as a main theme on this blog a few weeks ago in Spotting the Balance. At the AgileCoachCamp, I committed to writing a post on this every two weeks, and due to holidays in the meantime I’m starting now. My thanks to Gitte Klitgaard Hansen who has been constantly reminding me of that commitment…
I’ll start by roughly defining the “opponents”.
What is Teaching?
This is easy. Enabling people to learn. That usually involves some elements of
- giving them some sort of information (model, tool, technique…)
- creating a safe environment for experiments
- guiding them when they make mistakes
- evaluating their progress
What is Coaching?
Coaching is assisting and guiding people to identify the goals they want or need to achieve, to spot obstacles that make it difficult to achieve them, to make out a path to overcome those obstacles and to verify that they stay on that path, so that they actually reach their goal. That implies a set of Don’ts:
- Don’t tell them where to go
- Don’t show them the obstacles
- Don’t do their work
As agile coaches, we’re usually in a situation where we know more about Agile then our clients—that means we have experiences and a toolbox of practices that might help the clients to identify or reach their goal. The goal usually comes down to some variation of “building the right system right”—meaning they want to better identify what system to built, and to achieve better ways to build it.
Which leads to the challenge that while you let the clients define their goal and find their own path to reach it, they’ll constantly ask for your advice, your ideas… But you want to stay out of the way.
Notice there’s a main similarity and a main difference to a teacher:
- Similar: the topic is set. If you attend a maths class, you don’t expect to gain knowledge about biology. When you hire an Agile Coach, you don’t expect hir to improve your resource management (nor your biology knowledge).
- Different: as a teacher you generally have a predefined curriculum. As an Agile Coach, you have to help your clients identify their learning needs first. At least that’s how I understand our job.
I think to manage this risk it pays to create a clear frame in which to evaluate your options. Your objective is to enable the client (be it the organisation, a manager, a team) to find their own solution. Solution to what? That’s your first thing to find out… So we’ll take this as an example to establish the concept of your Coaching Mode and your Teaching Mode.
Zoom in on the right problem
Let’s assume your client asks you to teach pair programming. Grabbing the right tool from your agile suitcase, you ask, Why? And depending on the answer, you might ask that question again. They tell you they need knowledge transfer in the teams, as there is a legacy system which only two out of many developers dare to touch, because it’s built on an architecture that is very different to the one everybody uses now, and barely recognisable anymore anyway… During this entire conversation you stay in Coaching Mode—you ask open questions, listen actively, thereby pulling the tacit knowledge of individuals out into the shared knowledge of the group.
At times, the conversation might get stuck, you get the impression that you’re rather talking around the real problem than about it. This is probably your experience, pattern-matching what you see and here with situation you’ve been in before. Sometimes, just asking another question might not be enough. Rephrasing what you’ve heard in your own words, trying to break their mental model with an example, can be a good strategy here. When you start giving examples, you enter your Teaching Mode.
“I think I’ve been in a similar situation, when I had to change something in a part of a system where the person who developed it wasn’t around anymore, and nobody really knew how it worked… What I felt I needed at the time was…” This lets the group leave their introspection for a while and gives them new information which they can use to reframe their own situation.
You then enter your Coaching Mode again and ask, “How is your situation different from my example?” This pattern you then repeat.
I think we can generalise for all the balance topics that you need to identify two Modes of Operation for yourself. In this case of Teaching vs. Coaching, the Teaching Mode and Coaching Mode. This is where your own learning takes place:
- You need to define for yourself how you behave in each mode.
- You need to sense which mode is required in any situation.
- You need to decide how (and if) you want to make the group know that you’re switching modes. Remember that what they perceive and what you intend them to perceive might not be the same.
- You need to hone your switching skills, so that over time it becomes natural to you to adjust your behaviour appropriately to the situation.
I realised two things while writing this post:
- The usage of the teaching and coaching modes and the honing of your ability to switch between them is not specific to agile coaching, it’s certainly applicable to many teaching situations.
- The resulting technique reminded me of BDD and deliberate discovery…
To pay respect to Chris Matts‘ Feature Injection technique we could call this Knowledge Injection. Instead of pushing knowledge into the students, you pull the most important knowledge needs from the class, and inject knowledge using examples. This expands the mental model your students have of the problem domain and this model can then again be broken/expanded with more examples (or questions by the students that indicate more knowledge need). This leads to an Experiential Learning Cycle. I like that.