cynefin-framework Featured image

It's complicated, or maybe complex? Make better decisions with the Cynefin framework!

Companies are confronted with an increasingly complex world. Agile methods and practices, which have their origins in the world of software development, are also gaining popularity in business and management.

Companies find it difficult to deal with complexity: on the one hand, agile methods do not seem to create sufficient flexibility. In other cases, the same methods generate more overhead than added value. How can this be explained?

 

The Cynefin framework helps to understand this paradox. The Cynefin Framework [kə'nɛvɪn] is a so-called Sense-Making Framework, which management consultant and former IBM employee Dave Snowden has been developing together with his colleagues since the 1990s. It is still used and further developed in his consulting work today. Sense-making means correctly understanding and assessing the current situation in order to be able to act appropriately.

 

The Cynefin framework can be used in various ways. Typically, the procedure is as follows: Let's assume you are confronted with a specific problem. According to the Cynefin framework, how this problem should be approached depends largely on the nature of the problem, i.e. on the understanding and assessment you have gained in relation to the problem. It is important that the context and the granularity of the individual aspects are clearly defined when analyzing the problem. Depending on the type of problem, it must be assigned to one of the five domains defined in the Dynefin framework:

cynefin-framework
Source: https://thecynefin.co/about-us/about-cynefin-framework/

Each domain describes a process model suitable for the problem with associated methods and practices.

The first step is to determine what type of problem we are dealing with - we are therefore in the "Confused" domain (in the middle of the diagram). In this respect, this domain is a special case: the aim is to determine what type of problem it is and thus assign the individual aspects to the appropriate domain.

 

In the following, I present the domains of the Cynefin framework in detail.

 

The Clear domain - the solution is obvious

We are in the Clear domain when the solution to a problem is obvious to someone with the corresponding instructions. It is an ordered system in which cause and effect can be clearly predicted.

Concrete example: Every company has regulations and fixed processes that must be adhered to. Think, for example, of the process for travel expense accounting or the break regulations in your own company. In both cases, there are (usually) clear rules and procedures that offer hardly any room for interpretation and, in principle, cover all conceivable corner cases.

A second example relates to the question: Which side of the road do I drive on?

 

The basic process model in this domain is explained on the basis of this question:

  1. Scythe: Which country am I in? In Germany.
  2. Categorize: Germany is one of the countries where people drive on the right-hand side of the road.
  3. Respond: I drive on the right-hand side of the road.

The conditions or rules (the Cynefin framework speaks of constraints) are therefore fixed and it is the one always suitable Best Practice is used. In the example above, the constraints are defined by the Highway Code and the best practice is to drive on the right-hand side of the road.

 

The Complicated domain - An expert is needed

If we are in the Complicated domain, we need an expert to solve a problem. The expert can either solve the problem directly or may need a little more time to analyze the problem in depth and develop a suitable solution.

Concrete example: Imagine you want to introduce a new IT system in your company and still have legal questions to clarify - then contact a lawyer (if you are not one yourself) to clarify these questions.

The basic approach in this domain is therefore:

  1. Scythe: Recording information about the problem.
  2. Analysis: Analysis of the cause of the problem (by yourself or other experts you consult).
  3. Respond: Elimination of the problem or implementation of the solution.

Cynefin speaks of Governing Constraintsframework conditions within which the expert operates and Good Practice is used. What is the difference between good practice and best practice? With best practice, there is the a suitable wayGood Practice has different suitable practices, depending on the specific Variation of the problem. In many companies, supposed best practices are developed in the context of problems in the Complicated domain and compliance with them is demanded.

Just like the Clear domain, the Complicated domain also describes the "ordered" systems. This means that there is also a linear and very direct relationship between cause and effect. In contrast to the Clear domain, this correlation or determinism is not apparent to everyone, but only to experts.

Properties of systems

Source: own presentation

The Complex domain - too complex for a solution?

The Complex domain is characterized by the fact that although it is clear that many aspects interact in a system, the number and interdependence of these aspects is so extensive that it is technically impossible or simply uneconomical (within a reasonable time frame) to arrive at a solution through an analysis. It is known that a deterministic exists, but this is either too complex to be fully captured, or a certain action changes the deterministic in a way that cannot necessarily be predicted. A further heuristic is that information gathered to date on the problem supports various hypotheses, some of which conflict with each other.

Complex issues arise, for example, when considering globalized markets. If we look at the interrelationships, dependencies and connections in globalized logistics as an example, it is clear that these are diverse and interdependent. They cannot be fully identified with reasonable effort. The complexity is simply too high. Any change to the system means that the impact on the overall system cannot be clearly predicted. The actual collapse of global logistics chains in the wake of the coronavirus pandemic is a current example of this. Too many actors have made individual changes to the system (by changing their behavior) with the result that a global logistics system that was functioning until the outbreak of the corona pandemic has collapsed because the individual actors could not foresee the effects of their actions on the overall system.

But people are also complex beings. You realize this at the latest when urgently needed change processes in the age of digital transformation are ground down by culture, values and attitudes that have grown over decades.

In the world of the complex, it helps to formulate hypotheses that are investigated by means of experiments. If carried out correctly, this procedure is both goal-oriented and economical. Several experiments should be carried out in parallel. This is because conducting one experiment already changes the problem space, often to the detriment of finding a solution. It often leads to predetermination of possibly suboptimal solutions. The experiments should "safe-to-fail" This means that if the experiment (action) does not have the desired outcome, this should not lead to a catastrophe. If, for example, a newly launched product of a company does not have the desired success, this should not drive the company to ruin.

The basic approach in this domain is therefore:

  1. Sample: Carrying out several "safe-to-fail" experiments (in parallel).
  2. Scythe: Determination of the results of the experiments.
  3. Respond: Evaluation of the results and decision on how to proceed.

How do you arrive at the hypotheses? This is where the experts, who are very familiar with the problem space, come into play again. Unlike in the Complicated domain, you can use the Experts They cannot be trusted to find the right solution. Hypotheses can also turn out to be wrong. But you can trust the experts to reasonable hypotheses so that you don't have to wander aimlessly around the solution space. Scientists used this approach during the coronavirus pandemic, as it was a complex problem. Individual measures were implemented and tested for their effectiveness. As a result, experts learned more about the coronavirus, even if they did not fully understand it at first. They were sharply criticized from many sides for this approach and their expert status was denied. The reason for this was the assumption that the coronavirus pandemic is a complicated problem, i.e. that the scientists, as experts, should know how to get the pandemic under control quickly.

 

The domain of chaos - nothing fits together anymore

The chaos domain describes a state in which there is complete uncertainty about the relationships and causalities between events.

In most cases, you slip into this state unintentionally.

In the context of a company, it could be a competitor that unexpectedly disrupts the market with a new innovative product, i.e. shakes a traditional business model to its foundations. For example, the integration of a flashlight function into the mobile operating systems for smartphones made the majority of the then popular flashlight apps superfluous. In this example, the manufacturer of the mobile operating system acted as a direct competitor to the flashlight app manufacturers and effectively took away their business basis, as a dedicated app to control the LED light on the smartphone was no longer necessary.

The first step here is to stabilize the system ("stop the bleeding"). To this end, initial constraints are introduced with the aim of stabilizing individual aspects of the chaotic system (by transferring them to a more orderly state). In practice, crisis management is the recommended management approach.

It should also be mentioned that it is also possible to deliberately put part of a system (e.g. a company) into a chaotic state. In the context of Cynefin, this is referred to as a "shallow dive into chaos", figuratively: you go into the sea but stay close to the beach so that your feet only get wet up to your knees and you don't drown in the water. In concrete terms, this can be done by forming a project team in which the project members are released from their other duties in the company and can devote all their energy to developing an innovative concept or product.

The basic approach in this domain:

  1. Scythe: Perceiving the crisis situation.
  2. Act: Stabilization of the system.
  3. Respond: Transferring the system to a state (usually in the Complex domain) in which further steps can then be taken to solve the problem and where lessons can be learned from the situation so that similar situations do not lead to chaos in the future.

Complacency can also lead to chaos. When a disruptive product from a competitor is completely underestimated by the current market leader. Just think of the reaction of Nokia, the market leader in the cell phone business at the time, after Apple introduced the iPhone. Nokia hardly feared Apple and confidently stated "we have a year's head start" (Source: https://www.spiegel.de/netzwelt/mobil/nokia-reaktion-auf-apples-iphone-wir-haben-ein-jahr-vorsprung-a-458742.html)

Dynamic Cynefin - Dynamic instead of static

This has already been mentioned in the description of the Chaos domain: In the Cynefin framework, a problem is not statically assigned to a domain. Cynefin is a dynamic framework in the sense that situations can evolve and thus move between domains.
The examples above show this dynamic. A chaotic situation can be transformed into a complex situation through stabilization. It has also become clear that there are situations in which everything seems clear and yet you very quickly find yourself in a chaotic situation ("We have a year's head start"). Under certain circumstances, it is also possible to deliberately create a chaotic situation, for example to enable fundamental innovations that lie outside the set framework.

 

Conclusion - There is no single solution to problems

As much as we strive for it - The one-size fits all solution does not exist - An agile approach is not the right approach for every conceivable problem, just as the classic waterfall is not. When we are confronted with a problem, the first step should be to work out which domain the problem or individual aspects of the problem fall into and only then select the appropriate approach (including practices and methods) for finding a solution. This applies to issues that affect the entire company as well as issues that you are confronted with as an employee in the project. Even if it requires some practice, give it a try - you'll find it's worth it!

 

Co-author: Matthias Sekinger

 

Learn more about software development

Zdravko Lucic

About ME

Zdravko Lucic has a degree in computer science. He has been working for doubleSlash as Head of Architecture since 2009. As a senior solution architect and project manager, he has worked on numerous projects (especially at BMW AG) his extensive know-how in the design of (Enterprise) IT architectures has proven itself.

All contributions from Zdravko Lucic

Learn more

Further information on our website and in our newsletter

Arrow up