One of the central benefits to applying Lean and Agile ways of working within our teams is that implementing the principles of these methodologies highlight our process problems by making them *painfully* visible to everyone in the group.
One of the most popular methods for causal analysis, the Ishikawa diagram (also known as the Fishbone), has been adapted by Agile teams in a variety of contexts to support a focused team discussions about the causes of negative symptoms that are affecting the team.
We’ve heard it said that the ‘fish rots from the head’ -- true in life as it is in our organizations, this metaphor is the guiding feature of the Fishbone Retrospective format, a causal diagram template made popular by product teams in large enterprises.
The Fishbone diagram helps us facilitate productive conversations regarding the process problems we have identified in order to ideate around appropriate solutions.
By identifying a key problem that represented a challenge for the team in their previous timebox of work, this format asks us to begin by defining the symptom, or effect, impacting the team negatively.
Although it begins at the problem, the Fishbone Retrospective doesn’t stop there, because it is ALL about getting to the root cause.
By encouraging the team to consider the symptom they are observing in different contexts, the fishbone format urges each contributor to dive into its potential causes, analyzing it through a few common lenses:
Causes that might appear in the People category include:
In the Process category, we often encounter issues such as:
From a Technology standpoint, teams often float up causes like:
.png)
In preparation for a Fishbone Retrospective, whether it is in-person or virtual, Scrum Masters or Team Leads must agree on a specific problem that is affecting the team’s process negatively.
Rule of thumb: Phrase the problem as a question as a way to invite team members to consider the possible answers and lead them in an exploratory direction.
This will populate the head of the Ishikawa diagram and focus the team’s efforts during the retrospective around solving this specific, overarching issue.
There are two popular approaches to running a fishbone retro with your team. The first allows greater flexibility and might be more suitable for more mature teams that have already built a rapport with each other. The second encourages the team to categorize their thoughts right off the bat and filter their ideas based on a number of key groups.
For a more laissez-faire approach, facilitators may ask the team members to generate ideas freely, without setting any parameters.
Invite team members to brainstorm possible causes of the problem, beginning at the most direct and obvious causes and digging deeper to indirect, hidden causes that may also be impacting the team.
For a more structured approach, label each of the fish bones with the name of a category under which you anticipate clusters of causes might form (ex. People, process, technology, etc).
Ask the team to sort the potential causes they have generated into the relevant category and, in effect, cluster their opinions for greater clarity.
In both cases, a best practice for guiding the team through extracting more in-depth ideas from this brainstorming session is using the 5 Whys method.
Ask the team to dig deeper to arrive at the root of the problem and defend their opinion by beginning at the problem and then questioning each of their causes at least five distinct times.
Focus the conversation around the more significant clusters that have formed in the fishbone diagram. If you have time leftover, discuss the outliers and ask their owners to go into more detail about their unique idea.
You’ll find that, sometimes, the devil truly is in the details and the solution to the problem at hand manifests itself from a discussion centered around one of your team’s outlier causes.
Crystallize the team’s ideas from the fishbone diagram to formulate clear action items.
The Fishbone diagram is a simple, yet effective, retrospective format that can help the team arrive at innovative solutions to persisting process problems that are stalling their progress on initiatives.
Created by Kaoru Ishikawa, the Fishbone diagram was first adopted by teams in the development and design context, but has since gained traction among a diverse range of departments in the business and IT. More recently, it has become particularly popular in implementations of the Scaled Agile Framework in an enterprise setting.
For any team looking to get to the heart of the matter, this exercise in identifying the true causes of our team process problems is a go-to retrospective format. It has been proven to help even the most traditional teams generate innovative solutions to their process problems.
Running your next Fishbone retrospective online? In ScatterSpoke, there are two ways for you to do that -- a more rigid column-based retro format or a free-form canvas. Both are ready for you out of the box, so your distributed team can hit the ground running, jotting down all their great ideas as they shake away the hesitation to ask (and answer) the tough questions.
ScatterSpoke helps you eliminate waste in your dev process.