The Cynefin Review Pt 1

Cynefin – The Sense Making Framework – Part 1

This is a new series on Cynefin and the Sense Making Framework that shares what I learnt on the 4-day course with David Snowden and Tony Quinlan.

There are many other articles and official works which will give you a more formal view on the framework and I would advise you to consult these materials in addition to this article.

Most importantly these are:

I would also advise attending one of the training courses on Cynefin and you can then learn first hand these concepts and also work through the exercises.

This post highlights the things that will be of use to the organisational change community and to my clients practicing Agile and going through an Agile adoption.

The material related to SenseMaker® is copyright Cognitive Edge and protected under Copyright and Patent laws.Copyright © 2015 Cognitive Edge. All Rights Reserved. US Pat. 8,031,201 Permission to use has been kindly given.

First – the basics

The sense making framework gives us 5 complexity domains that we may find ourselves in at any given moment.

Obvious (was named Simple)
Complicated
Complex
Chaotic
Disorder

These domains are not categories. The model is not a quadrant model, and each domain requires a different leadership model, tools, and mind-set. Let’s dive a bit deeper into the Cynefin framework.

The important thing is that the boundaries are fuzzy and things move between the different domains. So a system may be dominated by different domains, but in reality, the type of work typically has elements of different complexity at different times.

Ordered systems: Obvious and Complicated systems

The Obvious and Complicated domains are ordered systems. This is represented by the domains on the right hand side of the diagram. In an obvious domain, the relationship between cause and effect exists, is predictable, repeatable and can be determined in advance. The domain is highly constrained, understood easily, and typically enforced.

For a given problem in this domain, we sense the problem, fit it into a category and respond with a standard solution. This leads to true best practice solutions at any given point in time.

Many design patterns have the ability to safely fail or extend as required built in. This allows for complex behaviour to emerge safely. For example, the abstract factory pattern lets you add other kinds of items as you find out what they are; rollback lets you release and if it’s wrong you get to roll back.

Building in real options is a way to insure against unexpected change and is a cost that can be worth exploring if you believe you are in the ordered system space but want insurance against being wrong.

In the complicated domain, there is still a direct relationship between cause and effect, however it is not self-evident. We need specialists or algorithmic help to derive a solution. Here we can find good practices and design patterns to solve problems. We sense the problem, analyse the solution and execute against a plan.

There may be many solutions to the same problem, hence good practice, instead of best practice.

An example of a complicated system is a wrist watch. A specialist watch maker can take apart a complicated watch and put it back together again.

Complex systems

Complex systems still have causality; however, it is not possible to correlate that causality upfront. It is only possible with hindsight. There are light constraints on agents who can modify the system. Cause and effect are only obvious after the event.

The way to solve problems in this domain, is to probe for the solution and sense what is going on. Given there are competing hypothesis, there is usually no shortage of safe to fail (learn) experiments to perform.

In practice, this means to form multiple hypothesis that are often conflicting. Then create multiple small safe to learn (fail) experiments within the problem domain and view the results. We then amplify, or dampen the results with more experiments. The practice moves us closer to a solution iteratively. This is similar to the Lean Start-up approach however the Lean Start up does things sequentially, but complexity requires us to run experiments in parallel.

The challenge is that we like to form conclusions too quickly and expect that the correlations we have identified will hold true if we repeat. However, this is not always true and quickly we can find ourselves getting different results when doing the same thing. We must probe first and then sense.

The practices and results emerge from the data. We have emergent practices.
Simon Powers
Tweet

An example of a complex system is a frog!

No one can take apart a frog and put it back together again and expect it to be the same. Complex systems have behaviours that arise or emerge from the system, making the system more than the sum of its parts.

A complex adaptive system is a “complex macroscopic collection” of relatively “similar and partially connected micro-structures” formed in order to adapt to the changing environment and increase its survivability as a macro-structure.

From Wikipedia

They are complex in that they are dynamic networks of interactions, and their relationships are not aggregations of the individual static entities. They are adaptive in that the individual and collective behaviour mutate and self-organize corresponding to the change-initiating micro-event or collection of events.

Although this sounds (at least to me) to be very technical an unrelated, if we swap this around a bit, we can see how it is relevant to product development:

A complex adaptive system is a community of relatively “similar and partially connected people” formed in order to adapt the business model to the changing environment and increase its survivability as a viable product.

Product success is complex in that it is reliant on a dynamic networks of interactions, and their relationships are not aggregations of the individual features and decisions. Customer behaviour is adaptive in that the individual and collective behaviour mutate and self-organize corresponding to product releases, market events or collection of other events.

Chaotic systems

No cause and effect relationship can be found. Patterns can emerge, but they do not repeat or stay in a stable state. We cannot correlate cause and effect until we’re out of chaos (at which point we can do so with hindsight, eg: “Huh! Look at that… I skidded on black ice.”) (Thank you Liz Keogh for the example ☺)

Chaos is only ever temporary and constraints must either be formed in a constructive way, or stability will form seemingly automatically from other forces, and may or may not be beneficial. Therefore, when a system moves to a chaotic state it only stays in that state temporarily. It will stabilise into one form or another. That form may be beneficial or it may not be. To increase the chances of the outcome being beneficial, it is necessary to act first, then sense, and respond, mainly because of time criticality.

Chaos can be used to find innovation, and having an innovation team, that works in tandem with the crisis management team to provide learnings that might never have happened is recommended by the framework.

Disorder

The central space is for when you do not know which of the domains that you are operating in. According to Dave Snowden (Snowden, The Cynefin Framework), when we do not know what domain we are operating in, we default to using the method that we are most familiar with.

Cynefin Review – continued…

Next, read the rest of the Cynefin review at the following pages: