BT

Retrospectives Applied as “PROspectives"

| Posted by on Dec 28, 2013. Estimated reading time: less than one minute |

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Solution-focused goal-driven retrospectives by Jason Yip

Strengths Based Retrospective by Ben Linders

Thanks Hans-Peter for this article which shows how we can use the strenghts of people and teams to improve continuously.

In my blog post www.benlinders.com/2013/using-solution-focused-... I also decribed a way to do a strength based retrospective, using solution focused. Instead of doing new things, things that you might not be capable to do, you would be doing more of a thing that you are already doing, and which you are good at. The goal is to use the strengths which the professionals already have to solve problems.

Re: Solution-focused goal-driven retrospectives by Hans-Peter Korn

Yes, I know it! So: What is different (not "better", but different ...)

As a very first step I propose to establish a "Platform for confidence and trust". To go directly into the process is possible only with this precondition.

I don't start the process with "Identify the Ideal State / True North / Future Perfect using the Miracle Question."
Very often this leads to too idealistic visions far away from what can be / should be achieved as a next step. Here I follow Tomasz Switek who is focusing a "future" situation, not a "miracle" (see www.centrumpsr.eu/foreign/english/SFWINDOWS_1.pdf and www.centrumpsr.eu/foreign/english/SFWINDOWS_3.pdf)
And: The "miracle question" should be used carefully - not as a "standard element". It is appropriate if the client (the team) is caught in a "problem trance". If the client / the team is working on his future situation quite well this "miracle question" is not necessary. I learned this from Insoo Kim Berg: She did coaching without "miracles and scales" very often, when the client does not need it. ("Do not more than necessary - keep it simple")

I use a "panaorama" to base the PROspective on specific occurrences, situations or activities, not general statements.

And I propose to collect the actions derived from:
o Appreciate what is working well and sustain and increase it with the UUS tool
o Find specific actions items for improvements with the PLUS tool
If necessary, apply the impediment solvent
o Second-order PROspective
in a "Teamwork Backlog".

Re: Strengths Based Retrospective by Hans-Peter Korn

Yes, I fully agree!

This is the reason why I propose the step "Appreciate what is working well and sustain and increase it with the UUS tool" and within several steps questions like: "How did you do that? What else?" or "What makes this chance a 3 and not a 2 or even a 1? What else?"

Asking for Causes of Problems is not appropriate for social systems (Re: Strengths Based Retrospective) by Hans-Peter Korn

In addition to the posting above: Yes, we share a positive approach to improvement, focusing on people and their strengths.

So: How can this approach (described in www.benlinders.com/2011/business-reason-for-roo...) be useful for this?

> Analyze a problem to determine causes that made it happen, to define actions to prevent similar problems from happening again.

To analyse the root causes of a problem does not uncover strengths and resources - it uncovers weaknesses and deficits. And asking for e "chain of causes" with "5 x why" will uncover much more weaknesses and deficits ... ending in a big heap of them ... which seems to be too much to resolve ... a so called "problem trance".

Therefore in SF we don't deal with causes of a problem. But we may ask "coping questions" to uncover resources like: "How did you manage to "live" with this situation until today?"
(I use the word "situation" instead of "problem")
In www.sfwork.com/jsp/index.jsp?lnk=6d7 at "Problem Focus and Solutions Focus" and "SF - the direct route" you may find more about this.

And there is an other important point:

The idea:
> Analyze a problem to determine causes that made it happen, to define actions to prevent similar problems from happening again.
is based on the assumption, that there is a cause - effect relationship which (after having uncovered it with "why" - questions) also will work for future similar situations.

BUT: This assumption works for simple an complicated relationships only, nor for complex ones (like social systems). Have a look at the "Cynefin framework" in en.wikipedia.org/wiki/Cynefin :
> The Cynefin framework has five domains.[12] The first four domains are:
>
> 1: Simple, in which the relationship between cause and effect is obvious to all, the approach is to Sense - Categorise - Respond and we can apply best practice.
>
> 2: Complicated, in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge, the approach is to Sense - Analyze - Respond and we can apply good practice.
>
> 3: Complex, in which the relationship between cause and effect can only be perceived in retrospect, but not in advance, the approach is to Probe - Sense - Respond and we can sense emergent practice.
>
> 4:Chaotic, in which there is no relationship between cause and effect at systems level, the approach is to Act - Sense - Respond and we can discover novel practice.
>
> 5: The fifth domain is Disorder, which is the state of not knowing what type of causality exists, in which state people will revert to their own comfort zone in making a decision.
>
> In full use, the Cynefin framework has sub-domains, and the boundary between simple and chaotic is seen as a catastrophic one: complacency leads to failure.

So, Root-Cause-Analyses which should prevent us from similar problems from happening in future are appropriate for complicated relationships, for example technical issues like a bad performing server. They are NOT appropriate for complex relationships in social systems like communication and cooperation in the team or to reach a higher level of competence. Maybe you can uncover cause - effect - relationships in past situations, but they are not helpful for the future: "The relationship between cause and effect can only be perceived in retrospect, but not in advance."

Instead of cause - effect - questions in complex situations "Solution Focused Questions" aiming at a "better situation" are more appropriate. This is the underlying principle of
www.infoq.com/articles/retrospectives-as-prospe... . More examples you may find here:
knowledgex.camh.net/primary_care/toolkits/addic...

The combination of Root Cause Analysis and Solution Focused can be a very strong one by Ben Linders

Thanks for your extensive reply Hans-Peter, very useful.

Repeatedly asking why to explore root causes does not reveal strengths as you already pointed out. Understanding what causes the problem however helps to frame where to look for a solution and to use what is there already. That is where Solution Focused Questions come in. The combination of Root Cause Analysis and Solution Focused can be a very strong one.

Root Cause Analysis (RCA) helps to come to a shared understanding of significant problems in organizations. An example: when I was analyzing issues reported by customers with a team new to RCA we discovered that team members lacked specific technical training. It became clear during the RCA that the team had requested the training, which had been refused by their manager.

Since the manager was also attending the RCA, we discussed it further. We found out that the team had a profound understanding why they needed the training and how it would help them. They were capable to manage their own skills and abilities. That was their strength which helped them to work as a self-organized team! But the organization demanded that training was always approved by managers.

The team had asked for the training using the prescribed forms. In the motivation field they only stated that they needed the training to do their work. They assumed that it would be approved since for them there was a clear need for it. But the approving manager wasn't aware of their needs, so he disapproved it. The team decided to look for other ways to acquire the knowledge (it's a self organized team) which didn't work out sufficiently as now became clear with the root cause analysis.

The team and manager decided to take two actions:

- Do the training
- Next time when a team asks for training, explain why training is needed and which purpose it serves.

I've had another RCA where the team discovered that they lacked experience to do proper risk analysis and test planning. As a result defects slipped through, which were found at system test i.s.o. function test.

I asked the team what they possessed that could help them to solve this? It appeared that there was one team member with experience in risk based testing. He arranged an experienced test engineer from another team who paired with him in the next iterations.

So we used the strength which was already there in the team to solve the problem, but only after we were aware of the significance of the problem and the need to address it which we found out using 5 times why. Slipped through defects went down significantly in the next iterations.

These are just some cases where Root Cause Analysis showed problems wrt people, skill, and knowledge, and Solution Focused helped teams to take action to prevent similar problems in the future by using their strengths.

As Gerald Weinberg said in the Secrets of Consulting: "No matter how it looks at first, it's always a people problem." That's still true!

Re: The combination of Root Cause Analysis and Solution Focused can be a ve by Hans-Peter Korn

Hi Ben,

your example is pretty good to explain whether RCA are useful or not. You describe this case:

> Root Cause Analysis (RCA) helps to come to a shared understanding of significant problems in organizations. An example: when I was analyzing issues reported by customers with a team new to RCA we discovered that team members lacked specific technical training. It became clear during the RCA that the team had requested the training, which had been refused by their manager. <

There are two points to reflect upon:

1.:
> Root Cause Analysis (RCA) helps to come to a shared understanding of significant problems in organizations. <

This works only for situations which are seen as based on "cause - effect - relationships". That means, for "complicated", not for "complex" ones.
Of course: Many of us try to see and handle organisations (despite their character as social systems) as "complicated" systems based on "cause - effect - relationships" which can be "understood" and applied for future situations.
For me this a not very useful reduction leading to more complexity by hiding complexity.

2.:
> ... we discovered that team members lacked specific technical training. It became clear during the RCA that the team had requested the training, which had been refused by their manager.<

For me this is a good example for "constructed causes". And in complex systems you can construct a lot of such causes.
In this example a much more important "constructed cause" may be, that the HR departement hired team members with too low technical competence. So, to handle this "cause" means to fire this team members and to hire more competent ones.
Or to outsource the work to a competent supplier.
And this: > the team had requested the training, which had been refused by their manager < is rooted as a "constructed cause" on the (reasonable!) insight of the manager, that such a training is too expensive and the team members should cheaper ways (maybe self-study) or they should leave the team to become replaced by more competent persons.

So, you see: In complex social systems you cannot "discover" root causes - you only can "construct" them arbitrarily. And - that's the problem - there is nor way to proof, whether such a constructed root cause is true or not.

So: IMHO all those RCA in complex situations are misleading.


Coming back to your example. Let's start with this:

> There are issues reported by customers <

My way do handle this with the team might be:

PLATFORM: The point of departure for searching for what works and what should be improved or changed

What is your concern about theses issues reported by customers? What bothers you?
What is the broader task or job? What is its purpose?
How does your concern affect this purpose?

LOOK AT A POSSIBLE BETTER SITUATION:

Suppose you have worked out a way to change the recent situation (issues reported by customers):
What is your best hope as a result of this?
What is the least that you need to see happen?

UTILIZE PREVIOUS SUCCESS

Imagine a scale from 0 to 10 where the 10 stands for your best hope:
Where on that scale would you place the recent situation (issues reported by customers)?
How have you managed the recent situation so that you place it here (e.g. on a 3) and not one or two points lower on that scale? (e.g. as a 2 or 1)
How have you managed to live with the recent situation? (Ask “What else?” to find more than one aspect.)
When has it been a bit better, if at all? How did you contribute to this positive difference? (Ask “What else?” to find more than one aspect.)

STEPPING THE SCALE

What can you do now to rise, maybe by one point only, on the scale?
What needs to come as the very first step? How will you notice that this step was successful? --> Put this in the Teamwork Backlog.

AS A RESULT - without doing any RCA - the team might put this in the Teamwork Backlog:
Propose a first - not so expensive but quickly organized - training so, that the manager is willing to accept it.
Or: Sharing the already existing expertise of some team members by doing much more pair reviews or pair development.
Or: Finding out, that one or two team members should find a more appropriate job in an other team to make place for one or two experts.
Or: .... ... ...

Re: The combination of Root Cause Analysis and Solution Focused can be a very strong one by Hans-Peter Korn

Hi Ben - an additional reply:

Combining Root Cause Analysis and Solution Focused is not strong - it is an oxymoron.

Have a look at www.sfwork.com/jsp/index.jsp?lnk=6d7
Here you find this:

""""
When something's wrong, we have the idea that the way to change is to find what's wrong and fix it. The usual strategy goes something like this:
o Diagnose the problem
o Discover the cause and address weaknesses
o Make detailed action plans
This works very well in many situations - fixing your car for example. You take it to the garage and you want them to look at it, find what's wrong, fix it and give it back to you. This strategy works well for situations where things are fixed and well-known in advance, and where your efforts don't themselves change the situation dramatically.
Introduce people into the equation, however, and things aren't so easy.

However, the good news is that there is a better way - a way which not only works reliably but also saves a great deal of time and effort on everyone's part. It's relatively quick to learn, and also a positive experience to do. It's called Solutions Focus.
SF takes a quite different approach to working out what to do. To start with, it doesn't use ANY of the conventional problem-focused steps above.

So, what are we going to do instead? Rather than the problem-focused route described above, we can look at SF as taking three contrasting steps:
o Describe what's wanted instead
o Discover what's working already and find strengths
o Take small steps
At first glance this looks so obvious it's hardly worth talking about. And yet the process of discussing, deciding and acting on these things - and not doing the other things - can transform even the most difficult situation.
"""""

Re: Solution-focused goal-driven retrospectives by Jason Yip

If we break "trust" down to the two aspects of trust in intent and trust in capability, then identifying the ideal, asking "What do you really want?", is about addressing trust in intent. Are we all basically aiming in the same direction?

In the first case I've used this (actually a proto-form of this), I was using the ideal state as more of re-establishing a sense of challenge for a team that was already doing quite well and getting bored. In the second case, it was to encourage the team to see more broadly and leave the sense of helplessness.

Re: Solution-focused goal-driven retrospectives: Trust in intent and trust in capability by Hans-Peter Korn

Good point!

To avoid a too big gap between "trust in intent" and "trust in capability" I ask:
"Suppose you have worked out a way to change the recent situation:
What is your best hope as a result of this?
What is the least that you need to see happen?"

Instead of:
"Suppose - by a miracle - you have worked out a way to achieve an ideal situation:
How will the ideal situation looks like?
What is the least that you need to see happen?"

I know, that imaging the "ideal situation" (supported by the "miracle question") is often seen as "the" typical element for SF. But this is a misunderstanding of the intention of SF (see my reply www.infoq.com/articles/retrospectives-as-prospe...)

There are always multiple Root Causes: Understanding causes and effects is useful by Ben Linders

One thing that I want to add: There are always multiple causes that lead to problems. Solving the *one* cause doesn't work, understanding problems by exploring all effects and all causes can be useful.

A Root Cause Analysis helps to explore problems. For simple and complicated situations (Cynefin) you can usually break it down to clear causes and effects, and addressing the causes has a high probability to prevent similar problems. For complex problems, in retrospect you can determine the relationships between effects and causes, but (similar as you already mentioned) there is no guarantee that addressing the causes will prevent similar effects/problems from occurring in the future. Only doing Root Cause Analysis is not enough in these situations.

Having a shared view of the root *causes* is IMHO still useful. You want to prevent similar problems in the future, that is why decided to do a Root Cause Analysis in the first place (see my blog post on www.benlinders.com/2011/business-reason-for-roo... on this).

With a better understanding of the problems and the causes, you are more able to discuss preventive actions. This is where a Solution Focused approach has value, as you will look for the strengths that can help teams to prevent similar problems.

Re: There are always multiple Root Causes: Understanding causes and effects by Hans-Peter Korn

This is the important difference between the "usual" Problem Thinking and Solution Focus:

The usual Problem Thinking is based on this assumption as you describe it:
""
With a better understanding of the problems and the causes, you are more able to discuss preventive actions. This is where a Solution Focused approach has value, as you will look for the strengths that can help teams to prevent similar problems.
""

In contrast to that Solution Focus does not analyse problems and their roots, as far as we have to handle NO situations where things are fixed and well-known in advance, and where your efforts don't themselves change the situation dramatically.
(see my post www.infoq.com/articles/retrospectives-as-prospe...)

Steve de Shazer put this in a short statement:
"Problem talk creates problems - Solution talk creates solutions"

And in the preface to "Putting Difference to Work" [de
Shazer, 1991, p. xiii] de Shazer says: "You do not need to know what
a problem is in order to solve it."

More about this you can read on page 17 in books.google.ch/books?id=NYPrh8fl7voC&pg=PA...

Of course, I am aware, that this is VERY irritating for us with our background coined by "technical thinking" - for me it was also very uncommon some years ago.
But having done a lot of very successful coachings based on SF without any impetus to "understand" a problem and his roots thinking about "better situations" only without any problem-talk for me becomes very natural.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

12 Discuss

Sponsored Content

Educational Content

BT