In today’s blog post we will not only examine when there is no answer to why we have a problem and we therefore consequently need new science, but also the case when existing habits for solving a specific problem with current science must not be used in another context, i.e., wrong context where it will not give us the solution.
We reiterate how to use the what and the why questions, and as said before, the what many times need to be handled, but to come to the root cause, which is a necessity, we need to ask why. But, with rules there will always be some exceptions, and here are two, but very reasonable. There are two and only two reasons when to explore only the what and not the why, and it is in the two following cases:
- We know the answer to the why and therefore the root cause(s), but the circumstances make it hard to solve the root causes(s)
– an example is when the customer comes to a psychologist, where the root cause(s) can be very hard to handle, and this is examined in part 5 of this series.
Note! But, when we switch context to a company, we suddenly have the root causes in our own hands if our people are getting sick due to our own bad organisation.
-Another example is in part 6 of this series, where car queues are examined, which we can only solve with thorough planning of when the cars can be on the roads, a method that has so far not been fully implemented in any country. Therefore, the science of queues needs to be used with queue simulations built on queueing theory in order to understand how the traffic congestions can be minimised with new roads, time specific toll fees, more lanes, specific licence plate numbers rules for allowance on weekday or day of month, etc. - There is no answer to the why question, because we do not know the science or our solution yet and therefore, we do not know the root cause(s), or we cannot find them due to a gap between the effects, for example see Cobra effect, where the Cobra farms needed to be found before the root cause could be understood (the bounty).
– An example with blood transfusions will be thoroughly discussed further down.
Note! There is also one big no-no, when the what can never be used by itself and that is when we already know the why, and consequently having the root cause(s) to a problem in our own hands.
– part 6 of this series has a very appropriate example of this regarding queues of activities. We have the answers with better planning and T-shaping in our hand, but the Agile community instead looks for handling the symptoms of the root causes, i.e., the queues, which only will lead to new chains of symptoms that cannot be foreseen, insolvable as well. This is a big no-no and together with takt time, the chains of new symptoms described above gets even bigger. Not asking why when having organisational problems, can lead not only to trying to solve these insolvable symptoms, where WIP Limits/Constraints for Agile queues is a good (bad) example, but also to experimentation, where Continuous Improvement in Agile is a good (bad) example. To start experimenting on symptoms, when the root causes already exist, is as bad as trying to solve the symptoms. The consequence of this means that we always first must solve our organisational problems, before we even think about doing a situational assessment or mapping. A situational assessment is most probably not even needed (especially not directly) after the root causes have been dissolved, if there are not also non-caused problems to be solved, but which is normally business as usual with the current way of working.
We can take the earlier example regarding the EMC problem discussed in part 5, and modify it so it becomes clearly stupid. From the test house we now only get the information that we have a failure on our product, not an EMC fail specifically. This means that we cannot find the root cause(s) to the failure, since the newer EMC requirements are not in our specifications. We will have the following walk-in-the-dark scenario:
Yes, this is a stupid example and would never be accepted, since we then cannot find the root causes to the problem. But unfortunately, this is how we treat our organisations of today and the habit of not asking why we have an organisational problem, has rather become the norm when we are trying to solve organisational problems. The walk-in-the-dark scenario as a norm for organisational problem-solving frankly, and sadly, looks like this when why the organisational problems exist is never asked:
The results are of course bad, since symptoms can never ever be solved. It is all about that reduction and aggregation in a complex system, like an organisation, is wrong a priori and this is thoroughly explained in this easy-to-read blog post by Dave Snowden.
A complex system like an organisation shall not be mixed up with a product that is only complicated, and where reduction and aggregation can be done since you already have the product. The reason is that in a product with problems, the problems can be reiterated, even though it sometimes can be difficult to find the start condition and the right input, to reiterate the problem. This also means that if the real root causes to the problem is hard and/or expensive to take care of, for example changing hardware at the customer, the many symptoms can sometimes be taken care of in software or another cheaper solution, due to the repeatability. In the same way it is possible to make the product cheaper by optimising the parts, even though EMC, heat dissipation, space, electricity need, etc. need to be considered.
But for an organisation, the symptoms cannot be foreseen, which makes it necessary to dissolve the root causes. And cost reduction of a part of the organisation, like head count reduction or outsourcing, will easily fail, since the parts or value streams in a complex system can never be isolated. An isolation of parts or trying to optimise them separately, only lead to sub-optimisation.
And a complex system like an organisation shall definitely not be mixed up with a production system, which is an obvious system where the reduction has already been done into the different processes and only the remaining repetitive aggregating of the product is left. We can put it like this:
The development of easy-manufacturable complicated products and services that delight the customers, is complex.
Now it is time to examine a very old example regarding the progress of science when it from the beginning were no answer to why the problem existed so we could only handle the what, but where research during centuries gave us the needed knowledge. This new knowledge then changed the answer to the question why to give other root causes, which will be clearly described below.
The progress of science regarding blood transfusions
In 1628, the English physicist (note the few disciplines for science in the 17th Century) William Harvey discovered the blood circulation. That meant that blood transfusions were possible and experiments with dogs were made successfully. But, due to a couple of unsuccessful experiments between animals and humans, blood transfusions were outlawed 1678. We had the following scenario:
And as you can see, we have a walk in the dark, because when we ask why people are dying, we do not have any right answers only guesses, and the correct decision is to finally prohibit blood transfusions.
More than a century later, we understood that the species need to be the same when doing blood transfusions and 1818 a successful blood transfusion was done between humans. But, the remaining part of the 19th century many people died due to blood transfusions, which were offset by many people also surviving and no more prohibition followed. We have the following scenario:
And the progress of science regarding blood has continued since then and are still continuing. Year 1900 the Austrian biologist (now we also have biology as a discipline) Karl Landsteiner understood that we had different blood groups, that made him 1930 to be awarded with the Nobel Prize in medicine, the AB0 system had been discovered. The blood transfusions were now very successful, but still on some occasions, people died that could not be explained why. The Polish-American haematologist (the disciplines in science are now growing fast; reductionism) Philip Levine discovered 1940 the Rh system which made blood transfusions very safe. We have the following total scenario:
Now we have the science needed regarding blood in order to do safe blood transfusions. If we still have problems at a blood transfusion, the scenario changes and instead looks like this:
As you can see, we now have also the organisational level to take into account, when there are human mistakes done. But, once again we are not asking why to find out what individual person that has made a mistake. We are instead asking why to understand if our organisation, our system is good or not, since otherwise we can never find the root cause(s) to our organisational problems. Also added in the picture above is the case to the left, if there still is some science we do not know about blood, which it most probably is, when we are diving even deeper into the bits and bytes of blood.
Notice also the more and more specialised disciplines in science over the centuries, as could be seen in the blood transfusion example. This is also one part of the problem of not asking why when having organisational problems, as mentioned above about reduction and aggregation. In science it is obvious that if there is no answer to why, we use reduction to experiment on the details to get more knowledge and at the same time it is obvious that if we have the knowledge, we can aggregate it and use it. But, for organisational problems reductionism thinking makes us to start exploring the symptom, instead of asking why, maybe because we do not think there is an answer, or more commonly that the answer is outside the area of the investigator’s responsibility or power. So, here we go wrong if we follow the scientific approach when handling the organisational problem, also called the engineering metaphor.
As we have seen throughout this series of blog posts, we can never just attack the problem directly, the what to do, trying to lean on the current science instead is always key, with no exception. We always need to ask why when we have an organisational problem, or any problem, in order to reach the easy-dissolvable root cause(s).
This was all for today’s blog post.
C u tomorrow.