We can view all situations in our work (and life!) as opportunities from which to learn how to better handle similar situations in future. Looking back and asking, “How did I manage to…” is useful, but the more essential question is “How will I deal with future situations like this to improve my results?”
I call such reflections “PROspectives” instead of “retrospectives”.
We learn for the future many times every day. We learn to be on time at the bus stop, to deal with a new feature on our smartphone, to discuss in more useful ways with our boss.
And we know the more we reflect, the more we learn and improve.
Yet we often forget to use such learning opportunities during longer situations and processes. How often do you reflect on how you organize the eight hours of your workday? Or your weekend? Or how you managed to complete a specific and complex work package within a period of three weeks?
Furthermore, we seldom use this approach together with our co-workers or partners. How often do you analyze the way you together with your family managed your holiday? Or consider with your partner how to deal with the housekeeping? Or reflect with your team about how you managed your teamwork over the last four hours or five days?
Let’s be honest. Normally, we only undertake such reflections if we are forced to, especially in critical and unexpected situations. That means under time pressure and emotionalized:
“The dishwasher has been filled with dirty dishes for two days! It’s ALWAYS up to me to turn it on!” (But right now, you both have to leave for the theatre…)
“AB36CZ is not working - and we have to deliver it today at 6:00 p.m.! It was your job AGAIN, Bill, to do this. We cannot trust your commitments!” (And it is 2:00 p.m. with about six hours of work to do).
It might be helpful to increase the motivation to reflect regularly or more often, independently of acute, unexpected problems and without time pressure?
First of all:
- Avoid making a reflection session seem to be a psychological or therapeutic session.
And make clear that:
- such a session is a short (but not too short or terse) event with a chance to celebrate and sustain all that is working reasonably well (and offer some coffee and cake to celebrate!) and to uncover ideas for perhaps small future improvements.
- it is, to keep it short, not a review to analyze failures and to invest a lot of time to dig out root causes, and to point fingers at people responsible for failures.
All this is supported by calling these events “PROspectives”.
Following Norman L. Kerth’s Mining for Gold Exercise, these are the core issues of a PROspective:
What worked well that we don’t want to forget?
This list is for those things that most agree worked well and that we want to continue doing on the next project.
What did we learn?
Here is where we document causes and effects that have lead to learning.
What should we do differently next time?
This list is for issues that need to be done better next time.
What still puzzles us?
This list is for issues that the project team doesn’t have enough information or skill to resolve. The issues on this list often require training or more thorough investigation.
What do we need to discuss in more detail?
Issues on this list are things that need further discussion, clarification, information, etc.
Steps to handle core issues:
- Warm up --> Platform for confidence and trust
- Sprint- (release-) panorama
- Appreciate what is working well and sustain and increase it with the UUS tool
- Find specific actions items for improvements with the PLUS tool
- If necessary, apply the impediment solvent
- Second-order PROspective
- Teamwork Backlog
The following suggestions apply to a PROspective held at the end of a time-boxed phase of work by which the team delivered a useful result either for specific stakeholders or for the team itself as a prerequisite for the next time box.
The time box might be something like a sprint of one to four weeks (typical for agile development practices) or could last about two to four months for a release.
If you apply a PROspective to a work process longer than four months - maybe as a debriefing or post mortem reflection of a whole project - be aware that you might not find enough learning and improvement opportunities because there might be not many or even any sufficiently similar situations in future.
A PROspective is too heavy a method for shorter phases of work, like only several hours. You’d be better off with something leaner, for example slide 24 (Reflect the Process). If you want to apply these suggestions to produce results other than at the end of a time-boxed phase of work, you may take these steps as inspiration for an adapted version appropriate for your situation.
The steps of a process-pattern to perform a PROspective are a pattern, not a cookbook. Always adapt it to make it appropriate for the specific context.
A PROspective that covers a time box of about two to four weeks of work should require two hours to complete. At the end of two to six months of work, it should take about three hours. In any case, avoid a strict time limit. Respect the needs of the participants to have enough time to reflect, learn, and invent actions for improvements. Too much steering will kill creativity. Take in account these two of the four principles of Open Space:
Whatever happens is the only thing that could've.
When it's over, it's over.
Don’t worry if the PROspective needs more time than planned. As long as the participants - the owners and beneficiaries of the PROspective - are willing to continue, it is fine. You, as the facilitator, are responsible for keeping the process on track to enable reflection, learning, and inventing actions for improvements. If you think the team has lost track of that and the meeting has become a waste of time then share that impression with the participants. If they want to go on anyway, it is their decision. You are the enabler, not the director.
1. Warm up --> Platform for confidence and trust
Don’t start with funny warm-up games!
You are working as an adult with adults. To start a PROspective by playing with balls, for example, may undermine the PROspective’s reputation and intent as an event for learning and improvement in a context of professional business-driven work. Some participants may think that they slipped into a therapeutic encounter group.
Instead, keep it lean and focused on the outcome.
Offer this PROspective manifesto (on a flipchart on the wall):
We intend to create learning and improvement for our future way of work by
- uncovering, sustaining, and enhancing our success patterns
- seeking improvements
- learning from and with each other
- defining concrete actions and tasks to improve our future way of work so that the effort invested in this PROspective is paid back to each of us
If you, as the facilitator of the PROspective, can see strong signs that all participants support this manifesto, you can go to step two.
If you suspect that there may be some aloofness to one or more points, it is important to work out just how far the participants accept this manifesto. Scaling Poker may be useful for that:
Give this scale:
0 = I disagree with the manifesto completely
10 = I fully support the manifesto
Have participants write their score from 0 to 10 on a small card and put the cards backside up in a pile on the table. The facilitator shuffles the cards, turns them over, and sorts them into columns to build a bar chart on the table:
The facilitator firstly appreciates the high scores (8, 9, 10 in this example) and explicitly accepts the moderate scores (5 and 6).
Next, the facilitator asks the participants to split into small circles of two or three people to consider these issues:
- How can the success of this PROspective be supported, taking in account the aloofness to one or more points of the PROspective manifesto?
- What show stoppers must be avoided?
Each circle writes its ideas on sticky note and adds it to the bar chart:
The facilitator thanks all for their ideas, mounts all notes on the flipchart with the PROspective manifesto, and expresses confidence that the PROspective will work fine by keeping in mind the manifesto and the additional notes.
The facilitator must also accept unrealistic ideas like “Don’t take longer than 20 minutes so we can return to our work.” But 20 minutes later he can ask all participants, as the owners and beneficiaries of the PROspective, if they want to continue. It is up to THEM, not to the facilitator, to decide this.
Remove the bar chart from the table. It has done its job.
If there are HEAVY concerns, the facilitator has to moderate a solution-focused conversation (see What is SF?) with all participants on how to deal with them.
Don’t start with the next step of the PROspective as long as there is still any heavy concern or aloofness against the PROspective manifesto. At worst, find a new date for the PROspective and use the time to build a better platform.
2. Sprint- (release-) panorama
2.1. Brainstorming
Draw a grid on a wall:
Each participant writes significant occurrences, situations or activities on sticky notes and places them on this grid.
Attention:
- Use specific occurrences, situations or activities, not general statements
- Do not allow discussions or deals among participants
2.2. Reflecting the panorama in pairs
In pairs, participants reflect on the panorama. They may move or rework their own sticky notes but not those of others. Discussion may take place only within the pairs.
2.3. Refactoring and clustering all together
All participants as a team change, remove, or add sticky notes.
All notes that belong to the same or similar topics or aspect are marked as such, maybe with colored glue dots.
- This should take no more than 15 minutes. No exhausting discussions!
2.4. All together: Selecting the hot spots
All participants as a team select the two or three most important topics, aspects, or standalone issues (such as number three below) that worked well.
The team also selects the two or three most important topics, aspects, or standalone issues which must be significantly improved.
3. Appreciate all that is working well and sustain and increase it with the UUS tool
Work out for the up to three best things:
(Based on the micro tools developed by Michael Hjerth, www.solutionwork.se)
UTILIZE SUCCESS (SEARCH)
- How do you know that it was successful? (Ask “What else?” to find more than one aspect.)
- How can others recognize that is was successful? (This is a typical systemic question to change the focus by slipping into the shoes of others to uncover more signs of success.)
UTILIZE SUCCESS (STABILIZE AND AFFIRM)
- How did you do that? What else?
- What did you learn from it?
STEPPING THE SCALE
- What will you do more as a result of this, to sustain or even increase it?
- What needs to be the very first step? How will you know that this step was successful? --> Put this in the Teamwork Backlog.
- What will you do differently as a result of this to sustain or even increase it?
- What needs to be the very first step? How will you know that this step was successful? --> Put this in the Teamwork Backlog.
Why is it important to invest so much effort to reflect upon what is working well?
Imagine a family that only mentions what is bad and not working. No one says a word about the good things. This family will find it hard to appreciate their few good experiences, at least. The family cannot cultivate good experiences or grow. Imagine the mood…and how the family will sort through tough situations.
Understand that we are not asking facilitators and participants to only discuss positive aspects and to neglect difficulties, problems, and failures. But do take care of what has been working based on the resources to sustain those practices. Otherwise, they will wither and vanish. No athlete will improve through only excercizing his weak muscles. He has to take care of his top-performing muscles with the same or even greater intensity.
4. Find specific action items for improvements with the PLUS tool
Work out for the up to three things to be improved:
(Based on the micro tools developed by Michael Hjerth, www.solutionwork.se)
PLATFORM: The point of departure for searching for what works and what should be improved or changed
- What is your concern? 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:
- 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?
- 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.
It is important here to avoid the words “problem” and “solution”.
The word “problem” often connotes something that is given and not changeable. It’s an inescapable fact. It’s said that problems are problems because we call them problems. It’s better to talk about “situations”. Situations are fluid and can have different colors: stressing one person; motivating others; preferred; changing; long-lasting; appropriate; hindering; sustaining…
(Of course, a complicated “chess problem” can be challenging in a positive way. The emotional ascription of “problem” depends on the context.)
The word “solution” often is associated with the “solved problem” as a persistent result rather than as an adaptive, step-by-step process towards a changed (and hopefully better fitting) situation. Politicians and tough managers will say, “We have the solution for xyz.” I prefer to talk about “changing the situation” rather than finding a definite “solution”.
5. If necessary, apply the impediment-solvent
If you find that at STEPPING THE SCALE that a serious impediment seems to block the next, even small step, you may apply the following impediment solvent”.
5.1. How easy is it to eliminate or bypass this impediment?
Have the team estimate the ease of eliminating or only bypassing the obstacle from 0 (absolutely no chance) to 10 (very easy). This is the same as planning poker or a magic estimation.
0-------3-------------------10
Ah, a 3!
5.2. What makes this chance a 3 and not a 2 or even a 1? What else? What else? What else?
0====3-------------------10
5.3. What can you do, using what is already available, to eliminate or to bypass this impediment?
- Which are the first concrete, small, possible steps? What else? What else?
- Which of those steps is the easiest?
- Who makes this step together with whom?
- How will you know that this step was successful? --> Put this in the Teamwork Backlog.
5.4. Imagine that the chance to eliminate or to bypass this impediment is a 4 or 5.
0====3==4==5----------10
- What is the difference between the 3-rated chance to eliminate/bypass the impediment and the chance rated 4 or 5 to eliminate/bypass the impediment?
- How can you contribute to increasing the chance from a 3 to a 4 or 5? What else? What else?
- What might be the easiest of these alternatives?
- What is a very first concrete and small step toward a 4 or 5?
- Who makes this step together with whom?
- How will you know that this step was successful? --> Put this in the Teamwork Backlog.
The mechanism of this impediment solvent is based on five ingredients:
- In step 5.1, the intention to eliminate or reduce the impediment is expanded to the alternative possibility to bypass the impediment. Very often, bypassing is not seen as an option. We often fixate on eliminating/reducing only.
- In step 5.2, the focus shifts from “how to eliminate/bypass” the impediment to the chance to do so and available resources that contribute to this chance.
- In step 5.3, these now uncovered resources are used as tools for a first step to eliminate/bypass the impediment. The “What else? What else?” questions broaden the spectrum of alternatives.
- In step 5.4 a slightly enhanced chance is imagined and possible alternatives for own contributions are explored
- All this helps us to escape, step by step, from the “problem” trance that typically makes impediments seem indomitable at first. As long as we stay in this trance, we will either be frozen or will try to handle the impediment in a traditional way with a limited set of methods.
6. Second-order PROspective
This is the PROspective of the PROspective meant to gather learning to improve the next PROspective. For this, we use the UUS tool:
UTILIZE SUCCESS (SEARCH)
- What were the best things we did during this PROspective?
- What will others who hear/see the results of our PROspective say was the best?
UTILIZE SUCCESS (STABILIZE AND AFFIRM)
- How did we do that?
- What did we learn from it?
STEPPING THE SCALE
- What will we do more of as a result of this? Put it in the --> Teamwork Backlog.
- What will we do differently as a result of this? Put it in the --> Teamwork Backlog.
7. Teamwork Backlog
All participants as a team
- Consolidate the Teamwork Backlog (clustering similar next steps, maybe rephrasing some steps, ordering the steps).
- Visualize it as a task board or Kanban board.
- Agree on how to manage and monitor the execution of the planned steps (maybe by having once or twice a week a short team aperitif (or beer) that works like a daily standup in front of the teamwork task board).
Conclusions and further reading
This kind of PROspective is in line with important core principles and values behind lean and agile:
- Working towards a “preferred situation” as a vision
- Observe and adapt
- Act with small steps
- Respect people and their needs
- Build on and sustain what works
- Search and use existing resources and opportunities
Don’t confuse a PROspective with naive positive thinking and don’t see it as an invitation to put on rose-colored glasses. It is an offer to handle situations that are working poorly or not well enough in a constructive and respectful way.
This way is called “solution-focused work”. You are invited to read this brief introduction and to learn a bit more by reading this article. You may find much more about solution-focused work in organizations at Jumpstart into Solution Focus.
Of course, the wording “solution-focused” (or “solution orientation”) may be misleading, as I explained in step 4 above. Inspired by the work of Tomasz Switek, I prefer to use “solution and situation focus”.
About the Author
Dr. Hans-Peter Korn works in organisation development, personnel development, and change and knowledge management. He has recent experience as agile coach and consultant with a pragmatic understanding of agile derived from his work in large enterprises. He is co-editor and author of the books Agiles IT-Management in großen Unternehmen, Symposion Publishing 2013 and Solution-Focused Management, Hampp 2006.
Community comments
Solution-focused goal-driven retrospectives
by Jason Yip,
Re: Solution-focused goal-driven retrospectives
by Hans-Peter Korn,
Re: Solution-focused goal-driven retrospectives
by Jason Yip,
Re: Solution-focused goal-driven retrospectives: Trust in intent and trust in capability
by Hans-Peter Korn,
Strengths Based Retrospective
by Ben Linders,
Re: Strengths Based Retrospective
by Hans-Peter Korn,
Asking for Causes of Problems is not appropriate for social systems (Re: Strengths Based Retrospective)
by Hans-Peter Korn,
The combination of Root Cause Analysis and Solution Focused can be a very strong one
by Ben Linders,
Re: The combination of Root Cause Analysis and Solution Focused can be a ve
by Hans-Peter Korn,
There are always multiple Root Causes: Understanding causes and effects is useful
by Ben Linders,
Re: There are always multiple Root Causes: Understanding causes and effects
by Hans-Peter Korn,
Re: The combination of Root Cause Analysis and Solution Focused can be a very strong one
by Hans-Peter Korn,
Solution-focused goal-driven retrospectives
by Jason Yip,
Your message is awaiting moderation. Thank you for participating in the discussion.
Have you seen this? jchyip.blogspot.com.au/2012/02/solution-focused...
Strengths Based Retrospective
by Ben Linders,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.