Solution Focused Coaching in Agile

di

Last week I was at the XPDays Benelux conference where I presented a session about Solution Focused work in agile.

The session was attended in the morning of the first day by about 40 people and, as there was a lot of interest around it, I re-made most of it in the evening for an additional 15 people. I was pleased to see so much interest around coaching techniques in general and how agile coaching is already something mature in Benelux.

The slides of my presentation are available on the XPDays website and also on slideshare:

Stai visualizzando un contenuto segnaposto da Predefinito. Per accedere al contenuto effettivo, clicca sul pulsante sottostante. Si prega di notare che in questo modo si condividono i dati con provider di terze parti.

Sblocca il contenuto

Ulteriori informazioni

Now some more words about Solution Focused coaching: this is actually a concept coming from psychotherapy, in particular from the work of Steve de Shazer, Insoo Kim Berg and others at the Milwaukee’s Solution Focused Brief Therapy Center. During the eighties they recognised, during their daily practice, that analysing problems, i.e. the freudian approach, does not help in finding the solution of those problems. To know that the origin of a mental disorder comes form, say, a child abuse, does not give any hint on how to “fix” the problem.

De Shazer and his colleagues found afterwards a philosophical basis of what they were doing in the work of Ludwig Wittgenstein, in particular with the perfectly synthesized sentence stating that “All of the Facts belong only to the Problem, not to its Solution”.

Analysing the facts of the past can be a powerful mechanism to understand what happened, how it happened and what lead to the event. But finding a solution requires turning towards the future and being able to identify, among all possible future states, one that solves the problem, and also one that is reachable.

Some examples, related to the daily life on an agile project:

1. There is a conflict between the Product Owner and the Team. Knowing the fact, that this problem comes from a time several years ago when the PO and a team member had an interpersonal issue on another project, might help in reflecting on the past and expose the conflict, but all this facts don’t help in reaching a solution. It is much better to discuss instead how the relationship between PO and Team should be in the future: what can they do to, how should they behave to create an effective co-operative environment.

2. The Team did not deliver software with the proper quality in the previous iterations. Sure, understanding the reasons why this happened might give some hints about a possible solution, but another – and in my opinion more powerful – option is to simply envision the team delivering and understanding what do they need to do differently in order to achieve the wished quality.

The keyword here is different: what do we need to do differently in order to achieve our goals? In order to find these differences between what we do and what we should do we need to envision our future state and, with that state clear in mind, work out the steps to reach it.

The central lesson of the Solution Focused work is, in fact, to take our clients out of the problem state, where they remain stuck in the petty analysis of what was, and bring them to a future state where the problem is solved and let them identify the differences in comparison to the problem state. Another added value of doing this is that thinking about “solution” we are in a very resourceful state, as the problem is not there anymore, and we are free of its emotional weight. Blame, for example, has no place in a solution state, as the problem is simply gone: think about how much easier some meetings could be without the search – implicit or explicit – for somebody to blame!

During my presentation I also introduced the participants to the concept that the question “why” – because of its implicit past-oriented connotation – should be used sparingly. This provoked some interesting questions and discussions. Unsurprisingly, actually, considering that one method used heavily by the agile community is called “5 Whys”. I will address the topic in a subsequent post to give it the space it deserves.

Summarising: Solution Focused work is actually a language, a way to talk in the future rather than in the past. Is also the attitude of looking into the future in search for a solution instead of digging in the past and identify blame: a very important attitude indeed for an agile team!

Selected Bibliography: