Dave Snowden

False dichotomies, reality avoidance

RSS Feed

In my keynote on Friday at Agile Maine I opened by suggesting that there was a schizophrenic dichotomy in the Agile movement between highly structured, harmful, all encompassing frameworks on the one hand, and
mostly harmless, but inconsequential methods based on happiness and the like. This also represented Agile coming late to a similar tendency in industry overall between rigid process based approaches such as Sick Stigma combined with fluffy bunny and/or idealistic models of leadership competence. Both approaches fail to deal with reality, in fact they are reality avoidance methods. Given that schizophrenia involves abnormal social behaviour, false beliefs and confused thinking the reference is appropriate.

Personally I trace this back to the cybernetics origin of the systems thinking approaches that dominated since the 1980s. That produced the promise of order through engineering but as the limitations of that approach became apparent all that could not be engineered was consigned to the deified role of the great leader. The irony of Agile is that that is all started in the right place – small experimental changes, a recognition of the essential messiness of life. But sustaining such realism has proven difficult. An over focus on training and accreditation makes this worse as such approaches require more and more emphasis on codification with standard messages, multi-choice questions and the like. All the things that went wrong with Knowledge Management at the turn of the Century. One of the downsides of age is that you are condemned to live through multiple cycles of the same mistakes.

The reality is that we have complex and complicated systems, but we also have transitions between them. It is one of the reasons I am emphasising dynamics as well as domains in Cynefin. In some presentations I have started to introduce the complex-complicated transition in human systems as a domain in its own right (and I may do that more, still playing with the representations). One of the many values of SCRUM as a technique in Agile is that its linear iterative nature is well suited from taking material on the boundary with complexity into complicated to allow for easier scaling and operational control. Providing structure for the mess of complexity through heuristics, portfolio management of parallel safe-to-fail experiments and the like has always been a part of what we do at Cognitive Edge, but starting to look at managed transitions between domains – in both directions – is a necessary step.

Reality in complexity is about emergent plausibility, in complicated it is about objective cause and effect relationships that can be replicated as is. False dichotomies enslave us to formal methods and structures, recognition of the dialectic and transitionary nature of reality gives true freedom.


A note for fellow obsessives: With time differences I ended up using Gaping Void’s 2nd May cartoon on the 1st of the month and have worked in sequence since but the May Day one was too good not to use so I’m now getting back into alignment. The need to do this is rather like my need to follow the Wales Coastal Oath in sequence, according to the official route, retracing steps over ugly terrain if necessary. Oh and then there is the Starbucks mug collection and my sense of extreme discomfort at amy linear out and back walking route ……

  • Robert Wolff

    Excellent read! As a Scrum Master I still fail to recognise when problems are complex versus complicated and it’s sadly very easy to give false advice when the team asks how to proceed with a certain topic when there are unknowns. Adding a “Spike” into the sprint is usually what we do then, to find out what we actually have to do and how to approach it. Unfortunately Spikes are hard to translate into story points and god forbids no one wants the velocity to go down. I’ll try to bring keep the domains in my head in our next refinement, asking the team what they think in which we are with a certain topic and why they are thinking this way – hopefully sparking awareness in the team on when to bring in experts versus when to probe and experiment.

    • https://twitter.com/chrizbot Chris Butler

      If the management team can’t trust that employees are doing the right work through discussions, seeing the code shipped, research synthesis, etc. and requires quantified metrics like velocity, then I’m not sure that the team can be effective in the complex domain. Velocity seems to only make sense when something can be repeatable and that is not the case in the complex domain.

    • Matt

      Hi Robert, I tried this approach with a certain degree of satisfaction you can read more here: https://medium.com/@MattCarella/cynefin-applied-to-user-stories-a68f2301902