I’d come across the model previously and it had been all over my twitter stream a couple of weeks ago as a result of Dave Snowden giving a key note at the Lean Systems and Software conference.
These are some of the things I learnt from the workshop:
- The model is based around understanding the correlation between cause and effect:
- Simple – there’s an obvious correlation between the two
- Complicated – there’s a correlation but it’s only clear after some analysis, probably by an expert in that domain
- Complex – we can only see the correlation in retrospect, not in advance.
- Chaotic – there is no correlation between cause and effect
- Disorder – there probably is a correlation but we don’t know what it is
- My original understanding of the model was that you would try and work out where a system fitted into the model and I was under the assumption that most software projects would be considered ‘complex’.
After a couple of hours in the workshop it became clear that we can actually break down the bigger system and see where its parts (sub systems) fit into the model as well.
Since different approaches are required depending upon where in the framework we are, we would act differently depending on the situation.
For example a software project as a whole might be considered complex but the design of the architecture might only be complicated because some of the team members have worked on something similar previously.
- Another interesting point that John made is that things don’t have to live in one domain forever – they can move between them!
For example on a lot of the projects I’ve worked on it often feels that if we knew everything we knew at the end of the project at the beginning we could have finished it significantly quicker.
Effectively the project starts off being complex but if we got to do exactly the same thing again and it played out in exactly the same way then it might only be complicated.
- We did a couple of exercises where we had to place different items onto the model – first non software related and then software related.
It was interesting to note that in the first exercise we had quite a few items in the disorder section but in the latter we had none.
As you would expect having experience in the group around the domain helps us understand the problems in that domain better.
If we take this one step further it’s also beneficial to have diversity in the group because then we get a variety of perspectives and one person’s strengths can help make up for another’s weaknesses.
There’s an interesting article in the Harvard Business Review titled ‘A Leader’s Framework for Decision Making‘ where Dave Snowden explains the framework in more detail using scenarios which might fit into the different areas of the model.
The origins of cynefin is another nice write up where Snowden describes how he came up with the model.