Welcome to the last blog post in this series about problem-solving, which will summarise the series and also state all implications of it.
As we have seen so far, problem-solving is easy if we dissolve the root causes. But, if we try to solve symptoms, we will instead generate new problems, in form of a chain of symptoms, a chain that will never stop. Not asking why on our organisational problems and therefore only trying to solve organisational symptoms, is unfortunately the norm in our organisations of today. We have different methods as Dispositional state mapping or any other mapping technique of the current state of the organisation. We also have multiple experiments in parallel, where Continuous Improvements in Agile is an example, all to try to gain new knowledge in a live system, mostly on a team level as well. With a live system, it means that we are in the Complex domain, with a clear Walk in the Dark, since Continuous Improvement on team level means suboptimization on the whole organisation.
How we got to this point where we are not trying to dissolve the root causes is a difficult question. But definitely it has something to do with that complexity theory is a quite new and immature area, very different from Systems Thinking that is only covering the ordered domains. and to some extent the liminal between the complex and complicated domains. Complexity theory of today bans everything with cause-and-effect chains when things are regarded as complex. This is due to looking at a complex system in real time, it is impossible to understand what caused the current snapshot and how the future will look like, which is totally correct due to all interacting agents. But, if we look at an organisation, we humans still have limitations regarding when we are doing problem-solving, or solving activities with interdependencies, like any organisation in any business is truly doing. This science about our limitations we already know to a great extent and the most of this science are common sense as well. This means that organisation’s way of working is wrong per se, if it is violating this human science, which unfortunately is the normal case. This leads to that for every organisational problem we have, we do not need to go live, meaning we are in the ordered domains, not in the Complex domain. This means that we can ask multiple why we have the organisational problem, since the science is already there, we do not need to do experiments, instead we must change our organisation’s way of working to fulfil the human science, which is Dr Russell Ackoff’s dissolve a problem. If we are not asking why and instead are trying to solve the symptoms with some panacea (Dr. Russel Ackoff’s “Manager’s list of panaceas” [1]), or trying to do small parallel organisational experiments in our live system, we have put ourselves in deep trouble. This due to the fact that we with a live system are in the Complex domain, where we with any intervention cannot foresee the unintended consequences in the organisation. But on the other hand, if we had a product problem, we would never ever think about start to do experiments directly, since we know that the visible problem that we see is only symptoms of the deep root cause. Instead, it is self-evident to ask why we have the unexpected product problem until we find the root causes and dissolve them, or finally need to experiment due to an error in our system specification. And only in very rare occasions the chain of whys ends up in that we do not have the knowledge and then, and only then, we do experiments to gain the needed new knowledge for our product.
This can be explained by some pictures/graphs with the system definition on the y-axis and the building blocks on the x-axis, with the values of right or wrong, giving four different options. We also have the choices working or non-working product, giving us two different pictures to for products. We start with the picture for working products, here also as a pdf file, The product is working as expected.
As we can see the green upper right corner is where we normally are, but of course the light green lower right corner is possible if the system definition is not correctly updated. The grey upper left corner can to some extent also work when the building blocks are not perfectly meeting the system definition, but should be rare since it is not a comfort zone. The black lower left corner is a product, that I would not like to repair if it has some problems, since we are totally out of control.
If we go to products that are not working as expected, we find the following scenario, here as a pdf file, Something is wrong with our product:
The black upper right corner we cannot be in, since the product is not working, and the black lower left corner is not once again reasonable. But the green upper left corner means that we need to do an analysis for our product, where a traditional analysis to find the root cause(s), like 5Why? or Ishikawa (fishbone) diagrams are good in combination, since we do not know if the problems are isolated or complex. We only know that the combinations of faulty building blocks in our product is almost infinite. Our analysis will show what building block that is wrong, or that we find out that there is no wrong building block. The former means that we have the following cases: 1) if it is a SW fault, we can most probably correct the fault to 100%, 2) If it is a HW fault we have a) change to the correct building block in production b) change HW also at the customer, or if possible, make changes in SW to mitigate the HW fault. 3) if we cannot fix the problem, we can degrade the system performance, if possible, and the customer excepts it. The latter, where all building blocks are correct, means that our system definition is not correct, since our system is not working as expected. This means that our synthesis is not correct and we need to continue in the green lower right corner and analyse and maybe also experiment to get new knowledge in order to find the solution. Only then we can change the system definition and change some building blocks to follow the new system definition, so our product has the performance we aimed for from the beginning.
From the latest blog post, we understood that we need to follow the laws of human science, when we are making our organisations with all its different parts. These parts (us) are already designed by nature with the capabilities of working in a certain way when solving problems, internally as well as externally when interacting with the other parts (us again) of our complex system, our organisation. This is very different compared to our system products, where we design all the parts ourselves; the internal functions as well as the external interfaces to the other parts within the system product, where we of course always need to follow the laws of natural science. For a very complex software problem that was solved for more than two decades ago and includes many different iteration loops within the complex domain and between the complex and the ordered domains, please see this series of blog posts.
For our products it goes without saying that we need to follow the laws of natural science. Laws or principles have not been considered for organisations, but to follow the laws of human science means that we will get the prerequisites for an efficient, innovative and healthy organisation, an organisation where we respect each other. This has during a long time been ignored, even though most of the needed science has been known and available for half a century.
For a non-functioning organization, please see the Dissolve the organizational problems series.
So, for organisations, only the organisation is changed to follow the cognitive and social abilities for us humans in our total organisation definition, meaning that the organisation will become more flourishing, more efficient, more effective and with healthy people. Simply by changing the definition of the organisation to follow our abilities, we are indirectly solving the root causes and by doing that, getting rid of all our organisational problems. This is what Dr. Russell Ackoff called “dissolve a problem”, to redesign the entity that have the problem, in order to get rid of the problem, and we can then write the following quote:
An organisational problem can only be dissolved, never solved.
Dr. Ackoff also states that problems are transdisciplinary in nature, which also goes hand in hand with our set of principles which is the holistic or transdisciplinary solution. A symptom can then be seen as a disciplinary cut of the organisation in any direction; group, agile team, quality, culture, silo, unhealth, requirements, design architecture, test, etc. where the problem is found. If we continue to think about the implications of the fact that symptoms cannot be solved, anybody trying to do that will of course fail. But today there is more and more treacherous talk, talk that is easy to get lost in, with no connection to reality, something Dr. Ackoff called “intellectual con men”. Here is a picture trying to show that the consequences of not asking why on symptoms, actually will put us in a state of lies, non-systemic acting, sub-optimisation, politics, any opinion is valid, etc., a state we only can avoid by asking why we have our problems. Here as a pdf, symptoms and root causes – general.
If we go back to our picture of the organizational and product levels combined into one picture, it looked like this on a general level, symptoms and root causes – different levels.
And today, normally the product level is quite OK in most of the organisations, doing 5 why?, Ishikawa diagrams (fishbone diagrams) to find the root causes to problems within the products. But, very few organisations are actively looking for their own organisational problems, where Toyota with their Jidoka (problem-solving) pillar, is heavily focusing on problem-solving for their success, see this series of blog posts about Lean (Toyota’s) thinking and principles. And the level between the product and the organisation, is due to not wanting to blame individuals, normally untouched as well. We then get this picture of the status in our organisations today regarding our problem-solving ability. Here is the pdf file, symptoms and root causes – different levels – with judgement.
And once again remember that it is not about finding an individual to blame, which unfortunately has led to a concreted rule when doing traditional analysis to find the root cause(s), and which is the main reason for not continuing to ask why when the root cause in the product or service has been found. Instead, we always need to continue to ask why to find the root cause(s) to a possible organizational problem that may have led to the problem in the product. This is another main reason for not continue to ask why, since the system is impossible to change (i.e., symptoms cannot be solved) if we do not know the root causes to our organisational problems. See this blog post for the root causes for organisations’ way of working.
For the last decade the Agile way of working has introduced some new fresh team thinking, but that unfortunately fails when scaling up in a big organisation, since the engineering metaphor that unfortunately normally is used, cannot be used in complex systems, here clearly stated by Dave Snowden in this easy-to-read-blog-post.
If we summarise the blog posts of this series and our new understanding of organisational problem-solving, we now know the following:
- The major thing we have learned is that we need to ask multiple why on any organisational problem until we come to the root cause(s). No method not asking why on an organisation’s original problems, neither dispositional state mapping or other mapping techniques will therefore do the job without extreme risk for suboptimization and unintended consequences. There is no exception.
- A root cause is easy to dissolve, it does not require any rocket science.
- Any problem that is not a root cause is a symptom. We may also need to care of the symptom, the what to do, for example wipe up the oil under a leaking machine or if our people have got sick by stress.
- It is impossible to solve a symptom because the solution is an intervention to our complex system, which means unintended consequences, not even rocket science can do it, which is commonly called to sub-optimise, if we try. We can as well also call it reductionism (simplification) if we claim that we can solve the symptoms, or as many methods do, fully ignore the problems of today’s organisations.
- That we have our set of principles, derived from human science, that we need to follow, see this blog post.
- That our root causes are the negated (not fulfilled) laws/ principles.
- That root causes (and also symptoms) are context independent, which are only logical, since the laws and principals are universal (context independent).
The implications of what we have learned are the following:
- Organisational problems can never be solved directly, they need to be dissolved, i.e., indirectly a redesign of the organization, to dissolve the problems and the root causes, which is the same as fulfilling our set of principles. This is also according to Dr. Russell Ackoff, that dissolve a problem is the only way to fully get rid of a problem.
- Whenever a new tool, method, good/best practice or way of working is implemented in an organisation or any problem-solving at all without asking why on the problems of the organisation, it is sub-optimisation per se.
- Since almost no tool, method, good/best practice or way of working asks why on the problem, they cannot work per se.
(Already in the middle 1990s, Dr. Russell Ackoff made his list of Manager’s panaceas [1], a list of around 20 methods that come to his mind, for example Total Quality Management – TQM, benchmarking, downsizing, process reengineering, and scenario planning that he claimed, because of their high failure rate of about 75%, had one thing in common; they were antisystemic, sub-optimising. The elaboration on many of the methods Dr. Ackoff is mentioning can be seen in this series of blog posts, and with our current understanding of problem-solving, we understand that he was completely right.) - That trying to solve queues directly in Agile development is completely wrong (and impossible as well), the root causes must be looked for, see part 6 of this series for detailed elaboration.
- That Continuous Improvement* cannot be done on the respective Agile teams that are scaled to something bigger, instead we need to ask why on the problems (this is called Jidoka at Toyota, and is very different from Continuous Improvement* and this has been misinterpreted by Agile, see this series of blog posts for an elaboration), so we can find the root causes which means a holistic solution.
Note! Continuous Improvement* on a process in Toyota production is very different from product development, since a process does not have interdependencies to other processes, only a dependency or handover of clearly specified parts to the next process. Every process in Toyota Production is also repetitive, which makes systematic improvements much easier. Product development on the other hand is many times complex and is therefore a totally other context with many interdependencies and no repetitions. And in a complex system, the following is valid; “Everything that science is telling us is about systemic change, not individual change.”, according to Dave Snowden at Cognitive Edge, or from this blog post by Dave; “But if you want systemic change there are simply too many individuals to change to achieve it and it is a lot easier to change the interactions and allow people autonomy over what they are.”. And our systemic approach is to find the root cause(s) to the original problem, which means redefining our system and not changing our people, or dissolve the problems, as Dr. Russell Ackoff claims is the ultimate way to get rid of a problem. This need of course to be done systematically, as all efforts in science need to be when finding new laws and principles, by in this case by doing a System Problem Picture Analysis (SPPA). - That measurements for work need to be done on high level not on team level that are scaled to achieve something bigger, where Mary Poppendieck’s Measure-up is a very good proposal.
- That any measurement on a part of a line organisation not performing any work, for example a silo, will sub-optimise and therefore constrain the way of working in projects, teams and team of teams when they are collaborating to find the solution to their activities.
- We know all the possible root causes to organisational problems (since we know our set of principles).
- That we can make our Prefilled Problem Picture Analysis Map, with prefilled with the most common organisational symptoms. This makes it very easy for an organisation to find the root cause(s) to their organisational problems.
- We need responsibility for our system, our organisation, otherwise the non-working or working parts will be egoistic in one way or another. Since our organisation is complex, it is frankly less strange having system responsibility compared to a product that is only complicated.
All these implications together with this earlier series about implications on the possible way of working, will be thoroughly elaborated on in a later series. This in order to see if there is a possibility to find a few organisational ways of working for different domains and different context within the domains, or if it only will be a preferred high level one, no matter domain or context.
And here is a last statement summarising why asking why to our organisational problems is so important, all to avoid sub-optimisation of the organisation’s complex whole:
For an organisation having efficiency, effectiveness, quality and health problems, the answer is not local systematic improvements. Instead, due to its complexity, systemic problem-solving, dissolving the problems to get rid of them one time and for all, is the only way forward, which of course should (and can) be systematically done.
This was all for this series of blog posts, and I really hope that I changed your patterns of thought, so you can make the organisation you work for even more awesome.
C u soon again.
Next “chapter” according to the reading proposal tree is the blog post about the beauty of negating our principles to become root causes. For a deepening example about extreme complexity in software development with real time hardware input, please see this series.
*Remember that on the whole only continually improvements can be done, due to the synchronisation needed between the parts when the respective part’s improvements are executed at the same time, for example takt time change. The parts can (and must) themselves be continuously improved, as long as they do not affect another part.