The Cynefin model

Cynefin is a model that aims to help decision-making by allowing us to understand the cause-and-effect relationship that occurs in a given system or context as its agents interact. Created in 1999 by Dave Snowden, the model offers five distinct domains so that we can choose the one most suitable for the system or context in question, and thereby make appropriate decisions (SNOWDEN; BOONE, 2007).

Ordered domains include those systems whose constraints are strong enough for the behavior of their agents to be predictable, so that we can establish the relationship between cause and effect. Ordered domains are divided into Obvious and Complicated. If the constraints are evident and we can directly determine the best decision, then the system belongs to the Obvious domain. If the constraints allow for a choice between options and the best decision can only be determined after an analysis, then the system belongs to the Complicated domain.

Unordered domains, in which there is no apparent immediate relationship between cause and effect, are divided into Complex and Chaotic. In Complex domain systems, the constraints co-evolve along with the system agents in order to enable this evolution. In the Chaotic domain, on the other hand, there are no constraints.

Finally, in the Disorder domain, it’s hard to recognize what we’re dealing with.

In introducing the Cynefin model, my goal is for you to realize that Scrum is suitable for product development contexts. I will then analyze the meaning of each domain defined in the model and relate them to this type of work.

Obvious Domain

This is the domain of best practices, where there is stability and the relationships between cause and effect are evident to everyone, predictable and repeatable. Thus, for any given situation, we must assess its facts (sense) in order to define what kind of situation it is (categorize) and then apply the best-known practice for it (respond). This domain was called “simple” in the original Cynefin model, later modified by its author.

For the type of work that predominantly operates in this domain, we can use knowledge from the past to choose the best approach and thus utilize it to perform the work.

Changing a light bulb, for example, belongs to this domain, since there is a known sequence of actions to be conducted to perform this work. The work of typing the data for the products to be sold in a virtual store also characterizes a context of the Obvious domain.

Complicated Domain

This is the domain of good practices, where the relationship between cause and effect exists, but not everyone can see it. Unlike contexts in the Obvious domain, there may be several viable answers to the same problem and experts may be needed to investigate and choose the one that best applies. Thus, for any given situation, we must assess its facts (sense) to define which of the possible solutions is the most appropriate (analyze) and then apply it (respond).

For the type of work that predominantly operates in this domain, we can conduct sufficient analyses of the problems and choose, among the possible solutions, those we deem the most appropriate.

The specialized work of a mechanic fixing your car, for example, belongs to the Complicated domain. The mechanic will assess your car’s condition in order to choose between possible solutions, and then solve the problem.

Complex Domain

This is the emergent domain, where the relationship between cause and effect only becomes evident in retrospect and is not reproducible. In other words, for any action by its agents, it is not possible to predict what will happen as a consequence. We can only know after the event. Thus, for any given situation, we must investigate through experiments (probe) to understand its impacts (sense) and then promote what works and abandon what does not (respond). In other words, we conduct a series of experiments in parallel to then choose the one that generates the best result.

A multivariate test operates in the Complex domain. In an example of this type of test, users of the same website are divided into groups. Each group has access to a version of the same page, but with different elements. The version that generates the best results (more conversions, for example) will prevail. Also operating in the Complex domain are Complex Adaptive Systems, described above.

Chaotic Domain

This is the domain of new practices, where the relationships between cause and effect are impossible to determine, because they constantly change. There are no constraints (or patterns), just turbulence, so any practice used will be completely new. When possible, we should act quickly to restore order (act) in order to understand where stability exists (sense), and then work to turn the situation from chaotic to complex (respond), which is a more manageable context.

The necessary actions in a crisis situation, such as rescuing hostages, for example, characterize work in the Chaotic domain. Projects focusing on innovative research, in which what we discover at one moment can change all the subsequent work that is done, are also examples of work that operates in the Chaotic domain.

Disorder Domain

Multiple perspectives are presented in this domain, and it is not possible to determine which of the other four domains is predominant. As such, we know nothing about the relationship between cause and effect, and we cannot determine how best to work. The Disorder domain lies in the center of the Cynefin model sketch.

In Disorder, people compete destructively for solutions that are in their respective comfort zones – that is, in one of the other four domains. The way out of this situation is to break the problem into parts and define the domain for each one of them – Obvious, Complicated, Complex or Chaotic –, and then act accordingly.

Scrum and Cynefin

Unlike Scrum, traditional command-and-control management treats work as belonging to the ordered domains – i.e., Obvious or Complicated. In these domains we can establish the relationship between cause and effect, and thus the known good practices (or best practices) must be applied for each situation.

As I already highlighted in the Scrum is agile section of this chapter, these traditional methods are not effective in changing and unpredictable contexts and fail precisely because they treat product development work as a predictable process. This type of work, in fact, is usually positioned in unordered domains.

For systems that operate in the Complex domain, we should conduct multiple experiments in parallel, so that innovation, creativity, and new standards can emerge. Tolerance for failure is an essential aspect of this empirical learning. Scrum, however, does not exactly operate in this domain. Although several aspects of the Complex domain are present, the iterative work in Scrum produces deliverable increments of the product in sequence, rather than producing multiple delivery candidates in parallel, and which would compete for deliverability.

Scrum also does not work for projects that operate in the Chaotic domain. To use the framework, it is necessary to establish short-term horizons in which the goals to be carried out are well defined and stable, aligned with a longer-term goal. In the Chaotic domain, on the other hand, the goals and direction can change at any moment.

I did a training with Dave Snowden in the first half of 2019 and had the opportunity to talk to him about this. According to Snowden, Scrum operates in the liminal region between the Complex domain and the Complicated domain (the shaded region between the domains in the sketch of the Cynefin model). In fact, Scrum treats the implementation of product increments in each cycle as an experiment, given that the product will be modified in subsequent cycles based on the feedback received. Nevertheless, Scrum shifts from the Complex domain to the Complicated domain by focusing on just one experiment at a time.