I’ve noticed that the word ‘coaching’ is often used to describe anything from teaching to professional coaching, and everything in between. So how much of what we do as agile coaches or ScrumMasters is really coaching – and how much of it should be?
The Agile Coaching Institute’s coaching competency framework[1] defines eight competencies: agile-lean knowledge and application, technical mastery, business mastery, transformation mastery, teaching, facilitating, mentoring and coaching.
Broadly speaking, those eight competencies fall into two categories; the first four are knowledge of how to do something, while the second four are skills in helping others learn how to do something, or do it more effectively.
Coaching is a process through which one person (the coach) helps another (the coachee) improve her performance in some aspect of her life, or work towards a goal she has identified. Coaching happens through a conversation or series of conversations during which the coach helps the coachee do things like: increase awareness of her current reality; explore options to make progress towards a goal; create a plan; build motivation or tackle limiting beliefs.
One of the key differences between coaching, mentoring and teaching is that in mentoring and teaching one person is transferring knowledge to the other person. In coaching, however, the coach helps the coachee make more effective use of knowledge and attributes the coachee already has.
But wouldn’t it be easier to just tell the coachee what to do?
As agile coaches or ScrumMasters some of the key things we want to achieve are helping teams learn to self-organise and helping people shift their mindsets from a reliance on command and control and up-front planning to accepting uncertainty, devolving responsibility and valuing experimentation and learning.
When you tell someone what to do, or show them how to do something, you are working with the logical, rational aspect of their mind. If all you want to do is show them a new way to do something, that’s fine.
But, if you want to challenge someone’s fundamental assumptions about how work should be planned and controlled, or you want to help them build the collaboration skills, self-confidence and responsibility that is necessary for a successful self-organising team, you will be most effective if you work with their emotions rather than just logic and rationality.
This is because people’s behaviour is largely governed by their emotions, so focussing only on teaching is unlikely to lead to the sort of transformational change that agile coaching frequently requires, given that fixed mindsets and the existing organisational culture are often the most difficult obstacles to overcome during an agile adoption.
Because coaching focuses on the coachee’s own beliefs, feelings and goals, and is based on rapport and trust between the coach and coachee, it can have far more emotional impact than teaching or mentoring. This is why coaching can be so powerful.
When should we coach?
I believe when working with teams or individuals who are new to agile (at the Shu stage of the Shuhari learning model) an agile coach should start by teaching or mentoring on agile techniques and underlying principles, while coaching to develop behaviours such as effective collaboration and communication, and the ability to work with uncertainty.
With coachees who are experienced with agile (at the Ha or Ri stage) I think coaching should be the agile coach’s default approach, with temporary forays into teaching or mentoring when necessary to teach a specific technique.
ScrumMaster and agile coach are servant leader roles which focus not on telling people what to do, but on empowering them and helping them find their own paths to agility and increased performance. This is why these roles can be such a powerful force for organisational change and this is why I am convinced that coaching is a fundamental skill for these roles.