The wrap-up of the System Collaboration Blog Book

Welcome to the wrap-up blog post of the System Collaboration Blog Book, its last blog post!

If you have read all the blog posts in this blog book, I need to congratulate you. Your organisation will have great benefits of your, by this time, big understanding of what is needed in order to achieve true system collaboration for your organisation, doing changes and a transformation possible that will make your organisation flourish.

If this is the first blog post in this blog book you read, don’t worry, just read below and you will soon know the best way for yourself to digest the blog book.

This wrap-up blog post is divided into two parts, a conclusion of the whole blog book and a summary with a reading proposal how to best digest the 100+ blog posts. The blog posts are for you that want to understand the details, examples and consequences of the conclusion. Especially the consequences make it very clear that many organisations and/or their way of working have built-in organisational problems. To read the whole blog book can be of big importance, not because there is some rocket science in the details (rather the opposite), but because it is about the following:

Without changing our pattern of thought, we will not be able to solve the problems we created with our current patterns of thought.

  • – Albert Einstein

This is really what this blog book is all about, a totally different way of thinking in order to very easy get rid of wicked and intractable problems in our organisations, but where the change of current patterns of thought is the hard part. It is about what Dr. Russell Ackoff called Dissolution of Problems [1], which means to change a system or its environment in order to solve the system’s root causes, and by this indirectly dissolve the problems. Ackoff understood already in the early 1990s that many organisational problems could only be dissolved, but his track has not been continued on in the complexity theory since then. Why dissolution of problems is the only possible way forward to get rid of organisational problems, is shown in the conclusion below and with details and examples in this entire System Collaboration blog book and will be referred to as Organisational problem-solving.

Less important is that we can also show how to build an organisation from scratch, since the root causes of course are connected (root causes are the negated principles) to our total organisation definition with its principles, needed to make any organisation awesome. Why is that less important you think, since that sounds really neat? The reason is that with organisational problem-solving, we can prove that there is no short-cut method or framework, that can fix an organisation’s problems. Because, without asking for the problems in an organisation, the root causes cannot be found, which imply that these methods and frameworks try the impossible of solving symptoms. And if they could solve the root causes, they had if we have some second thought, for sure showed that instead of guessing. Because, so far, there has been no commercialized method or framework actually performing well*, since they are not solving the root causes. This was brought up by Ackoff already in the early 1990s when he talked about the non-working manager’s panaceas [2], which of course is connected to his Dissolution of Problems, in order to act systemically (and not only talk, like the panaceas do). Further down, it will be shown why Best practice doesn’t work, where Best practice is closely related to Ackoff’s panaceas. A summary of Ackoff’s thinking is:

A method needs to be built on theory from science and not speculation. If the author of the method cannot show why it is working by referring to valid principles, then it is an antisystemic panacea. Don’t use it.

Apart from this, another way for panacea peddlers to try to convince the world about a new fancy method is by using counterfactual conditions, CFs. An example of a CFs is:

If A had happened – which A did not – then B had happened.

which is obviously a false sentence, since A did never happen, which means we cannot know if B had happened. But, of course panacea peddlers, do not write the sentence in this rather clear way, no, they are treacherously mixing and tweaking until it is hard to see through. And if someone is questioning the short-coming, they will often be ridiculed, one of the famous master suppression techniques, or pointed out as negative to this new fancy thing. Finally, people will sadly give up, which is understandable since CFs are like trying to solve symptoms, which is the area where panacea peddlers are in their full flow, which is not a flow for adding value to any organisation.

But, with Organisational problem-solving, organisations can think themselves and get rid of intellectual con men or panacea peddlers, two different ways two state it, as Ackoff put it.

Organisational problem-solving has two important parts, organisations and problem-solving. Before we dig into these two parts, we need to have a common vocabulary with the same interpretations of important words, especially for the problem-solving part. A common vocabulary within an organisation, is a vital principle for any organisation with more than one person. This to have a decent and of course correct communication, in order to achieve the necessary interactions between the people within the organisation. Of course, this also includes not only the employees, but also customers, partners, consultants, etc. If we do not have a common vocabulary, we will have difficulties to even agree that we have a common problem, especially a systemic organisational problem effecting many parts of the organisation in different ways.

Here are some definitions of some important words in order to understand Organisational problem-solving, with the detailed explanation within the brackets, that are the references to well-known dictionaries:

  • Principle [3] – a comprehensive and fundamental law, doctrine, or assumption
  • Cohesive [4] – united and working together effectively
    (cohesion – (of objects) the state of sticking together, or (of people) being in close agreement and working well together or
    the act or state of sticking together tightly or
    the action or fact of forming a united whole.)
  • Coherent [5] – having its parts related in an organized and reasonable way
    (coherence – the situation when the parts of something fit together in a natural or reasonable way or
    systematic or logical connection or consistency or
    the quality of being logical and consistent)
  • Analysis [6] – detailed investigation
  • Synthesis [7] – the composition or combination of parts or elements so as to form a whole
  • Negate [8] – make (a clause, sentence, or proposition) negative in meaning
  • System [9] – A system is a number of components (parts of the system) that work together for a common goal (/purpose)***
  • System [10] – a set of principles or procedures according to which something is done
  • Organization [11] – an organized group of people with a particular purpose, such as a business or government department.
    Note! All organisations are complex adaptive systems and hopefully successfully synthesised by following organisational principles (see System [10]) to a cohesive**** (like the actual interactions and interdependencies between the parts) and coherent**** (like the structure of all the parts) whole.
  • Sub-optimization [12] – a situation in which a business is not as successful as it could be because one part or department works only on its own or only for its own success
    – can also be called anti-systemic
  • Context dependent [13] – depending on context
  • Context independent – not depending on context, context-free
  • Problem [14] – something that causes difficulty or that is hard to deal with
  • Narrative [15] – a way of presenting or understanding a situation or series of events that reflects and promotes a particular point of view or set of values

And as you can see for the definition of problem, it can of course mean many different things. A problem can belong to the activities we are doing when we are building our products and services, the WHAT, but also the reactive activities we need to do if we have made something wrong in our products and services. But of course, problems can also belong to our work we are doing to achieve our products, the HOW, which means that we also can have organisational problems. So, we need to start to sort these different meanings out, which is very very important, as you soon will understand.

Art Smalley, a Toyota Production System expert, author and former Toyota employee, states in his recent book “Four types of problems” [16], that problems can be reactive or proactive. The reactive ones mean that the problems require reactiveness in abnormal conditions, which means that the problems are caused (by ourselves), having root causes that we need to solve. Problems in normal conditions means proactiveness if we want to go to next level to become better or make a new product, incrementally or by brand new innovations, where Smalley describes these as created problems.

This dividing into caused and created problems has the right granularity level, since it does not state anything about context*****, neither regarding WHAT we are doing nor HOW we are doing it. In his book, Smalley continues to divide the caused and created problems further, but then context come into the picture. And context is king, Dave Snowden repeatedly states, where we have big difference regarding the repetitive manufacturing on one side (WHAT (always simple) equal to HOW) and non-repetitive product development on the other side (WHAT not equal to HOW). So, we leave context out of the picture since we want to be able to handle any problem. But, this first context-free division of problems into caused and created ones, that Smalley calls reactive and proactive, is extremely important, because they are very very different regarding how to solve the problems. To not mix up caused from created, we will from now on call the latter one non-caused.

If we use Dave Snowden’s well-renowned Cynefin™ Framework, the solution to a non-caused problem, the WHAT (for example any activity when we are designing or manufacturing a product), can “easily” be mapped into one of the domains in the Cynefin™ Framework, when we use it as a categorisation model; do we have the knowledge to do it (obvious/simple), can we do some prototypes and get guidance from our experts (complicated), or do we need to explore because we do not have the knowledge yet (complex).

The caused problems on the other hand have cause(s), meaning they are only symptoms of something deeper rooted. And as we know, symptoms cannot be solved, only their root causes, and root causes as explained throughout this blog book are the negated principles, further explained in the introduction blog post. And since principles are universal like mathematics, physics, logic, etc., meaning that they are valid for any context, organisational root causes are of course universal too, since there is only a negation done as well. Which with some further logic also gives that all symptoms are universal too, valid for any organisation (or product, etc.), which is the reason for the possibility to make a Prefilled Root Cause Analysis Map. This means that we cannot put caused problems or their root cause(s) directly in any of the general domains, and since it is not a crisis, not in the Chaotic domain either. But, the Cynefin™ Framework also has another domain, the domain of disorder. And one sub-domain of disorder is inauthentic disorder, where we will be as long as we do not know in which domain the solution(s) to our problem’s root cause(s) are. So, for caused problems, we always need to ask multiple why? on them in order to finally reach their root cause(s), since then and only then, we can do WHAT (an activity) to solve the root cause. Remember that only this WHAT, the solution to the root cause, is context dependent (can be placed in a domain in the Cynefin framework), not the actual universal root cause. Finding the organisational problems can easily be done in a workshop or similar by collecting the narratives (I use the word narrative, many times used in the theory of complex adaptive systems, in order to have a common vocabulary) of the organisation, the good ones, but especially the problematic ones so we can find their root cause(s). If a narrative is presented as a series of events, we need to ask why? on every event, to be sure that they are not improperly connected (which is a common mistake) and continue until we find the root causes. And preferably these narratives are written down individually; an individual “yellow notes session” for 10-15 minutes will do the job perfectly, not only to make all voices to be heard, but also to avoid bias and that the facilitator is influencing the result. Then it is just to start to ask why? on every event of the problematic narrative to connect a lot of them and also to find the universal root cause(s), our negated principles. After that we continue to find the (often multiple) WHAT on every root cause in order to solve them for this context.

Do not fall into the temptation to categorise the organisational problems/symptoms found into organisational units like units, departments, silos, or into other slices of the organisation like quality, leadership, virtual structures on different levels, or as in an Ichikawa (fishbone) diagram; People, Process, Tools, Program and Environment, etc.. The reason is that the root causes to organisational problems/symptoms are in many cases common to many slices, and will therefore affect many slices of the organisation. So, any try to categorise the problems/symptoms, will make people think that the solution is to be found in the same frame as where the problems/symptoms were found. And framing the solution, no matter what kind of organisational slice it is, gives sub-optimization per se.

Once again remember that there is no “one size fits all” way of working, meaning that we neither can copy another organisation’s recipe, nor use the same recipe within the different contexts of our own organisation. Once again; context is king, as Dave Snowden puts it. The reason we cannot copy another companies recipe, can be proved with these picture, same symptom different root causes:


A method claiming “one size fits all”, is normally pointing at common organisational symptoms on a very high level far away from the root causes, meaning the methods do not have a clue about organisational root causes. The picture above shows that the three different companies (A, B and C) can have different root causes to the same high-level symptoms that a method claims to solve. So, when company B, tries to copy company A’s method that successfully solved all the root causes for company A, the fail is inevitable with no progress at all, since no one of company B’s root causes are solved when using the copied method from company A. When company C, with extreme problems, copies company A’s method, company C becomes a little better, but probably not much, since many root causes still remain. Added can also be that if the method is introduced in the organisation together with other organisational changes that actually are solving some root causes, the result can be better than above, but once again only by luck, since trying to fix symptoms are impossible. Remember that the author of the method has no clue about organisational root causes at all, otherwise that for sure had been clearly stated. This is the problem with all commercialised methods so far, no one talks about root causes. Here below is an easy example of the same companies as above, with a picture showing the many different root causes to queues, here is the pdf file, queues of planned activities different root causes.

Many of the caused problems are normally referred to as wicked problems, or intractable problems as Dave Snowden prefers to call them. And since caused problems are unsolvable symptoms, this means that we can directly neither do safe-to-fail experiments with multiple, oblique or contrary experiments, nor use set-based design, nor focus on extending the problem definitions phase (to avoid premature convergence; note that not even an eternal extension can solve a symptom, meaning indirectly that the convergence is premature anyway ;-)), nor situational mapping to nudge people in the right directions, nor change the constraint structure, etc. And since symptoms are unsolvable, they are also uncategorizable (or non-contextual, i.e. meaning also that no one can be the owner, as Dr. Ackoff stated it) and this indirectly means that we do not know what method to use; we need to find the root cause(s) first to be able to categorise and choose method. And all symptoms together definitely give a mess, a system of problems, as Ackoff would have put it. This also means that symptoms for sure will stand the wicked problem characterisation test******.

Trying to categorise lead us to a catch with both Smalley’s and Snowden’s thinking, since they go directly to categorisation of the problems, without analysing if the problem is caused or non-caused. And a caused problem as we have seen above, can never be categorised, since it is only an unsolvable symptom that not even rocket science can solve. Cynefin™ Framework’s inauthentic disorder is of course a good start because we cannot categorise a caused problem, but without asking why? on it (as we need as stated above), we can also never find its root cause(s), meaning we can never categorise it. When we instead, by asking multiple why?, finally find the root cause(s) to our caused problem, their solutions on the other hand are simply only activities that need to be solved. This means that the solutions to the universal root causes can be complex, complicated or obvious/simple ones and can be put in one of the general domains of the Cynefin™ Framework, in the same way as for non-caused problems.

But we still have one thing we first of all need to do when we encounter a problem, even if it is normally easy to understand. We need to be able to distinguish if it is a caused or non-caused problem. Fortunately, this is simply to ask why? we have the problem. If we cannot find any answer to our why?, then it is just to solve it since it is a non-caused problem, i.e. do the what? to do according to if it is simple, complicated or complex.

After we now have defined the word problem properly, it is time for a dive into the word problem-solving in Organisational problem-solving. Here we will use the traditional root cause analysis by asking why? as we already stated above, which has been used by Toyota, or the Toyoda family to be formally correct, for more than a century.

The visual problems we can see in our organisations are always symptoms, and symptoms means that our visual problems are caused problems according to above, caused by ourselves. This should be no surprise since we made the organisation ourselves, so if it does not work as expected, there is no one other to blame. Caused problems means that we need to ask multiple why? every time we find a symptom, and we cannot stop until we find the root cause(s) to our visual problems. Since only root causes can be solved, a solved root cause is the truth. This also means that if we try to solve symptoms directly, that means indirectly a “lie”, since symptoms cannot be solved. Most probably, the intention of people that convince us that their solution of a problem (symptom) is correct, are (mostly) sincere, but even if they are innocent, the solution is still impossible and therefore a “lie”. In Swedish the expression “killgissa” (literal translation to English is “man guessing” (mansplaining is different)) [17] comes to one’s mind, which means that we are talking about things we actually do not know if they are correct or not. People that are “man guessing” seldom have a second thought or critical thinking, the answer comes to fast and they are very convincing. This means that solving root causes is a Walk in the Park, while solving symptoms with a method or framework (panaceas according to Ackoff) is a Walk in the Dark, since it is obviously totally out of Control trying to do the impossible. This is the reason why Ackoff talked about panacea peddlers. Here is a picture describing symptoms, root causes and their relation, and here is the .pdf file, symptoms and root causes:

If we anyway try to solve symptoms, more intractable symptoms will appear, at any time (can also be years later) and anywhere in our organisation. Especially unsolved root causes that generate symptoms over the whole organisation are really nasty if they remain unsolved for a long time, due to people trying to solve the symptoms. Not to mention all time our people are wasting when they are trying to solve symptoms, and most of the time also the same symptoms, but at different places in the organisation. Much ado about nothing.

Sometimes though, we need to take care about people that are stressed or having lost their power, or in worst case are burned-out, which is WHAT to do, and is of course important, even though it is actually not solving the root cause. Wiping up the oil under the car is another WHAT to do, but is of course not solving the actual problem with the leaking oil from the motor.

Here is an example of an organisational root cause analysis done, where the smaller boxes are symptoms (some boxes are root causes that are finally found later in the root cause analysis). This is to show how easy it is to have a Walk in the Dark, not knowing what are symptoms or root causes, not to mention all people’s time putting actions on the different boxes. Here is the .pdf file, problem overview.

But, when starting to ask why, as in this picture below, we start to understand on which boxes where we shall not put our power, since that is totally meaningless and only a waste of time, since they are only symptoms. It looks like this, the .pdf file is here problem overview – with why:


The arrows point finally at the root causes. If we add some colours to the boxes it would look like this, with the .pdf file here problem overview – with colours:

The white boxes above are facts, meaning that you need to accept it, for example when you have customer issues that need to be looked into immediately, even though it is interrupting the flow in the team’s sprint.

Note that every symptom and root cause are context independent. It is not until we ask what to do on our root causes, it gets context dependent, since we then are trying to solve the root causes in a certain organisation’s context. This means that anyone without knowing the organisation’s context can help doing an objective investigation of an organisation’s problems. So, it is not until we actually are solving the root causes that organisational knowledge is needed, even though guidance and support most probably is possible, due to the similarity between the solutions.

An organisational root cause and the found Visual problem (symptom) can also be separated in time, in fact by several years. No measurement whatsoever can understand or solve these kinds of problems. Below is from a root cause analysis done back in 2010 at a big Swedish telco. From the problem found in production to the root cause at product management, the chain is 13 why:s long, and it took 1,5 year from the root cause until the problem appeared. And here is the .pdf file, 13 why asked.

But, to have some problems in the organisation, why bother? We humans are adaptive, so we will get some results anyway, right! Yes, we are, but the thing is that unsolved problems do not make us awesome and also give more problems, and at the same time the market is changing. Here is The Wheel of Curse, with .pdf file here, the wheel of curse:

And with the market getting faster and more uncertain for every year the last decades, the wheel spins faster and faster, making it harder and harder to escape from it, due to less and less time to fix the organisational problems. Everybody in the organisation get more and more busy, and the organisation starts to look like a fire brigade instead. And if our competitors understand how to solve their organisational problems we are in very deep trouble.

Bad flow in the wheel above is only one of the results when having organisational problems. Other purposes of the organisation, still from a universal, context independent view, is for example; right product, fast time to market (actually related to flow), right product cost, right development cost, right quality, healthy employees, etc. If we add these to our Wheel of Curse, we can see that all the organisational problems make our organisation go in the wrong direction. Here as a .pdf file the wheel of curse with result:

Unfortunately, it does not stop here. Since root causes can be found far from the original problem, both in place and time, it means that the root cause is easily outside the “problem owner’s” area of responsibility. This means that the last symptom that is inside the “problem “owner’s” area of responsibility, erroneously becomes the root cause. This is a common consultant trick, to frame the problem so it looks like the root cause has been found within the frame: But, in turn this instead means that the root cause will never be found, which is a clear sub-optimisation trying to solve the symptom within the frame’s boundary. And trying to fix unsolvable symptoms will, yes you are right, give us more treacherous symptoms. And we will not know where they will show up, or when. The unsolved root causes of today’s organisations can also be seen in job advertisements, where the applicants need to; work well under pressure, have eyes in the neck, be able to juggle with many balls, think out of the box, turn around stones outside reach, etc.  We add consequences to our picture of symptoms and root causes and here as a .pdf file, consequences.

If we add that to our Wheel of Curse, it will finally look like this showing some of the endless consequences that easily occur, making the organisation coming very far away from achieving its different purposes, here as a .pdf file the wheel of curse with consequences:

And here is when Ackoff’s panacea peddlers enters the arena, telling the organisation that they have the answers to all the problems, showing power point slides that even the peddlers believe themselves. I mean, who does not want the following results; better flow optimisation, the right product, more innovations, less cost, etc.? Everybody does, so when you are questioning the logic behind (since they are trying to solve symptoms) to get the result everybody wants, you are easily treated like a negative person, since you have not been swept away by the sweet talk. This is exactly what Mats Alvesson and Andre’ Spicer write about in their book “The Stupidity Paradox: The Power and Pitfalls of Functional Stupidity at Work” [19]. The impossible or even stupid things have become a non-questioned fact, since peoples’ critical thinking and reflexion seem to have been wiped away. But still, trying to solve symptoms are impossible, meaning that not even rocket science can help us here. That is why we put the none-truth like this instead; “Lie”, because it is impossible to see through that the solution presented isn’t a solution, that it is in fact only man guessing. But it is still not the truth, even though it is most of the times not deliberately done, and since it will not solve anything on the wholeness, it is only sub-optimising.

A harder nut to crack, is when some parts of a method or framework is really solving some root causes, but where other parts of it instead increase the problems totally within the organisation. That is why it is so important to ask the following question when we add something new to our organisation; what root causes are solved if we add this? If we cannot see any root causes solved, we need to be cautious, since it instead most probably will add new problems we did not have before in the organisation.

Beware also of measurements, since many measurements sub-optimise the organisation, since when done on parts, the success of the whole can never be guaranteed. Also, gaming the measurements are very easy. If we for example measure efficiency, we will for sure instead of doing the right product faster, with high risk suddenly do the wrong product faster. Which most probably was not the intention. The only way to make the right product faster is to solve the root causes, and systemic measurements will easily show that. In software product development with Customer Pull, we have complexity and complicatedness within our work, making measurements very tricky. This can be compared with the traditional hardware development projects with Technology Push, having done all the innovation and experimentation before the project started. This meant also that the complicatedness was understood, adding up to some prototypes, but still under control, since output and outcome were pretty much the same.

Now after we have understood the problem-solving part, and why it is needed, we will now examine the word organisational in Organisational problem-solving, which tell us that we need an organisation. And a reminder is needed, to emphasise that every organisation is a (complex adaptive) system, which means that it indirectly will have a system specification or system definition, where the aim for the system is to achieve something, a goal or a purpose. And do not forget that every system is a number of components that work together for a common goal. In our organisations, these components are ourselves and the activities we are trying to solve to achieve the purpose of the organisation. From our definition of organisation in our common vocabulary above, we can make it a little more specific since any organisation will solve activities and will have interdependencies between the activities. We can write it like this below and notice that it is still universal, context independent, which is important since that makes the definition valid for any organisation.

People that interact to solve activities with interdependencies for a particular purpose.

But this definition won’t help any organisations to become awesome. Actually, we will go backwards in time a couple of 100 000 years, since our ancestors know a lot about themselves in groups and communities, as well as about the activities they handled and structures that helped them handle complexity. And the science for the last 100 years has explained the reason why our ancestor’s communities, families, tribes, clans, etc, had their size, as well as that activities can be obvious, complicated or complex and many more things. These babies we cannot throw out with the bathwater, so let us instead dig into them and make a definition of an organisation that take them into account. We start with the activity side, the “hard” side, before we dig into the people side, the “soft” side.

Activities cannot be done randomly; we need to follow certain steps. We can complain and say that development according to waterfall is slow, but anyway, certain steps need to be followed, the tests cannot be done before we have written the code, even though we can write the test before the code is written as in TDD/BDD. For sure we shall also incorporate test knowledge into the loop making testing easier, but still, test needs to be done as the last step.

We also need to understand the complexity of the activity, referring to the non-caused problems (activities). The more complex the faster feedback we need and the more uncertain our predictability will be, a too complex activity may not be solvable in a reasonable time regarding current unknown knowledge. Complicated activities mean that we know that we can solve the activity with the help of experts. Probably we need some prototypes/iterations to get it right and where we get new knowledge after every prototype/iteration. Obvious activities we know exactly how to solve.

The different complexity of the activities, means that we need to have timely Integration Events where we for example integrate, verify and validate our work done so far, to get feedback on the parts, the wholeness and of course also from the customer. Of course, we need to have Built-In quality to as high degree as possible, but we always need to verify and validate the wholeness, since successful verification and validation of each part, does not sum up to a verification and validation of the whole product. Sometimes agile software development tries to skip this last vital step, where especially an erroneously specified system, which can have the most severe errors, never can be found with Built-In quality thinking. Changing the name of the parts of a system from the traditional subsystem or sub-subsystem, to value streams, features and user stories, will not change anything. Built-In quality on the wholeness can never be achieved, and writing a White Paper that states that it is not needed, won’t make the need of verification of the wholeness to vanish just like that. All things done on the parts (optimisations/verifications/ validations, etc.) do still not aggregate to an efficient and effective whole in product development, even though it many times work in manufacturing. Context is always king.

Structure is a leading star for us humans, not only the planning structure, but also the architecture. During mankind, we have also understood that architectures of pyramids, houses, cars, circuit boards, are a good way to handle complexity for us. From Conway’s law [20] we also have that communication structure gives architecture. This means that teams sitting close to each other, not working on parts next to each other in the architecture, have the risk of changing the interfaces in the architecture.

Now over to the “soft” side of the definition of our organisation so far. First of all, we need respect for people on all levels of our organisation. In order to solve the activities within our context, we of course need to have the right specialist competence, commonly referred to as I-shaped competence.

The latest 100 years, the science has shown many different group sizes which we need to follow. We have 5 as the maximum number of people in a Group having the same competence, splitting the same task, to avoid loafing [21]. 15 is the number of trust and sympathy [22] we can have within a group of people, and 150, Dunbar’s number [23], is the maximum number of people that we can remember name and face on.

We have Miller’s number 7+-2 [24], which is the maximum number of things we can keep in our short-term memory. So, when the children play the Chinese Whispers game [25], it is not a surprise that for every Child the story passes, the story changes due to the inability to keep the whole story in the short time memory. And the story does not only get corrupted, it takes also long time for the story to pass from the first child to the last child. All this together gives us that we need to keep our chains of interactions as short as possible, otherwise we lose time and information during the chain. Start up and close down of activities are costly, and the smaller activities, the longer the chain of interactions will be for sure, giving a bad flow of the activities through our organisation. Many small activities also give that our employees will be part of many projects, which for certain will give queues of planned activities to our employees, killing the flow totally. Flat hierarchies, especially for the actual work are therefore key, as well as T-Shaped competences, to reduce the chains of interactions and queues of planned activities, both in length and amount. From this it is also easy to understand Go to Gemba, or Go To the Source, that Toyota, or at least the Toyoda family has done for more than 100 years, to avoid intermediates corrupting and slowing down the information.

Back to structure again, where we can see that the above number for different group sizes give us a line structure, where we have control of the needed different I-competences in the organisation, and a virtual working structure where the actual work is done. This setup gives great flexibility to meet the market changes and problems occurring during the work. We can call it to move people to work in a virtual structure, or move work to people in a virtual structure, it is just a play with words, the importance is that we have a virtual structure giving us flexibility.

The purpose in the definition, sets the way of working, since our organisation will perform very different activities depending on if it is product development or manufacturing, complexity or not.. Purpose is a context independent constraint, it is always present, or context-free as Alicia Juarrero would have put it [27]. Purpose together with shared understanding and goal is what is called positive context-free constraints.

If we sum up the above, we now know how we can make an awesome universal organisation, so we add that knowledge from science to our definition of an organisation and we get the following:

Respected people with a common vocabulary, working full-time in a flat hierarchy of teams founded on the numbers 5, 15 and 150, also in the light of Conway’s law, with the right specialist competence, and understanding the Cynefin™ framework and Conway’s law, that iteratively and in parallel if needed, interact freely and end to end over the whole organisation in as short chains of interactions as possible, giving them the necessary broad competence to also directly take care of organisational problems as well as do continual improvements, and therefore be able to efficiently and effectively solve, by also exploring in close collaboration with the customer and end user to gain new knowledge, activities with interdependencies, fully planned and under control, to be able to build the system product or service, incrementally if possible, always with the appropriate architecture under control and responsibility and always with timely Integration Events with verification and validation depending on context, to get just-in-time feedback, where also the long-term critical line, activities, interdependencies and Integration Events are fully under control, and visualised as well, to achieve the purpose.

Splendid, right. So, for any organisation we build, we need to follow the above organisational definition, built on currently known science, in order to make our organisation both cohesive and coherent in any part of it, as well as on the total of it, to make it awesome.

As you can see there is nothing about, trust, mindset, values or culture. Isn’t that important, you think? Yes, of course it is, but they are the outcome from the interactions between the people within our organisation. It is the same regarding quality that is an outcome from the organisation and is nothing we can wish for, or set a goal for and then try to close the gap to. This means that putting up the cultural values on the walls won’t help. And since the interactions are done between our people, the culture cannot be found inside the walls either. But you think, we can find the culture at the breakfast table, eating strategy for breakfast. Sorry, not even there. It is the absence of organisational changes in a “bad” organisation, that can deteriorate any strategy. If one of the parts in the strategy’s aim is to change the culture, without changing the organisation so that the interactions can change, culture won’t change. Or as Dave Snowden states it; “Just as people think they can render a culture into a set of platitudes in a value statement, when real culture is evolved practice over time, not fully understood and never fully articulated.” [28].
The Hawthorne effect [29], that people change under observation, can give some short-term positive effects for easy tasks, but for complex tasks the effect is negative. That is why too much transparency can hamper innovations, since innovation means experimentation, which means many fails, and no one that may fail wants management to observe that. That is “101 anthropology”, as Snowden would have stated it.

Now we have explored both organisations and problem-solving and it is time to combine them. Because, if we fail to achieve one or more of the sciences and common sense above, an organisation will clearly have big problems, due to that our abilities have limitations. We cannot of course explain exactly what problems an organisation will have, but as you now probably understand the root causes will be the non-fulfilled science already discovered. And due to that our definition of our organisation is context independent, the root causes are the same for any organisation. It is not until an organisation tries to solve its root cause(s), the different solutions, the different WHATs, it gets context dependent, i.e. we are in one of the domains of complex, complicated or obvious.

But, hey there someone may say. In complexity theory there is stated to be no cause and effect, how come we can find root causes in our organisation, our complex adaptive system? Remind from what was stated above that these organisational problems are caused problems, meaning that they are symptoms and impossible to solve and therefore not part of complexity theory. But we can also take it from the following angle. We humans are adaptive to be able to solve different problems (caused or non-caused), but we cannot change our DNA. This means that no matter what system (including organisations) we make, as long as we use components that cannot fulfil the system’s specification, the system can only work as expected if the components can upgrade themselves. Our adaptiveness will still make our “bad” organisation to work, compared to a product with the wrong components that most probably won’t work at all and definitely makes the customer very unhappy. But, an organisation, will still have some, but degraded performance, depending on how many organisational root causes we have unsolved. The misunderstanding is that adaptiveness can make us fixing the limitations within our own DNA, which is impossible. This means that as long as we do not fulfil our organisational definition to the better, i.e. do Ackoff’s dissolution of problems, root causes will remain. Remind also that narratives that is never in real-time either, play an important role in complexity theory, where a narrative of course can be a problem. This means that a narrative in an organisation is something built up over time and is rather constant, same as problem. And as stated before; a common vocabulary is of great importance for solving transdisciplinary and systemic problems, that organisational problems of course are part of. See this series of blog posts for a deep dive into that matter.

Let’s take an example with an organisational problem. A common problem in agile product development is queues of planned activities on the Kanban board within a sprint. Let us examine that thoroughly. We actually start one step before the queues, when we have bad flow through our organisation. Some organisation does not even ask why they have bad flow, and instead start to control more, more governance, more measurements, etc., which will generate even more and more severe problems, since they are acting on a symptom.

One answer on why we have bad flow is queues of planned activities. This is agile’s Achille’s heel, since very seldom why? we have these queues is asked. Instead WIP Limits are put on the different Kanban board columns in order to decrease the number of work and thereby increase the flow. The problem with this is that the queues hide problems, since the activities that cannot be handled have a reason for that. Another common thing is to decrease batch size, i.e. the size of the feature or user story in order to receive faster feedback. But, as you remember, the thing we really need is timely feedback, which depends on the complexity of the activity; obvious, complicated or complex, nothing else. We need to understand that and not decrease the size randomly just because we do not understand what we are doing, which is obviously the root cause to this behaviour.

Since these queues of planned activities are to people, we have both the soft and the hard side of our original definition of organisation, meaning it should be more than one answer to our why questions. One answer is that we don’t have the right T-shape for our people and the other is regarding planning and can be bad planning of the activities or the dependencies between the teams and/or experts etc. A comical part in agile is when there is an activity on a Kanban board column, but no one there to solve it, since agile make fun of the traditional resource optimisation problems. An activity with no people there to handle it, is really bad flow, but good resource optimisation.

Here is a picture describing the above, that also goes into more details regarding the planning and here is the .pdf, symptom example – queues of planned activities with consequences:

For more explanation about the variability chain of symptoms, please see this blog post for a thorough deep dive.
Measurements as in the picture above is many times really contra productive. In the same way as inspections will not make the quality of a product better, the same goes with measurements. When you measure, it is already too late, you cannot get faster or get the right product by having measures, especially not the latter. Instead measures are treacherous since they easily sub-optimise, meaning bad side effects, and/or is easy to game. One example is to measure number of features delivered in a certain amount of time. The risk is then that the features are made shorter and then it will look like that there is a great progress.  And if someone erroneously think that smaller batches are always better since feedback is faster as described above, they think that a better measure and smaller batches is the perfect match. An objective question is then; why didn’t you have a smaller feature size from start? And don’t forget the risk of sub-optimisation when user stories and features repeatedly get smaller, since in product development, reduction and aggregation has never been valid as in production. And will never be neither.

Instead of measures we can follow Toyota thinking, doing continuous problem-solving and Continual improvements on the parts and wholeness, but only measures on the whole factory. They know that any problem-fixing or Continual improvement on the parts/teams or the whole factory, is the one and only way to make Toyota better on the whole factory, so why measure the teams’ efficiency. By measuring on the whole factory, Toyota avoids both gaming and sub-optimisation, where the latter is harder to do in production compared to product development.

If we now start to think of our root causes, we realise that we have a big problem. Our only root causes are limitations within ourselves, or that activities need to be done in a certain order and need that we understand complexity. And we people are the one we are, people. We simply cannot solve the root causes we found, because we cannot change ourselves. And this is exactly what Dr. Russell Ackoff meant when he talked about Dissolution of Problems, we need to change the system (organisation) instead. And as you also realise, change the organisation is exactly what many methods have tried the last 70 years, but no one of the commercial ones has been successful, which Ackoff calls manager’s panaceas as described earlier in this blog post. And as you can see in the example above, there are some organisational hiccups in Agile too. So, what do these methods do wrong. Let’s try to explain it with a picture, here as a .pdf file, new organisation – only synthesis.

As you can see in the picture, no methods deeply analyse an organisation’s problems, and therefore cannot find the organisational root causes. And without finding the root causes, we can only make a new synthesis at random, which is a Walk in the Dark, where we can loop for eternity. This means that the top right box will remain red forever, since we are trying to do the impossible, to solve symptoms. No, we need to do according to the below picture, heading for the root cause(s), the reason for an organisation’s problems. Here as a .pdf file, new organisation – analysis and synthesis.

We instead start with a normal root cause analysis (asking multiple why?), where the thinking is that the system is correct and component(s) wrong, so we can find the root causes to our organisational problems. But, as stated above, the found root causes will make that we people cannot thrive in our own organisation, and the only way to take care about that is to change the system, Ackoff’s Dissolution of Problems.

This means that we make a synthesis only when we first know the root causes, and the synthesis will instead give us a sunny Walk in the Park, which makes the top right box green.

Do not forget that our adaptiveness as humans, makes our organisation a complex adaptive system, which means that we will always get some degraded outcome from even a low-performing organisation with many problems. But, at the same time our adaptiveness can of course never solve our organisational problems (symptoms) because it is impossible to solve symptoms. But, our adaptiveness can neither solve the root causes, since the root causes are limitations within ourselves, so we need to change our organisation. This means that every time our organisations do not fulfil our organisational definition, we have built-in organisational problems (symptoms), that only will get worse if we try to solve the symptoms directly. These organisational problems will for sure give us narratives, which are really easy to grab at any occasion.

We can, as stated before, also build an organisation from scratch, since we have the definition of our organisation. Already now I think you understand that a good organisation will be a true mix of agile product development, Lean product development and the traditional organisations with projects, the first good at the soft people side and the last good at the hard activity side and scaling, and the middle on good at both. And it does not matter if we build the organisation from scratch, or by organisational problem-solving, both are terrific ways to make an awesome organisation.

And as you were promised from start, no rocket science in sight, only this:

Without changing our pattern of thought, we will not be able to solve the problems we created with our current patterns of thought.

– Albert Einstein

Summary with reading proposal
Below is an explanation of the details of this blog book and a Reading proposal how to best attack the parts at your interest.

Apart from the introduction blog book post, the common sense series is the starter, since everybody can relate to common sense. With the explanation of our organisational changes during history, human science and also Toyota (Lean) thinking, our common senses are really backed-up of reasons for the needed change of our organisations through the history, as well as how the limitations of us humans have affected the historical organisational changes. The limitations of our human cognitive ability have become very visible when the organisations try to follow the market of today that is fast, flexible and with products requiring more complexity handling to achieve. A big difference between us humans and (most) other animals is that we can intentionally or mainly subconsciously, in our organisations, violate our own cognitive abilities. This will then give us organisational problems, where this violation is the root to the problems. These problems can therefore only be solved by fulfilling the cognitive abilities again, which Dr. Russell Ackoff called to dissolve problems, even though he only stated that methods were anti-systemic and therefore could not work.

Dissolving problems combined with the principles regarding the limitations of our human cognitive ability are the top insights of this blog book, meaning also that organisational problems are really easy to (dis)solve. This is because the root causes are our negated principles, meaning indirectly that any problem that we do not understand why we have, is complex (organisational or product), since it is only a symptom of the original root cause(s), and it is therefore impossible to directly solve. This also means that all root causes are always very easy to solve, and when we are lacking root causes, we experiment to gain knowledge. But, in our case, we have our set of principles since the needed human science for problem-solving already is there. As soon as we violate one of more of these principles, we will have organisational problems we cannot get rid of, they will remain year after year; no situational mapping, no continuous improvement can help us, since these methods are operating live in the complex domain with a real time organisation where the former do intervention’s, leading to even more unintended consequences that cannot be understood, and the latter are trying to indirectly solve symptoms by experimentation. The only thing that can help is to fulfil the principles, or dissolving the problems.

As already stated, these principles have a strong connection to our common sense, things we already know, like basic understanding. Respect for people is the number one common sense, closely followed by the need to solve our organisational problems. But organisational problem-solving is directly related to Respect for people, because if do not listen and not try to solve the organisational problems our people bring up, we show disrespect indirectly. Problem-solving (Jidoka) is one of the pillars for Toyota, and they know since more than half a century that if they fail taking care about their people’s suggestions to make Toyota even better, they will fail the Respect for people pillar. But problem-solving can never ever be mixed up with Continuous Improvement and doing so for product development instead means that we create a mess for ourselves through sub-optimisation of the parts.

Another insight is that we need a common language on the top level of every discipline, and not some discipline specific language when we mean the same thing. Without this common language on the top level, we can never work transdisciplinary. Of course, we need specific and detailed language when we dig into the respective discipline, but not on the top level.

There are many other insights as well, some more contrary to today’s thinking, than others. For example, unknown unknowns with friends have due to extensive reasoning and logic been reshuffled within the domains of the Cynefin™ Framework. Also, the top insights above that organisational problems will not go away if not the principles are fulfilled, is not what complexity theory is proclaiming. This is since its theories for complex adaptive systems for three decades or more, clearly states that in a complex system there is not any cause and effect chains. The problem with that statement is that it only regards live (real time) systems, not systems with inherent problems from start within the organisation definition (dead system). Here instead, the effect and cause chain (backwards) for organisational problem, by asking why on the effect, easily can be found all the way to the root cause(s). Of course, only backwards to the root causes since we do not know the future. But, most probably we can understand the doomed future with more and more inefficiency and ineffectiveness and unhealthy people (due to our human adaptability to try to get the job done anyway) within the organisation, if the principles are not fulfilled.

The last important insight to mention is the tight connection between resource and flow efficiency. And the term resource efficiency we need to rethink and understand as an efficient use of our resources not just filling their time with work. This means that we need to look if they are adding value, and not only doing administrative stuff, in the same way as we are defining flow efficiency; are the flow units in a queue or are someone working on them. By having the same definition with adding value or not, it is easy to see that they are tightly connected; a queue of activities waiting for people to handle them, or a queue of people waiting for handling activities. Specialisation in product development will always give long queues of activities for the specialists, or many specialists need to handle every activity. Specialisation is not only a major problem in traditional silo organisations, just look at today’s queues of activities on the Kanban boards in Agile development, where the latter queues also are due to tremendous planning problems in Agile development, which is the other root cause to queues of activities, next bad T-shaping (specialisation).

The way forward for your organisation can be found in the Reading proposal tree hierarchy, since you should present the same knowledge as you know have yourself to get an exponential speed-up of the transformation:

The tree hierarchy connects the different series and blog posts with a main track and a deep dive/example track. The .pdf file also has the links to be clicked on to access the respective series and single blog posts directly.

The tree hierarchy has two main tracks and that is finding the principles and finding the root causes, and at the end understand that they are really the same, but found in two completely different ways. The principles are found from co-evolving of organisations and the market and the root causes from the fact that organisational problem-solving with the right granularity have root causes.

Below follow some guidelines on how to achieve the change or transformation, proceeding from Kotter’s 8 steps for change.

Remember that Kotter has built his steps on implementing methods, so there is mainly no focus on what problems an organisation has and asking why the organisational problems exist.

This means that the first step about urgency is not needed in the same way, since by understanding not only that the organisational problems exist, but also how they easily can be solved and that no method or framework is pushed on the employees. That will make the vision and the strategy well connected to the organisational problem-solving and the needed organisational changes, meaning they will be attractive and understandable for all employees. We have achieved a Pull from the employees, instead of a Push of a method we cannot fully explain to them, on them.

Of course, HR also have a big role in these early steps since salary, bonus, knowledge, competence, careers, etc. need to be changed, and to be proactive and explain these changes in advance for the employees, will build trust all over the organisation.

To explain the why is the main focus of the coalition put together for achieving the change. This means that there is also another vital difference compared to Kotter’s steps and that is that this time the coalition is focusing on educating, mentoring and coaching the organisation to understand themselves how to make the change or transformation. The coalition will of course guide the organisation’s different parts how to implement their respective solution in their own contexts, but it is important that they as soon as possible can coach themselves to a great extent. By securing that the whole organisation understands the why, means that they understand themselves what changes to do, meaning that the coalition can stay small. Unfortunately, introductions of many methods and frameworks today, instead requires more coaches due to not taking care about the organisation’s original problems, and in fact introducing more problems. Adding more and more coaches or coordinators at the end of the transformation, should be a warning flag for any organisation.

By just doing their work after the changes, the employees will automatically fulfil the vision, due to the tight connection between the vision, strategy and the actual changes done in the transformation.

Short term wins can be seen directly all over the organisation, since the transformation can be done all over the organisation at once. This is due to that root causes are solved, meaning we know that it will be better, i.e. we have not copied someone else’s method, framework or way of working.

Sustaining the change is also easier, since everybody has understood that organisational problem-solving is vital, it is really common sense. What is important to understand is that we have changed the system by dissolving the problems within it, meaning that the culture will change to the better automatically at the different contexts within the organisation. There is therefore no need to push out (and must not be) values of how people should be. These value statements (on the walls) are also easily gamed by the employees, which means that it will take even longer time, and more people will be employed that learnt the game, until it is understood that it did not work this time either. The new system with its new ways for people to interact will give the new culture automatically over time depending on context, most probably a short time, the easier the context is.

With this organisational problem-solving thinking, there is not many more guidelines that can be given, since every change depends on context. The educators, mentor and coaches secure that the different parts of the organisation understand why the change is needed. And understanding that respect is vital, but also that ignored organisational problems, easily leads to disrespect, and that the organisational problems then are never solved either.

Everything has an end, and so does also this blog book have now when it is finalised after 121 blog posts. But it has been an exciting journey over almost three years 2017-2019 and +5 000 hours of research (full time), not to mention the pre-research done that equals another +10 000 hours of theory, but mainly practice during the Lean Product Development pilot at Ericsson 2011-2016.

I guess I will continue to update the blog book continuously with small changes, probably sometimes also add a new blog post or two, since I still have a lot of unpublished material and answer comments if there are some.

But now, since the research have come to an end, I have more important things to do, since I am starting at a new employment 2019-08-19.

With what?

Transformation of course, so the research is more than appropriate for that :-)!

My final words, summarising this blog book regarding the achievement of flourishing system collaboration for your organisation, is:

There are only sub-optimising methods and frameworks to buy,
and that is a dead-end path,
no matter how convincing con men and panacea peddlers are.

So, you can only help yourself with your organisational problems.

But now you also know that it is actually easy.

And apart from that it is the only way forward, it is also for free.


C u around.


*Toyota(/Lean**) Product Development, is not commercialized, but it is systemical, following our total organisation definition almost perfect.

**since all methods and frameworks in agile product development that is referring to Lean, is actually not (even close) to follow the Toyota principles, the usage of Lean has really been abused. The real Toyota principles take care of the wholeness, the set of principles are systemic, so there is no possibility of cherry picking among the principles, or picking some low hanging fruit. Here is a series of blog posts, going through Toyotas set of principles.

***an example of a system definition for an agriculture system can look like this;
“An agricultural system is an assemblage of components which are united by some form of interaction and interdependence and which operate within a prescribed boundary to achieve a specified agricultural objective on behalf of the beneficiaries of the system. ”

****cohesive and coherent can be seen like this. The line (static) structure is the coherent part of the organisation that keeps the organisation together and the virtual (and flexible) organisation, like a project or another working structure, need to make the interactions between the people cohesive. From this we can understand that in production cohesive and coherent are very similar since the HOW is equal to the WHAT in each process, as well as that the hard part in product development companies is to make the organisation also achieve cohesiveness (same as cohesion), especially at scale.

*****If we try to map these four types of problems into Snowden’s well-renowned Cynefin™ Framework, we will get context difficulties,  And since Smalley’s work is mostly from the manufacturing and process industry context,  which is work mostly put in the Obvious domain, the mapping of the different types of problems into the domains of the Cynefin™ Framework will not be consistent. For example, manufacturing has clear interfaces between the processes, meaning that closing a gap to the process’s standard (due to a caused problem) can be done in isolation for each manufacturing process, after finding the root cause(s). We also have the fact that due to the repetitions, the activity done in the process are equal to the process itself, the WHAT equals the HOW. Every process can be seen as its own isolated discipline, giving that the processes can be aggregated, or the parts can be summed up to the total. But, in product development the teams cannot have clear interfaces between each other. This is because their work is transdisciplinary and the teams are constantly and unpredictably interacting with each other to solve their problems. This means that to close a gap to the standard state (reactiveness due to a caused problem) or even to close the gap to a future ideal state for a single team (with creativeness due to the (self-)created problem) is impossible to achieve in product development, without risking the total performance. Instead any try of making one team better, will give a sub-optimisation on the whole.
Another example is the very big difference between manufacturing and product development regarding variability. In manufacturing we try to remove it, as an increment of the standard, since variability is a big cause to waste. On the other hand, in product development, we need to live with variability, making it impossible sometimes to say what is actually waste. This means that closing the gap for manufacturing is possible since it positively reduces waste, but not within product development, where there instead are high risks of hamper interactions and in the end also innovations.
For the other types of problems in Art’s book, the context difficulties are repeated.

******Thus, wicked problems [26] are also characterised by the following:

  1. The solution depends on how the problem is framed and vice versa (i.e., the problem definition depends on the solution)
  2. Stakeholders have radically different world views and different frames for understanding the problem.
  3. The constraints that the problem is subject to and the resources needed to solve it change over time.
  4. The problem is never solved definitively.

[1] Ackoff, Russell Lincoln. Biography. Link copied 2018-12-15.
The best thing that can be done to a problem is to solve it. False. The best thing that can be done to a problem is to dissolve it, to redesign the entity that has it or its environment so as to eliminate the problem. Such a design incorporates common sense and research, and increases our learning more than trial-and-error or scientific research alone can.

[2] Ackoff, Dr. Russell Lincoln. Speech. “Systems-Based Improvement, Pt 1.”, Lecture given at the College of Business Administration at the University of Cincinnati on May 2, 1995.
The list at 03:30 min, the national surveys at 03:40, and the explanation at 04:48 min. Link copied 2018-10-27.

[3] From Merriam-Webster. Link copied 2020-01-25.

[4] From Cambridge. Link copied 2020-01-12.

[5] From Cambridge. Link copied 2020-01-12.

[6] From Lexico. Powered by Oxford. Link copied 2019-11-24.

[7] From Merriam-Webster. Link copied 2020-01-12.

[8] From Lexico. Powered by Oxford. Link copied 2019-11-24.

[9] Wikipedia (Swedish). Link copied 2019-11-25.

[10] From Lexico. Powered by Oxford. Link copied 2019-11-25.

[11] From Lexico. Powered by Oxford. Link copied 2019-11-25.

[12] From Lexico. Powered by Oxford. Link copied 2019-11-30.

[13] Psykologiguidens psykologilexikon (Swedish). Link copied 2019-11-24.[

[14] From Cambridge Dictionary. Link copied 2020-01-04

[15] From Merriam-Webster Dictionary. Link copied 2020-01-25.

[16] Smalley, Art. Four types of problems: from reactive troubleshooting to creative innovation. Lean Enterprise Institute (2018). ISBN 978-1934109557.

[17] Wiktionary. Killgissa. Scientific research about why it is done in [18].

[18] Science in Swedish. “Why men are man guessing”
Resume: Added testosteron for men in a mathematical test that needed second thoughts, gave higher rate of man guessing (20% more wrong answers).

[19] Alvesson, M, Spicer, A, The Stupidity Paradox: The Power and Pitfalls of Functional Stupidity at Work, IPS Profile books. ISBN: 978-1781255414.

[20] Conway, Melvin. Länk kopierad 2018-09-14.

[21] Ringlemann, Max. Link copied 2018-09-14.

[22] Snowden, Dave. Link to blog post copied 2018-09-14.

[23] Dunbar, Robin. Link copied 2018-09-14.

[24] Miller, George. Länk kopierad 2018-09-14.

[25] Chinese whispers. Link copied 2018-09-14.

[26] Wicked problem. Link copied 2020-01-05

[27] Juarrero, Alicia. Presentation from the Lean WX conference, April 2015.
Constraints that Enable Innovation – Alicia Juarrero on Vimeo

[28] Snowden, Dave. Blog post. Link copied 2021-06-26.
In uncertainty lies resilience – Cognitive Edge (

[29] Snowden, Dave. Blog post. Link copied 2019-06-04.

Leave a Reply