Away with the Ishikawa

I was allowed to carry out the retro in one of our development teams. As I only had representation and little time to prepare, I borrowed the example from Ralph and Veronika’s book – and it went really well. At the end of the 55-minute retro, I noticed something that reminded me of my beginnings with the solution-focused approach.

The team room is very small and has little free space on the walls (several boards and a free area for the projection). So I asked: “Where can we hang this?” “On the inside of the door, of course” came the immediate reply. When I saw the door, I looked worried (there were X layers of flipchart paper with lots of Post-It notes stuck to it). “We can tear it all down, it’s all old and we haven’t implemented anything” came from the team. Anyone who has worked in and with agile teams for a long time may be familiar with this and I was glad that we were able to clear the air together so easily.

On the way back to my office, I suddenly remembered a situation in February 2016. I remember the exact day. It was Tuesday, February 16, and I had been at the 66th Agile Monday in Nuremberg the previous evening. One of Ralph’s sentences still resonated with me: “The solution (usually) doesn’t care how the problem came about.”

Full of enthusiasm, I told every colleague on the way from the underground parking garage to my office how great the presentation was. I passed a small meeting room where two colleagues were standing in front of a large printout (plot) of an Ishikawa diagram and were very engrossed. As the door was open, I went in and asked:

“Well, does the Ishikawa get you anywhere?”

As the answer was not very convincing, I immediately presented my new insight: “The solution (usually) doesn’t care how the problem arose.” My colleagues looked at me, half horrified, half happy, and said: “We’ve been working on it for more than two days now and haven’t made any progress, even though we’ve put so much energy into it together with many colleagues.” It looked as if they were relieved to be able to stop. They immediately seemed a little more relaxed.

They followed up with something like: “We’ve always done it this way, but if we’re honest, nothing sustainable has ever come of it.” Then I said in my casual way: “If it doesn’t work (anymore), don’t do it and do something else.” After all, I had “absorbed” everything there was to say about it the night before.

Then I made my way back to my office. Some time later I passed the room again, it was empty and the Ishikawa was gone. Over lunch, one of the two colleagues told me how much effort they had put into these analyses and how little came out of them, or rather how exhausted they were afterwards, which meant that they were never able to derive any measures from them.

“We have understood you: Ditch the Ishikawa and focus on the solution(s).”

Over the next two days, all the Ishikawas disappeared from the walls. I haven’t heard anything about them since, nor have I heard anyone mourning even one of them.

What is much more important, however, is that my colleagues are now putting the “recovered” energy into ideas and solutions, asking “why” and daring to try things out more often. The “experiment” has become an even more important tool. To avoid giving the wrong impression: We are still at the very beginning when it comes to “solution-focused work”. After all, we are 200 colleagues working together on one application.

But we know that “patience and confidence” and the “power of small steps” are what will get us further. Looking back, I can say that “away with the Ishikawa” was the first, decisive and very important step for all of us towards a solution-focused approach. If you like, I can tell you all about what has happened in the meantime in further blog posts.

What is the Ishikawa diagram good for?

The name “C&E” (cause/s and effect/s) or “cause-effect diagram” explains quite well what it is all about, namely understanding the relationships between causes and effects. Where did Kaoru Ishikawa use the diagram himself? As one of the “Seven Tools of Quality”, also known as Q7, it is used to identify sources of problems in production with materials, methods, machines and people (= 4M). In other words, it is about problem source(s) and their elimination (= simple solution). Even if the extension to “8M” came later, it was never intended as a tool for complex topics or even complex systems in development. Accordingly, it is also unsuitable there. See Wikipedia disadvantages.

Where have I used it for complex topics anyway? In a PowerPoint presentation to present or explain solutions (which were developed with a focus on solutions) to an audience of American engineers. These people are used to C&E and understand the content more quickly and easily. In addition, I have added two arrows between “branches” to make the overarching connections at least partially visible. However, when using this approach, make sure that the emphasis remains on the solution!