Creative organizations, teams and leaders often encounter problems, as they explore new frontiers.

Seeking to prevent a problem’s recurrence, our biases may lead to a dysfunctional “fix”…

Completing a task may involve many people and many steps. At first, we focus on the last people involved or the last steps taken (Availability Heuristic). If we fail to look deeper, our solutions could worsen our situation. For example, if bad news causes us to kill the messenger, we eliminate a good source of information (Shooting the Messenger).

All problems have many causes. If I crash my car into a tree, here are some causes: I wasn’t looking in front of me; the pavement was slick; the car behind me was honking; my passenger was yelling at me; it was raining so hard I couldn’t see; I had a lot on my mind, since my friend is sick; I didn’t get enough sleep; I’m easily distracted.

We can usually prevent recurrence by fixing just one or two systemic causes.  For example, I could drive more slowly, and I could ritually calm myself before driving. However, immediately following my crash, neither I nor my passenger will likely think of this subtle solution.

Forces

People have cognitive biases that prevent them from seeing causes. For example, confirmation bias prefers causes that agree with our initial assumptions. Ingroup bias prefers causes that implicate people outside our close associates. Sunk cost bias shuns causes that involve expensive investments. Recency illusion can prefer causes that have become recently visible, but were present and hidden before. The bandwagon effect prefers causes that other people mention. (List of Cognitive Biases)

Process changes can compensate for cognitive bias. By involving different types of people from outside our group in analyzing a problem, we can overcome confirmation and ingroup bias. Hosting a brainstorming session that allows a cause to be mentioned only once, can reduce the bandwagon effect. Reminding people that agile approaches allow redirecting project budgets to more profitable efforts can reduce sunk cost bias. Asking people to look for systemic causes can reduce recency illusion bias. (Cognitive Bias Mitigation)

People cannot simultaneously compare more than 5 potential causes [Chunk Before Choosing]. Presenting causal relationships visually can improve our understanding.

When problems occur in highly political organizations, blame and fear are common concerns. People implicated in a problem may be blamed by impatient leaders and fearful colleagues for problems, before analysis reveals deeper causes.

Group decision-making produces better outcomes when people:

• Communicate, facilitate and complete a well-planned analysis process
• Develop a thorough and correct understanding of the problem
• Evaluate negative and positive consequences of proposed solutions
• Choose one or more solutions with the best value/cost trade-off [gour1996][kolb2009]

Sakichi Toyoda advised Toyota employees to analyze a problem until they had identified at least one causal chain “five whys” long [ohno1988]. Fixing any of the causes could prevent the problem, and this gave employees many more options.

…therefore, starting from a failure, collaboratively produce a cause map. Avoid future failures by preventing key causes.

Here’s how to create a thoughtful cause map for a problem, incorporating the perspectives of many parties:

1. Schedule at least one hour when most or all involved parties involved in the problem can meet. Be sure to invite people from diverse roles and perspectives, as will improve the outcome.
2. Find a meeting room with a large white board or high-resolution projector. If everyone is local, schedule the meeting in a room with a large white board. Otherwise, use an online conferencing system, such as Skype or GoToMeeting
3. If you are using online conferencing or projection, install an application like OmniGraffle or Visio, which allows you to create directed graphs rapidly. Practice creating these graphs in conversation with other people well before the meeting (each of these tools have tricks to make graph construction fast, but you must learn them).
4. At the beginning of the meeting, write the problem inside a node at the center of the board.
5. Call on an attendee to state something that caused a named problem on the screen. “Name one cause for the problem.”
6. Create a new node for the newly stated cause, and draw an arrow from the cause to the problem.  The cause now becomes another problem to consider.
7. Ask the next person to name only one new cause for any problem shown on the board, saying “X caused Y”. Draw the X node with an arrow to Y.
8. Repeat step 7 until everyone has spoken once. After talking to each person once, a map starts to emerge. Sometimes something causes multiple problems, in which case that node has many arrows leaving it. Allow everyone to review for a moment.
9. Resume step 7 and keep iterating until a linear chain of five causes appears somewhere in the graph, or until attendees run out of causes.
10. Then help the team examine the map to find causes that could have been easily prevented. Using those preventable causes, put together a mitigation plan.
11. Take a picture of the cause map, summarize the mitigation plan, and send to all interested parties.

New Context

This approach overcomes many sources of cognitive bias. By forcing people to name an unstated cause for a problem, we avoid confirmation and bandwagon bias. By involving people from diverse roles and perspectives, we avoid ingroup bias and reduce sunk cost bias.

This approach also contributes to an agile base pattern [Embrace Collective Responsibility]. Non-agile companies and their leaders often “throw someone under the bus” when problems appear, diverting blame to avoid leaders having to take responsibility. In a cause map meeting, however, it doesn’t last if the person is in the room. We can blame someone (“Jeff pushed the button”), but eventually that person gets to describe the cause that made him or her do it (“the documentation is confusing”).  The result is deep understanding of how things happened, and leads us to solutions that might  fix more than the specific problem we’re investigating.

By graphing the causes on a board or screen, we reduce the cognitive load on participants, allowing us to consider more complex causes, and solutions that might prevent many causes at once.

When created with colleagues, the cause map becomes a social exercise that reinforces a culture of continuous improvement.

Example

The graph above shows a cause map my colleagues and I, in the Agile Program Office, made when we missed our 4th quarter goals in 2009. One chain has 7 links, more than the 5 “whys” we need.

• Original problem: Missed quarterly goals
• Split priorities [we were doing many important things at once]
• Took on survey (not aligned) [we decided to work on a huge survey project mid-quarter, with uncertain value]
• Erratic prioritization [we were randomly picking items to work on]
• We seem to like multitasking
• Not willing to say No [people ask us to do stuff, and we just interrupt our current work and do it, rather than thinking about whether it aligns with our quarterly goals]
• Not ranking by value [backlog items for this team didn’t seem to be ranked by return to the company]
• We don’t know how to measure our work’s value

We decided to focus on the cause “Not willing to say No” to distracting, unimportant work. We agreed that we would not take on new work independently, without consulting the team, but focus more on our shared efforts.

We also aligned our personal objectives for the quarter (“No related MBOs other than for Dan” in the diagram) to the Agile Program Office’s quarterly goals and overall mission. In doing this, we pioneered a new idea to frame every quarterly personal objective as a “stakeholder story.” The next quarter was much better. We accomplished most of our quarterly goals.

References

• [kolb2009] Michaela Kolbe & Margarete Boos, “Facilitating Group Decision-Making: Facilitator’s Subjective Theories on Group Coordination,” Forum: Qualitative Social Research, Volume 10, No. 1, Art. 28 – January 2009. http://www.qualitative-research.net/index.php/fqs/article/view/1244/2692
• [gour1996] Gouran, Danny S. & Hirokawa, Randy Y. (1996). Functional theory and communication in decision-making and problem-solving groups. An expanded view. In Randy Y Hirokawa & Marshall Scott Poole (Eds.), Communication and group decision making (pp.55-80). Thousand Oaks, CA: Sage.
• [ohno1988] Taiichi Ohno, Toyota production system: beyond large-scale production, Portland, Or,  Productivity Press. ISBN 0-915299-14-3 (1988).

Author

Dan Greening