One of the problems we (in the sense of all users of) get with Cynefin is the temptation to put things into the domains and then privilege one over the other. I've seen it used to in effect say my method is complex, yours is complicated so Yah boo sucks I'm a better person or more recently you complex people are old hat, I work in chaos, I'm a true creative or when you enter the near psychotic; chaos is the domain for magicians with the obvious implication that the writer is a true descendant of Merlin and beyond criticism.
Now all of this rather misses the point. Cynefin is about multi-ontology sense-making or, to use the vernacular, horses for courses. Some horses run well on soggy ground others on dry and those that can't run end up as beef burgers. So if the constraints are legitimately high process engineer the solution to death, focus on efficiency as its simple. If the constraints are sufficient to create predictability and repeatability then its complicated so bring on experts or determine analysis. Otherwise its almost certainly complex, chaos is a temporary and very useful domain but difficult to create. Ironically if I want to use Wisdom of Crowds or as I prefer Distributed Cognition I have to put a lot of effort into constraining any interaction so the agents make decisions without influence. All of this is a lot more nuanced than a simple categorisation into the domains and it is certainly not about privileging one domain over another.
Now this post was original stimulated by a useful post from Kim about how KANBAN can apply in all Cynefin domains, in part in protest about people saying that it would always tend to the complicated. As it happened when I first read that post I was also on a conference call where I was making the point that SCRUM (an AGILE technique for software development) if used properly was about making complex problems complicated but lacked a feedback loop to push issues back into complex when needed. Something I will be posting on and talking about later. The whole SCRUM/AGILE/KANBAN/LEAN movement(s) are very powerful, very progressive but have some of the tendencies of welsh calvinist chapels or Trotskyite groups in the 70s to split on minor points of doctrine and be more concerned about internal differences than changing the world. Monty Python would have a field day (3 minutes into the link but its all worth watching again) but Liz may have beaten them to it in a very witty, near to the bone posting.
The issue with techniques such as KANBAN is not the technique per se, but what it is applied to. So if the problem is complex then you are running a portfolio of safe-to-fail experiments with monitoring points for potential success or failure with amplification of dampening strategies ready to roll. KANBAN is a good technique for monitoring progress and determining actions, in fact it is a very good technique but needs the KANBAN board redesigned to indicate which domain the activity is in and that needs some work.
The issue with complexity is less how you manage, more what you manage. I theme I will develop over the next few days. The title of this post and the picture are an anthropological reference by the way, fully intended and I'll come back to that as well.