As you have probably noticed – in case you did not fall asleep while reading these pages – I am a strong believer in the solution focused approach and I wrote already several articles about it (see this and this and this). The approach generated interest in many of my peers, so over time I answered several questions on this topic, mostly coming through Twitter: here are some of them.
Q: I want my teams to be self-sustaining: how to do solution focused without a coach?
A: Solution Focused is a technique in principle easy to learn. With some basic training and a supervision form a coach, any team member can then integrate it in his/her daily life. I suggest practicing while having an observer to give feedback on how the technique is used: this will speed up the learning enormously, provided – as usual – that there is a genuine will of learning from mistakes.
Q: When not to use Solution Focused?
A: As Solution Focused is an attitude when asking questions, there is IMO no place where I would not use it. If a problem is purely technical, i.e. a bug in the code, a problem in the server, …, then I would use a root cause analysis method. But as soon as the problem domain is in a human complex adaptive system, I would definitely use Solution Focused.
Q: Is Solution Focused a ‘talk about a good day X’?
A: Superficially it might look like that. At a deeper analysis Solution Focused is about bringing in the resources from the past to design a solution without remaining entangled in an analysis of the past. Think about being lost in a big city you don’t know. It doesn’t really matter how you lost your way and why did it happen (and whose fault it was!). What is important is to understand the current state, define where you want to reach and, using the positive resources you have – a car? a motorbike? walking? do you have enough energy to walk? do you have money for public transportation? how did you already successfully solve a similar situation? … – define the path needed to reach your destination. Envisioning yourself having happily reached your destination is a part of it, but the value is in determining the path to your destination.
Q: Where can it be used in Agile?
A: Restating: being an attitude when asking questions, it can really be used everywhere. I found it especially useful in some situations:
- In the retrospectives. Instead of a root cause analysis – especially dangerous if it might need an admission of guilt by somebody – I would ask the team to imagine that, thanks to a miracle, the problem is solved. Once they have clear what they will have without the problem, then we can design the steps needed
- In planning for an iteration/release/…: by asking to envision the result, I help the team to focus the discussion on planning a set of features that make sense when delivered together, not just a set of stories. The path to reach the solution is, in this case, the tactic used to tackle the stories in order to achieve the iteration goal
- Problems among team members. Imagine your problem with person X is solved: what would be different? What are you doing differently? What is X doing differently? How would other people notice that the problem is solved? … In fact, in scenarios like this Solution Focused has also a motivational aspect: while the solution is just envisioned, the feelings that appear in the process are very much real: it is possible to make the problem go away, it is possible to act differently – cool, now what do I need to reach there?
Q: What do I need to pay attention to when using Solution Focused?
A: Just a few things:
- Keep the discussion focused on the solution, not on the problem. This is probably the most difficult thing to do for beginners: it is too easy to engage in the situation of the client and start analysing the problem instead of talking about solutions…
- …if you catch yourself asking “why” this is a symptom of you doing problem analysis rather than talking about solutions. The question why has a great value in the context of exploring values – I might write a blog entry about it sometimes – but when talking about solutions it is, in general, a no-go question. Actually, let me contradict myself: once a solution is envisioned, I *might* ask why in order to verify how this solution fits the value system of the client, though I would be careful to formulate the question in a way that it does not ask the client for a justification of his solution, as this usually breaks the rapport with the client
- Once the solution is defined, work the steps back to the problem. Solution Focused is about planning a path towards a goal. Having a goal is great, but without steps to reach it doesn’t help either. The output of a Solution Focused session is a concrete list of action items
- Don’t give solutions. If I had to pay one Euro every time I was at least tempted to bring in my solutions, I would be bankrupt since long. Every solution I bring in makes me a consultant, but not a coach. I might become nervous, maybe bitching about the client not seeing something sooooo obvious, but I force myself to ask and wait. It’s a tough discipline to learn, but it pays off. Once I got a client who came up with a solution that was obviously wrong from my point of view, but I resisted bringing my solutions in. In the end we discussed the options, challenged them all without bias, and then the customer canned her own solution and opted for something more realistic. As it was the client’s process of rejecting the idea I found no resistance. Most of the times when I – mistakenly – brought my solutions in I ended up having resistance from the client, or the client did not implement the steps we planned, i.e. it was mostly a waste of time.
- Be careful about your rapport with the client. You are responsible for a good trust relationship with your client, so pay attention to both verbal and non verbal signs you are sending. Also here an observer is of great help
Thanks @YvesHanoulle for contributing to the questions.