Blog – System Collaboration Suite™

Welcome to the blog for System Collaboration Suite – A Systematic Approach to a systemic learning, including also the two methods for Dissolve the Organizational Problems – SPPA -Systemic Problem Picture Analysis and SOSD – Systemic Organizational Systems Design, as well as the method TDSD – Test-Driven Systems Design for software, a method for product development focusing on software, but also valid for hybrids for software and hardware! 

When we decide to do a change or transformation to a new way of working, no matter reason, we mostly try to correct the problems we do not want, instead to remove the real root causes to the problems. But the fact is, that as long as we do not remove the root causes, the solution for our new way of working will always be sub-optimising, which will be a hard, uncomfortable and never-ending journey. And we are not helped by saying that we are truly transforming to a modern method or framework, instead of our out-of-date. And it does not become easier when we say that the journey is never-ending. Unfortunately.
It is therefore necessary to, one time for all, break our old thought-pattern, and instead let the transformation benefit from understanding and removing the root causes, which will make our new way of working more efficient, faster and more fun, frankly flourishing.

This blog post is the introduction, as well as a concentrated summary, regarding the needed collaboration within any human Complex Adaptive System (human CAS). Even though it is general for any human CAS, the focus in this blog book will be on our organizations and our way of working, as our systems in focus.

The blog book thoroughly elaborates on a new transdisciplinary thinking about how to deal with organisational problems* (symptoms of something deeper rooted), as well as making the method TDSD, to be sure to make a flourishing software development organization. The research** made behind this transdisciplinary thinking, is built on already well-known science from different scientific disciplines, which in many cases also is common sense. I hope that you will find this blog book interesting, because I can promise you that it will give you new insights and a deep understanding of the way of working in your organisation. Frankly regarding any way of working since this thinking is context independent and therefore is agnostic to the actual way of working. The problems are evidence-based, since we clearly can see them and their negative effect on the organisation, so the problems are always the starting point here and now. But, since problems (symptoms) are impossible to directly solve, this new thinking only executes science-based interventions on the organizational root causes, which is the only way to get rid of organizational problems.

When you have that deep understanding about organisational problems and their root causes, you will always start to ask why when you have an organisational problem, since we can never afford to have built-in root causes in our system (our way of working, including the organisational structures). And that goes also for any decision that is taken within the organization too. Why take a new decision, when you do not understand the root causes to why your former decisions were not successful? We must always learn from our earlier mistakes, even though prerequisites have changed, since maybe our root cause is built-in to our system. You will also always learn to begin asking why someone’s method or framework (Ackoff’s panaceas) will solve your organisation’s problems, when someone tries to sell you a new universal method or framework. And by asking why, you will easily rumble the correctness of the answer, if the method or framework only tries to directly solve symptoms, which is the most common. But, solving symptoms/problems directly are impossible, they are insolvable, i.e., impossible to solve (no solution is possible), since symptoms will constantly be repeated in an eternal loop. We therefore really need to use the word insolvable and not unsolvable. Unsolvable is very different since it instead means that we do not have enough information, data, perspectives, knowledge, experience, skill, resources, etc. to find the solution. But, in the case of symptoms/problems, they are always impossible to directly solve and we always need to find the root causes, which on the other hand are easily solved.

An apt parable for describing symptoms and root causes in organisations (our system), is the pattern of ripples that we will get, when we throw some stones in the water. The ripples from the stones will interfere, making a criss-cross pattern, and the ripples are repeated, as chains of symptoms are from their root causes. If we try to intervene with the ripples, by throwing other stones on the already existing ripples in the water, it will only generate more ripples that will criss-cross with the already existing ripples. That is the same as intervening with our system by trying to solve the symptoms within it, which means sub-optimization, which will ripple out as new and cascading symptoms across other teams over the whole organisation. In fact, that only means we are creating “a mess – a system of problems”, as Ackoff put it, where the problems nowadays often are referred to as; wicked, sticky or intractable ones, finally reducing the efficiency and effectiveness of our organisation of planetary proportions. More, or other perspectives of the pattern of ripples, will neither make us come closer to a solution that eliminates the stones already thrown. In the same way, neither will more perspectives of the symptoms solve any root causes, which is the reason why we cannot use the<a term unsolvable for symptoms, as explained above. The only way to get the ripples to stop, is un-throwing the stones in the water, i.e., start again and not throw any stones in the water. In the same way we need to find the built-in root causes from the criss-cross network of symptoms, and make a new way of working which does not consist of the built-in root causes anymore.

And we really need to get rid of our organisational problems, since even though hundreds of new methods and frameworks have been presented to organisations the latest five decades, the same organisational problems are still around. The reason is, according to Dr. Russell Ackoff, that he stated in the middle 1990s, that they all are anti-systemic, which means that they are sub-optimising. This means that we need to be very vigilant regarding methods or frameworks that plead universality, since aside from that they may not be universal, the risk is high that they most certainly do not include any problem-solving of itself. This in turn means that the methods and framework indirectly are hiding that they are truly anti-systemic, by not letting the organisation dig into its own organisational problems, i.e., the organisation cannot find out if the method or framework really are appropriate for their organisation. Another approach, or in a combination with the former ones, is to “hide” the anti-systemicness, by saying that the method or framework will take 5-10 years to implement. This means that no one will be looking for built-in deficiencies from start and wait for many years of troubles and impediments until finally start to understand that something is wrong. Here we instead need to make our own critical reflections. Even though we are flexible and adaptive, we cannot solve built-in problems. Organisational problems have strong negative effects on our efficiency and effectiveness, which is stated in one of Dr. W. Edwards Deming many quotes [1]:

A bad system will beat a good person every time.

This is a very important statement, meaning that if we are not changing our bad way of working, we will not be successful and our people will be unhealthy. In the long-run, a bad system will per se also make our people show their absolutely worst possible behaviour. This is really not a people problem; it is only the bad effect of a bad system. So, if we fail to make a prosperous way of working where our people thrive and flourish, we can only blame ourselves responsible for the way of working. We need to be vigilant to our way of working, when our people start having bad manner and behaviour, since we people really are made for collaboration with each other. Marcus Aurelius, Roman emperor from 161 to 180 A.D., summarizes this aptly:

We are all made for mutual assistance, as the feet, the hands, and the eyelids, as the rows of the upper and under teeth, from whence it follows that clashing and opposition is perfectly unnatural.

Deming’s quote is also the reason why we in the blog book differ between built-in and normal problems. Built-in problems are the problems that are generated from a bad system, a way of working that simply is not good enough, since it consists of many unsolved root causes, i.e., having built-in root causes. Built-in problems are at first symptoms, showing that our way of working is not working, where the symptoms if they are not taken care of, sooner or later will lead to severe consequences. Bad emergent properties and bad emergent behaviour are the (emergent) consequences, that sooner or later will occur as a result of a malfunctioning system, which in turn over time will lead to inefficient and unhealthy people, and in worst case that people become burned-out.
Normal problems are problems that occurs even though we properly are following a well-functioning current way of working; the perpetual presence of Murphy, changed prerequisites, or the fact that we humans will make mistakes (even in the best of systems).

In order to be systemic, it induces that every organization and its way of working needs to have a top-down systems design originating from the purpose of the organization. This means that we cannot make our organization and its way of working, by cherry-picking parts of activities, methods, guidelines, heuristics, habits, rituals, values, cultures, etc. and aggregate to a whole. But, unfortunately aggregation of extractive practices to achieve a wholeness, within methods or as a framework of methods, has now undergirded new (or old) commercial methods for at least half a century. This in turn means, not only that System Collaboration is not a framework, it also means that we putting the organization at high risk if we proceed from a framework, since aggregation of practices is not a valid solution, not even for a clear context like production. And the bigger system and the bigger organization, the higher risk for a complete failure when proceeding from a framework, so we really need to be vigilant. System Collaboration is instead to be seen as a concept, an approach to problem-solving and organizational systems design, which leads to continual learning in the organization – frankly “A Systematic Approach to Systemic Learning”.

The picture below, System Collaboration – from the purpose to its fulfilment, shows System Collaboration and its content including its different methods.

It consists of four main parts; the Organizational Principles, and two different methods. The first method is used for problem-solving in any organization (or any human CAS), which results in an organizational problem picture, with all the problems connected all the way down to the root causes. The second method is used for (re-)designing the way of working in an organization to an appropriate one according to context and domain, that also is following all the Organizational Principles, where the method also results in a plan on how to implement the needed changes/transformation. The fourth part is TDSD – Test-Driven Systems Design, a method for big software systems, due to there is no appropriate one available today, i.e., not following the organizational principles good enough. TDSD solves that, and is a mix, a hybrid taking care of the best parts in some well-known methods.

Throughout the blog book the term product development, will be used for both hardware and software development, and when the term system or systemic is used, it generally refers to the organizational level, if nothing else is stated. What the Organizational Principles are will be explained further down in this blog post, but even though the name is pointing at organizations, the principles are valid for all human complex adaptive systems (human CASs). The methods for problem-solving and redesigning the way of working, are called Systemic Problem Picture Analysis – SPPA and Systemic Organizational Systems Design – SOSD. Using the methods together gives us the concept of Dissolve the problems in organizations, which is a name that is derived from Dr. Russell Ackoff’s “dissolve problems”, re-designing the organization (or any human CAS) in order to get rid of the problems once and for all. All other boxes in the picture are also deepened in order to get a full understanding of what to do, and why it is working, all the theory that informs the practices.

The best way to digest the information, knowledge and insights and get the deep understanding in this blog book, is to read the blog posts, chapter by chapter. This introductory blog post can be seen as the introductory chapter, and other blog posts as later chapters, many times connected as different series, i.e., sub-chapters. Here is a Reading proposal tree on how to read the blog book:

The right branch is the problem-solving branch, where you can read all about organisational problem-solving, the practice and the theory behind. The left branch on the other hand is the path to understanding the organisational principles, that any method and framework need to follow in order to work properly for a given context. A context can for example be complex like product development, or clear like production, not to mix up with that they both need educated, skilled and experienced staff. The blog posts in the left and the right branch, also points at blog posts in the middle branch, which consist of deep dives into theory as well as detailed examples.

At the end of every blog post the link to the next “chapter” according to above reading proposal, or to a deep dive or detailed example can be found, with clickable links. Within every blog post, there is also links to other blog posts in the blog book for a deep dive in a special subject, as well as references to books, other blogs and internet pages.

A list and links to the blog posts and series of blog posts in order of appearance can also be found at the end of this blog post.

The blog book’s mission
This quote is what System Collaboration nail down to:

A root cause is easy to solve, because it is not rocket science.
But, not even rocket science can solve a symptom.

This means, that if we are trying to solve symptoms, we will sub-optimise our organisation, and no one wants that to happen, that is simply common sense. To solve root causes instead of symptoms will look transcendental, since trying to solve symptoms is the normal approach if we look at current methods and frameworks offered to today’s organisations. These methods and frameworks never ask why on the problems within an organisation. The tricky part here is to know what is clearly a root cause, because they are the only ones that we can solve, no matter dealing with complex adaptive systems, products or anything else. And by the way, we of course need to have the right granularity, since we do not want to dig deeper than necessary into any science, like complexity theory, human science, logic, etc. Especially for human science, where we stop at the level of our cognitive limitations as specie, since that have co-evolved with the environment for millions of years, giving us unique collaboration abilities in our DNA.

Complex Adaptive Systems, (CASs)
All organisations are Complex Adaptive Systems. They are striving for a structured way of working, in order to reduce complexity, to be efficient and effective to meet the market. Evolution has given us humans the prerequisites as a specie to solve problems in a structured and organised way, and human science gives us also the numbers valid for building our organisations, which consist of people solving activities. All of our time on earth, this has been needed in order for us to survive as specie by first solving different activities in families and then later, in bigger tribes consisting of many families.

Any organisation is aimed for solving problems in their business and make the customers happy. But, in the same way as the products or service the organisation makes, need to follow natural laws (principles), an organisation as the complex adaptive system*** it is, also need to follow principles in human science, which to a great extent is pure common sense. As can be seen in the reading proposal above, the series of our common sense is also the first recommended series of blog posts to read, due to its importance and that it is easy to fall back on to understand the later series of blog posts.

The set of organisational principles
This blog book’s mission, is to give the readers a deep understanding of the necessity of knowing this set of principles, the building blocks, that effects the way of working in our organisations. Because, only if this set of principles is followed, the ones needed within the context of the organisation, an organisation can properly flourish. And the set of principles can only have these principles needed, since they are principles that science already has found (fact) at least since many decades. So, we cannot have more principles. Not fewer principles. And definitely not home-made principles that are more and more common today in some methods and frameworks.

Finding this set of principles means that we then, and only then, deeply can understand our organisation and therefore can make changes to the better. And this is really what System Collaboration is all about; a collaboration with the system, so we are fulfilling our set of principles. This means that we successfully can collaborate within the system and with the outside of the system, the market.

The mission is also to find this set of principles that will make our organisation flourish when it meets the market of today and tomorrow. A set of principles that are valid for any organisation, regardless of business, and that can manage any context. The principles will be referred to as the what. Mind that the what are not best practice, it is beyond best practice, since we must follow our set of principles regardless the organisation’s business.

Granularity
The granularity level of our principles is very important, so we can connect them to our evolutionary prerequisites as a specie for problem-solving and collaboration, where we can lean on the current findings made by human science**** [2]. This means that our organizational principles will be built on what is already in our DNA, no matter what our organisation is doing or what people we have in the organisation, which means the granularity level will always be people and activities. Violating the principles means that our organisation will not flourish, since we then are trying to fight against nature, which will mean fail, due to hampering the needed interactions for achieving the organizational purpose. This is the reason for many fails in today’s silo organisations, we are frankly violating our own evolutionary prerequisites*****, many times by sub-optimization.

Our Root causes
When having organisational problems, System Collaboration also here leans on already proven science, on fundamental facts:

1. The problems seen by the employees within the organisation
2. These problems are only symptoms of something deeper rooted
3. Symptoms cannot be directly solved
4. Only root causes can be solved (but, there are many different solutions)

By following these facts, we can find the root causes and solve them, which means that our way of working is changed, we are redesigning the system, to achieve System Collaboration. This means that we successfully can collaborate within the system and with the outside of the system, the market.

Redesigning the system, is referred to as Dissolve the problems in organizations, which the pre-complexity guru Dr. Russell Ackoff [3] talked warmly about. Then the problems (symptoms) no longer exist, they are dissolved, or as he stated it:

Only through design do you deal with the
whole and move through the parts.

Dr. Russell Ackoff

And a collaboration with our system, is to fulfil our set of principles, or solve the root causes (which simply are the negated principles), to our organisational problems. Remind that the practice of finding the root causes is universal and not context dependent, it is only the solution that is context dependent. But, if we instead try to solve the symptoms and continue to think that dissolving the problems is transcendental, we will continue to fight our system and nature as well, and we will lose. Every time.

Our Prefilled Problem Picture Analysis Map
When come so far, the mission is also to find the Prefilled Problem Picture Analysis Map for organisations of any kind. Then it is also possible to deeply understand why parts of a way of working for an organisation, method or framework, is malfunctioning or really is not good enough, and also to be able to fix it, without any risk of sub-optimising. This will also give many new insights, easy to understand, but some of them may be very hard to accept. For example these two blog posts show that Process Cycle Efficiency calculations and WIP Limits in Agile Development are sub-optimising the organisation, because they try to solve symptoms, instead of asking why to find the real root causes.

Finally, when we put all together, we can solve all organisational problems****** that depends on the way of working, by changing the system so our set of principles are fulfilled, i.e., Dissolving the organizational problems in Complex Adaptive Systems. We frankly re-build the system to fulfil our set of principles, what the organisation is capable to do according to our prerequisites as specie. By doing this, we can easily fulfil our set of principles, and our organisation can flourish.

The system start definition
All organisations, or any human system, can in short be defined as; “People that interact to solve activities with interdependencies”. With this granularity, as mentioned above, used when we are searching for our set of principles needed for collaboration and problem-solving, we are able to take advantage of common sense and also our evolutionary prerequisites that has been found so far in human science. This granularity level also complies with the fact that in complexity theory it is stated that in a human complex system the interactions are the more important than the actions. As humans we have during millions of years co-evolved with the environment about how to solve activities (problems), as well as to handle dependencies and interdependencies between the activities. With this granularity we will therefore not go into depth of what kind of people we have (regarding motivation, intention, attitude, identity, etc.) or what kind of domain the activity is in. The principles will therefore only regard our collaboration and problem-solving abilities, and will be totally domain independent, and our context will state which of our organizational principles that are “activated” (we need to fulfil in that context).

This start organisation definition will be our starting point for adding the necessary principles to our total organisation definition, since we do not want to clog our system with any principles that are not beneficial to our organisation, by the high risk of violating our own evolutionary prerequisites. We only need the set of principles that will make our organisation flourish.

The necessity of understanding the history of organisational work
In order to further understand which principles that are necessary, we of course need to look at the market, always with respect to human science and common sense. But, we need not only to understand the situation of the organisations and the market of today, we also need to look at their closely interwoven history. If we do not also understand the history when we are looking for our principles, we introduce some big risks, especially when we are changing the way of working:

1. We discard everything that is old, the whole Body Of Knowledge of the old way of working, since we do not really know what parts that was good and what parts that was bad.

2. We cannot explain for the employees why we need to discard all the old.

3. We cannot fully explain why we are transforming to this new way of working and not a different one, and why we don’t just adapt our current way of working.

As you can see, the above is more or less about acceptance, and we really need to be able to explain our changes in the organisation for our people, which will make the change, following Kotter’s 8 steps or some other change method, much easier with more people accepting the change.

Today we have a transformation wave rolling, discarding more or less everything of the old way of working. The risks above will also make a transformation to a new way of working difficult and the worst is that we won’t have a clue if it will be successful or not. Especially if some parts of the organisation, with a totally different context, most probable are directly non-favourable to the change to a “one-size-fits-all” solution.

So, if we instead understand why organisations reacted and how they reacted to the changes of the market over the years, then we to a fuller extent can understand what principles that are useful. If we do not understand the why in more depth, the risk is that we introduce changes to our way of working that are inappropriate, omit important parts or introduce changes that cause trouble. This can easily put us in a situation where we do not understand why we sometimes are successful and sometimes not, even though the circumstances looked the same.

So, knowing our history is key and one of the first series of blog posts that should be read.

The Cynefin™ Framework
Throughout the blog book, the Cynefin™ framework, a complexity framework, by Dave Snowden will be referred to, being a well-known, highly accepted and open framework. It pinpoints the importance of understanding the context and deliberate and accidental context switches. See the presentation of the framework by Dave Snowden himself.

The context is important
When we are learning from the history, we will not only understand more and more of the principles and why we need them. We will also understand more and more where in the organisation we will get the most benefit of the changes and where we must not do any change at all. We also need to find out when we need to work differently depending on context. An example is product development with many context switches in its Product value flow.

By understanding why, what, where and when, the organisations can themselves understand and take control of their way of working. They will understand whether it is necessary to make changes only in some parts of the organisation, or if a bigger transformation of the whole organisation is required. Since the organisations have the best knowledge about their own businesses, they can themselves do also the details of the transformation, the methods, the practice, the how. This is very different from copying someone else. Best practice should never be used, which Dave Snowden is very clear about [5]:

No country (or company) has succeeded by copying a prior success story. They learn from those, but then create something unique to their context. There are no recipes here and words like best practice should be banned from strategy.

Best practice, copying is never possible
When looking for our set of principles that will build our flourishing organisation, it becomes obvious that many methods and frameworks use principles incorrectly. They state principles that are only sub-optimising the work inside the organisation, i.e., trying to solve symptoms originating from the method’s and framework’s own bad or non-existing principles. I call these so-called principles for Sub-optimising principles. Due to that they are stated as needed, and it really looks like they are needed, they are really treacherous.

Another way to put it is that negated good consequences become symptoms and negated good principles become root causes in an analysis to find the root cause(s). So, emanating from the set of principles we are looking for, it is possible to make a powerful Prefilled Problem Picture Analysis Map for organisations****** that was mentioned above, with symptoms, root causes and their connections*******. On the top of the map, we will write the problem description we will have if the market need cannot be met, then we ask why, why, why, until we have found all our root causes. This map clearly shows an organisation’s problems and what to do about them. We do not even need to do an analysis, which many times are difficult, since it is easy to find only one root cause and then stop, or to find a root cause that is inside another part of the organisation’s jurisdiction, and not take care of it. In the Prefilled Problem Picture Analysis Map, we just colour the symptoms and the root causes in for example green, yellow and red and then we can see the prosperity level of our part of the organisation or the total organisation directly, depending on where we set the borders. We can both find and know how to remove our sacred cows!

Transformation strategies
Another thing that will be handled in the blog is the importance of having a transformation strategy to achieve the new way of working. Either the transformation can start with a small team and scale out to more teams on the same level, and then scale up, to make a system. Or it can start with the system and its parts and sort of ‘scale down’, while dividing the parts into smaller pieces. Both of them with their pros and cons. And of course, any solution in between.

But, remember that asking why on the problems, will make the employees understand what need to be done according to all different contexts within the organisation. Understanding why will simply give our people the right thinking, to be able themselves to do the changes needed. This means that the change can start all over the organisation, since we will solve the root causes to our organisational problems.

In the transformation strategy lies of course also the maintaining of the current customer deliveries and avoiding that the old measurements are not sub-optimising the introduction of the new way of working.

What’s in it for me? – HR’s role in a transformation
The consequences of the transformation are also important aspects. For example, the question “What’s in it for me?” needs to be taken care of. Consequently, HR’s role in a transformation is of utterly importance to any transformation. Even if the employees understand the why, they will still need to feel comfortable about their own future in the organisation also after the transformation.

To get many perspectives
There are also a variety of topics with similarities and differences from different businesses, domains and contexts, which together give an important understanding of how to build flourishing organisations, that delight the customers. Other topics that also are covered are:

• Take real control of your queues in Agile development – Mean queues and Lean queues

• Why WIP constraints are excellent in production, but sub-optimising in agile development

• Resource efficiency vs flow efficiency – and their very close connection

• Working sequential or parallel – which is best?

• The powerful Prefilled Problem Picture Analysis Map

• Value Stream Mapping – sequential vs complex

• Why Flow Efficiency measurements in agile development can be treacherous

These topics will be alternated with the common thread of the blog.

And in the end with all the needed pieces for System Collaboration in place, and all what that imply, maybe there is only a few different organisational solutions possible. Here is where our method SOSD come into the picture, especially valid for product development that consist of software in big companies with big system products.

The most important when changing the way of working is always that we understand that everything depends on context, in order to understand why and what changes we need to do where in our organisation. Understanding the context is always key in order to not let go of the control. Thrilling, right? So, until we found out how to transform our organisation, we cannot give up:

Continuous effort – not strength or intelligence – is the key to unlocking our potential.

  —Winston Churchill

And do not forget that it is always the way of working we need to change to achieve a flourishing organization, never our people, which leads to some guiding words:

No matter how it looks, it’s never a people problem.

Welcome to be part of the journey!

Next “chapter” according to the reading proposal tree is the series of blog posts about the necessity of common sense while doing a transformation to another way of working.

List of blog posts and series so in order of appearance in this blog:

• Blog Introduction (this blog post)
• The way of working history, part 1-5
• Time to dig into our principles
• Our first principles
• The beauty of negating our principles to become root causes
• Elaboration of queues
• Principles from “activities with interdependencies”, part 1-3
• The Product Value Flow in the Cynefin™ framework, part 1-4
• Principles from “People that interact”, part 1-3
• Principles from “to solve”, part 1-8
• Now we have a quite good set of principles 🙂
• Our set of principles give us great opportunities
• Human science, part 1-2
• Now we have completed our set of principles for a flourishing organisation 🙂
• What our set of principles implicate and not implicate…, part 1-3
• Our total organisation definition for a flourishing organisation
• Sequential or parallel work – which is best?, part 1-6
• Flow efficiency, part 1-5
• Solving complex problems in software development, part 1-6
• Aggregation vs Integration
• WIP inventories are great Flow Efficiency enablers in Lean Production
• Finding the root causes to queues
• WIP Limits in Agile development are sub-optimising our organisation
• Finding the root causes to too many people in the projects
• Organisational Clogging, part 1-7
• The New New Product Development Game article in our set of princ., part 1-5
• Dissolving the problems in Complex Adaptive Systems, part 1-5
• The continuation of filling in the Prefilled Problem Picture Analysis Map, part 1-10
• Our ability to solve problems
• Our completed Prefilled Problem Picture Analysis Map
• Dr. Russell Ackoff’s list of antisystemic (sub-optimising) methods, part 1-8
• How to boost your organisational problem-solving ability, part 1-9
• The first trembling steps towards Our Method, part 1-5
• The importance of having the same vocabulary, part 1-4
• Transforming your organisation with common sense, part 1-6
• The pillars of Lean thinking, values and principles, part 1-3
• Are you stuck in a rabbit hole series

*the new thinking and practice is deduced transdisciplinary as well, with input from many different domains and disciplines; hardware, software, project management, computer science, complexity, non-complexity, chaos, programming, testing, verification, validation, architecture, system responsibility, uncertainty, engineering, human science, building houses, statistics, traditional analyses to find the root cause(s) (originated from a Clear context, i.e., manufacturing), silo organisations, traditional waterfall way of working, Lean Production, Lean Product Development, Agile software development, Value Stream Mapping, Flow Efficiency, Resource Efficiency, history, and many, many more domains and disciplines, within the fields of human science, natural science, mathematics, logic, complexity theory, etc. As Dr. Russell Ackoff put it [6]: “Proving the obvious thing. That changes in the field are never produced by experts. But, from outsiders, looking at the field.”. And since this is about transdisciplinarity********, we need to look at many fields at the same time. This to be able to make new way of working, accomplished by doing a new systems design that takes all the different fields into account.

***one definition of a system is from English Oxford living dictionaries [4];
“a set of principles according to which something is done”

****a branch of study which deals with people or their actions, including the human sciences [7] and the humanities [8], as contrasted with the natural sciences or physical sciences.

*****Since the principles take our evolutionary prerequisites into account, the principles to a great extent are “evolutionary principles”, that all human systems need to follow in order to flourish. From human science we already have the magic numbers 5, 15 and 150, Chinese whispers, etc., which already forms our organisations.

******really for any human CAS (will be elaborated on in later blog posts)

*******since root causes give symptoms, that will give more symptoms, etc., the Prefilled Problem Picture Analysis Map can of course never be fully completed, instead the important part is to fill it with the most common symptoms found in our organisations, and we for sure will find all the root causes.

********there is not really a proper word for someone that reduces transdisciplinary complexity/ complicatedness, maybe a systems designer is the best one, since a systems design is needed for all development of new systems; hardware, software, buildings, bridges, etc. I.e., someone that makes an architecture artifact with components and their I/F and needed interactions, where all functional and non-functional requirements on the whole have been taken into account and been divided to the different components of the architecture, recursively, level by level. Generalist or generalising specialist is too vague, since they are more like allrounders, having T-competence, are multi-talented or are multidisciplinary in their knowledge of the already existing components in the current architecture. Because, even if you as a craftsman can build a whole house from an architecture artifact, does not mean that you can systems design a house where the result is the drawing (architecture artifact) of the house. Same goes for someone working in Lean production, since even if persons can work in every process in the whole plant, which means able to mount the car by themselves, does not mean that they can make a systems design of a car. And finally, the same goes also for someone in an agile team. Since even though the person knows every task inside the agile team, meaning awesome T-competence, does not mean that the person knows how to systems design the whole software system, resulting in an architecture artifact.

References:

[1] The Deming Institute. Quotes by Dr. Deming. Link copied 2019-08-07.
https://quotes.deming.org/authors/W._Edwards_Deming/quote/10091

[2] Human science. Wikipedia. Link copied 2019-02-07.
https://en.wikipedia.org/wiki/Human_science

[3] Ackoff, Russell Lincoln. “Systems Thinking Speech by Dr. Russell Ackoff”. At 59.30 min; solving vs dissolving. Link copied 2018-08-23.
https://www.youtube.com/watch?v=EbLh7rZ3rhU

[4] English Oxford living dictionaries, definition #2. Link copied 2018-11-07:
https://en.oxforddictionaries.com/definition/system

[5] Snowden, Dave. Blog post. Link copied 2018-12-14.
https://cognitive-edge.com/blog/knowledge-economy/

[6] Ackoff, Russell Lincoln. Presentation film, at 29.38 min.
Link copied 2018-11-21.
Systems Thinking Speech by Dr. Russell Ackoff

[7] Social science. Wikipedia. Link copied 2019-02-07.
https://simple.wikipedia.org/wiki/Social_sciences

[8] Humanities. Wikipedia. Link copied 2019-02-07.
https://simple.wikipedia.org/wiki/Humanities