Cynefin

Cynefin this. Cynefin that. Everywhere I turned, someone seemed to be referring to this thing called Cynefin. I didn’t even know how to pronounce it, let alone what it was. So last month, at Lean Kanban UK 2013, I decided to go along to Liz Keogh‘s session entitled ‘Cynefin in Action’.

In short, Cynefin is a framework devised in 1999 by Dave Snowden to describe different contexts/environments/problems, which helps you evaluate a situation and decide on an approach. It is particularly relevant for decision-making and organisational strategies – it is particularly relevant to knowledge industries such as software development. The model helps understand why certain ways of approaching software development work best in certain situations; and fail at other times.

 

 

Lists 5 contexts/domains:

Simple
The relationship between cause and effect is obvious to all.

The best approach to deal with simple scenarios is “Sense – Categorise – Respond”. In short, no analysis is needed because there is a standard, best practice approach that everyone can do for this situation. The example given is putting a chain back on a bike.

You’ll know these situations as you will hear phrases like “Oh, it’s one of those problems, just do x and it will fix it.”

Complicated
The relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge. Breaking requirements down works in this domain.

The best approach to deal with complicated scenarios is “Sense – Analyze – Respond”. This means apply analytical techniques to determine the facts and range of options before choosing how to proceed. Examples include fixing a watch or the workings of a jet – they’re complicated, but you can understand how they work if necessary and there is consistency in how they work/the outcome.

Phrases you may hear: “I will investigate the problem and then will be able to tell you how to fix it because I’m an expert in this field”. Einstein was talking about the complicated domain when he said “The definition of insanity is doing the same thing twice and expecting a different result.”

Complex
You cannot identify the relationship between cause and effect in the complex domain until after the event. The outcome in complex scenarios is not consistent nor predictable.

Therefore, the best approach is “Probe – Sense – Respond”. This is the domain where you need to look for emerging trends and, as Keogh described, “make small, diverse interventions” from which you will generate options. This is the domain where hacking, collaboration and agile work well. An example often given is the workings of a frog, but I think Scrum is a better example: you could implement the same processes in five different companies and the outcome would be totally different. Maybe the weather is a good example too?

Things you might hear: “Doing the same thing twice WILL give you a different result” and “We ended up in a completely different place from where we planned to be … but it’s a much better place.”

Chaotic
In the chaotic domain, there is no relationship between cause and effect.

The best approach is to act immediately: “Act – Sense – Respond”. You may even perform multiple actions concurrently in order to stabilise the situation. One benefit is that novel practices are sometimes discovered during this act now, think later state. Examples of this domain are your house is on fire or you have just released a bug into Production that has crashed your site.

Keogh even suggests that chaos can sometimes be a good place to dip into when in the complex realm: sometimes creative solutions can be found here.

Disorder
You are here when you are unsure which domain dominates.

Apparently, the approach that most people take when here is to revert back to their comfort zone when needing to make a decision.

 

Finally, you might have noticed a small hook on the diagram between Simple and Chaotic. This denotes complacency: it is easy to go from simple to chaotic, but often impossible to go back simple (think about mixing yellow and blue paint to make green … then try to make it yellow and blue again).

 

Armed with this framework, you can decide where a situation lies, then use an appropriate approach: should we break the requirement down into stories (complicated), or do we need to do a hack/discuss options/get a prototype out to business (complex), or has something drastic happened and needs a command-and-control approach to stop the bleeding before we consider an approach (chaos)?

So, that’s the basis of Cynefin. At least you know now so that you can partake in the discussion when it next comes up. Oh, and it’s pronounced Cun-ev-in.