Drawing on Carl Rogers for Agile
You could say humorously that coaching a team on Agile principles and practices is very much like being a therapist. Beneath this flippant comment, though, lies a little wisdom.
In particular, I am reading a book by Carl Rogers titled On Becoming A Person, in which he describes some “Significant Learnings” from his long and distinguished career in psychology and as a therapist. Much of what Rogers describes as true to his role as a therapist can be transferred to the role of coach.
“In my relationships with persons I have found that it does not help, in the long run, to act as though I were something I am not.”
This simple but powerful statement works on many levels. It means that it doesn’t help to pretend you have answers when you don’t. It means that you don’t pretend to be calm when you are angry or assured when you are frightened. This doesn’t mean acting like a child and showing off your emotions by knocking over chairs and storming out of meetings (although this is sometimes necessary) – it means being honest with yourself about your own emotions and the limits of your knowledge and experience. It is okay to not have the answers – just admit it – don’t make up an answer on the spot that might be interpreted as the correct way of doing things when it is just a wild guess.
This is just one example of Rogers’ learnings, but many more apply. I may talk more about these later on in another article. Another aspect I wanted to cover immediately was the method of solving a problem.
A coach and a therapist have some similarity in their role. When a problem arises, the temptation may be to jump in and solve it. If an Agile team is consistently failing at a particular practice an easy mistake to make is to simply tell them what they are doing wrong and how to correct the mistake. The problem with this is that it doesn’t lead the team to a deeper understanding, it just solves the problem for a time (if they don’t see how they got into the problem state, they may fall back into their bad practices again later on). Rogers describes how his role as a therapist was to try and lead his client to an insight. Even if he suspected that he knew the answer, he believed that he needed to help the client make the discovery for themselves. This isn’t a contrivance. Just as with a therapist’s clients, the Agile team knows what hurts and what needs to change – and the coach just needs to lead them through the process of discovery and improvement.
This is profound.
You don’t just walk into a room with a “non-Agile” team and drop a process on them that makes them Agile. You don’t teach them the way to do Agile. What you do is help them to discover their context and help them to understand the principles and practices so they can use that knowledge to solve their own problems.
An incredibly important side-effect of this is that you can’t effectively coach a team via a book, or an article, or on a user group – because any answers you give are context-agnostic and may not be right for the context of the team. This is my main complaint with methodology zealots – they think they have the answer before they have enquired about or considered the context. This isn’t to say that we should all stop sharing our experiences in these ways; we just have to assume that people will apply their specific context to anything they learn. People answering questions on a user group with their “one true way” would do well to heed Rogers’ advice.
There are many comparisons to be drawn here, so I encourage anyone who finds themselves in a coaching role – or who aspired to be in a coaching role – to read Rogers’ book, On Becoming A Person.