Every now and then, someone comes up with a new way of looking at the world that becomes the next fashionable thing to do. Every time I’ve seen this, there’s usually a space of time in which a lot of people say, “Meh, it’s irrelevant”, or “Meh, consultants”, or “Meh, they’re only in it for the money.” After a while, things settle down and everyone is used to that new model or concept, and it’s no longer seen as edgy or strange. I’ve seen it with Agile, and Lean Software Development, and BDD, and now it’s the turn of Cynefin and Complexity Thinking.
I’d like to shortcut some of that with Cynefin, because I think it’s kind of cool, I’ve found it useful, and it’s not actually that hard to get your head around once you make the small mindshift. I’m going to share a bit about what I know of it, then talk about how it might actually be a useful concept for a dev to have in their head.
Some of us went to the Calm Alpha meet up, created a list afterwards, and have been using it to discuss which kinds of software can be categorised by which domains. I think our need to categorise everything is part of the problem, but I haven’t worked out how to solve it yet. In this post, I’ll be categorising things according the Cynefin definition of the terms, so resist the urge to say, “No! What I’m doing is simple!” or “But it’s complicated!” because Dave Snowden, who created the Cynefin model, uses those terms in a slightly different way to our common usage.
So here’s Dave’s Cynefin model.
Dave Snowden, released under CC BY 3.0 – thank you!
The Cynefin model consists of four domains – simple, complicated, complex and chaotic – with disorder in the middle. The edges of the domains aren’t strict – they’re domains, not quadrants. There’s also a little fold beneath the “simple” to “chaotic” boundary, to show how easily simplicity can tip into chaos. If you’re going to use this for a lot of items, it might be worth using the domains as attractors, rather than categories. Put the items down on a table, then work out where the lines go afterwards. If you can get your head round that, you’re already on your way to understanding complexity thinking.
Here’s how I tell what kind of programming I’m doing.
Simple
Everyone can work out how to do this. Like, everyone. The example the CE guys used was a bicycle chain falling off. It’s easy to work out how to get it back on again. If you’re programming, I imagine stuff like the turtle at the science museum, or Lego Mindstorms with its graphical drag-and-drop interface, might fall into this space. Children and non-programmers can do it.
In a simple environment, you sense, categorize and respond. You say, “Oh, it’s one of those problems.” No analysis is required.
Complicated
Complicated stuff is predictable, but requires expertise to understand. A watch is complicated. If you’re programming, complicated stuff will be well-understood, done before, not going to change as you develop it. Writing yet another CRUD form probably falls into this space.
In a complicated environment, you sense, analyze and respond. You say, “Let me have a look at this problem and I’ll tell you how to solve it, because I’m an expert at this.”
(I have a theory that most devs get really bored by doing the same predictable but complicated thing over and over again. We tend to turn it into open-source or automate it, reducing it to the far smaller but more complex problem of how to do the automation or use the open-source. Devs are drawn to complexity like moths to a bonfire. And we make it when we don’t have it…)
I reckon that if everything in software development was merely simple or complicated, Waterfall would work very well. You’d be able to set out to achieve some goal, work out how to do it, achieve the goal and say, “Job done.” Software doesn’t consist of only simple and complicated stuff, though. So let’s have a look at the other two domains.
Complex
My favourite way to understand complexity is that acting in the space causes the space to change, and cause and effect can only be understood in retrospect.
When you start writing tests, or having discussions, and the requirements begin changing underneath you because of what you discover as a result, that’s complex. You can look back at what you end up with and understand that it’s much better, but you can’t come up with it to start with, nor can you define what “better” will look like and try to reach it. It emerges as you work.
In a complex environment, you probe, sense and respond. You do something that can fail, safely, and it tells you things about the environment which you respond to, changing the environment . This is the land of high-feedback, risk and innovation: generally stuff you’ve never done before, anything that the business are unsure about, new technologies, etc. This is the domain in which Agile techniques really flourish. If you have a look at Cynefin’s pyramids, this is the one with very loose leadership and the people at the bottom all connected together, collaborating to solve a problem.
This is the most interesting domain for me. It’s the reason why we do things like BDD – using examples to discover more about what we’re doing – but it’s also the reason why, if we focus on trying to pin every small requirement down, we fail.
Chaotic
Chaos is your house catching fire. Chaos is accident and emergency. Chaos is that bug you released to production that brought your site down on the day of release, and you need to drop everything and fix it now.
In chaos, you act. You get out of the house. You stem the bleeding. You do something to get the situation under better control. When Egor Homakov hacked Github this week, Github responded by suspending his account immediately. They acted on the threat. After that they analyzed his actions, considered what he had done and reinstated his account. Act, sense, respond.
So why should I care as a dev?
I’ve found this model really useful for understanding why certain ways of approaching software work best in certain situations, and fail at other times.
The biggest failures I’ve seen have come from treating complex problems as if they’re complicated. For instance, a common Agile practice is to divide a problem into small chunks that we call “stories”, then start working on them. That’s actually a good way to work when most of the problem is complicated, but if you’re doing something new then you may want to go down the “probe, sense, respond” route instead. Hack something out, and get feedback on it. There’s no point guessing how you’re going to reach the goal, because as soon as you get feedback, there’s a good chance the goal itself will change.
Also, sensemaking is itself a complex thing. By trying to get feedback, you might find out how easy or hard it is just to get feedback. That could change the way in which you engage with the business. It might affect how much time you put into preparing for a planning meeting, whether you make a feature work fully or just fire off a screenshot, etc. As you seek to get that feedback the business will change the way in which they respond, too, so it might become easier or harder, and you need to be watching for those signs so you can help to change the process to match. As a dev, you’ll be the one feeling the frustration or ease from the process. It’s no good just relying on your coach or Scrum Master to help you, because he or she needs your insight too.
Knowing this model helps me know when to do TDD or automate BDD – defining a well-understood outcome, and working creatively with the software to reach it – and when to just use examples as ways of discovering more about what we’re trying to do. If I can clearly articulate the outcome and everyone agrees on it, then probably it’s good for TDD and BDD automation. Otherwise, having conversations is more important than automation, whether it’s with a pair-programmer at a class level or a business spokesperson or tester at a system level. Being able to tell the difference can help ensure that the conversations are the most interesting and effective conversations we can have. If I spot the conversations becoming boring, with people yawning or drifting off, then I know we’re trying to apply a complex method to a complicated or simple space and I can say, “Okay, I think we understand this well enough,” and work on something different instead.
(Also, knowing that the act of sensemaking is complex itself makes me look out for situations in which we’re misapplying methods.)
When chaos erupts, I know that letting my PM order us about for a bit is OK. Dropping everything we’re doing is also OK – forget the whole “developers need to be left alone to do their work” idea that the Scrum timebox normally provides. We fix the bug, hack the workaround, take the feature down, do whatever we need to do to get things under control. Chaos almost matches the “expedite” class of service in Kanban, except that I think you probably don’t even bother putting a card on the board until the need to expedite is over. After the emergency is over, we can look at whether it was just a one-off or whether there’s something we need to do to avoid happening again. For instance, being able to roll back a deployment cleanly and quickly gives us the ability to probe a release instead of crossing our fingers, moving something that might become chaotic into a complex space instead.
These are the kind of decisions that we make intuitively anyway, as developers, but human intuition is often flawed. We’re often uncomfortable with uncertainty, so we usually try to define outcomes regardless of whether they can be clearly defined or not. We’re definitely uncomfortable with chaos, and often make the mistake of treating a one-off chaotic incident as systemic, stamping controls over everything when what we really need is a way of probing, or trying things out safely. Having this model in my head has really helped me to become more comfortable with those situations, and to find approaches that fit them much better. Of course, this is massively useful when I’m coaching and acting as a change agent or helping a PM work out how to lead a team – but even as a dev, having this model makes a big difference to me and my day-to-day work.
I hope it will help you too.
Liz Keogh, lunivore 
Nice post, great summation of Cynefin, I can draw lots of parallels to current work!
I’m setting “Chatoc” aside in what follows. Or maybe I’m not.
I’ve only been working with software for a half century, so perhaps my experience isn’t general enough. Be that as it may, I’ve never been involved with a software effort that wasn’t part Simple, part Complicated, part Complex (and, now that I think about it, part Chaotic).
When we’re creating something new, there’s a lot of Chaos. We don’t really know quite what we want, even if we think we do. (We’ll discover that truth later, when we build something and don’t like it.) So we do something, as Cynefin suggests, and see what happens. This is a lot like what Eric Ries is talking about in Lean Startup.
Parts of the project are simple. We just do them. Parts are Complicated. We tease them apart, which tends to make Simple things, which we just do, and less Complicated things. Usually, at some point, we just do some of the Complicated ones without making them simple first. This is often a mistake in retrospect but never looks like it in the moment.
And some things are Complex. These are, in my experience, always the things that are not about the computer but about the people. I’ve never written a computer program that was Complex and I’d run like hell if I ever did. There’d be no telling what it did. (I hang out with a Complexity guy and he seems to have a different viewpoint. I’m not convinced that I understand it, and not convinced he’s right if I do understand it.)
What this all comes down to for me is that these distinctions aren’t entirely useful. Let’s look at the actions from Cynefin:
Simple: Sense Categorize Respond
Chaotic: Act Sense Respond
Complex: Probe Sense Respond
Complicated: Sense Analyze Respond
These all include Sense and Respond. They sometimes have something in between Sense and Respond. Both these things amount to look at what the sense returned and think about it. They sometimes have something ahead of Sense, which is always an action, sometimes called Probe, and sometimes called Act.
Therefore, setting order aside (which we can do for a reason I’ll mention in a moment) and merging these decks, we get
Everything: [Act/Probe][Sense][Categorize/Analyze][Respond]
The difference between Probe and Act is that Probe is something that can fail safely. In Chaotic, we, apparently, just act. It is wise, in chaos, to take actions that cannot fail safely? I think not.
The difference between Categorize and Analyze is that in Categorize we have the categories all figured out and in Analyze we are open to new discoveries. Is it ever wise not to be open to new discoveries? I think not.
Is it ever wise to Sense and Respond without some kind of thinking in the middle? I think not.
So while these classifications are interesting ways of looking at things, i agree with what you said above about our need to classify things. I believe that in fact the universe is Complex, and that in particular the human effort of devising a product is Complex. Creating a solution in software, especially with a team, is Complex.
Amid all that complexity, sometimes we can spin off a little Simplicity, and we mostly try to move from Complex down to merely(!) Complicated. We try not to spin off into Chaos.
So to me it’s all the same, always. Take some action, which may just be what Dave calls a Probe. Observe what happens, which he calls Sense. Think about what happens, sometimes just a little, sometimes a lot. And Respond, or as I like to call it, Rinse, Repeat.
That’s not to say that the model is bad. Like all models, it has value and like all models, it is wrong. It’s just that the world is a complex interweaving of things that sometimes seem simple, even when they’re not.
Thanks for making me think this. 🙂
Well said. Thanks!
I found “Everything: [Act/Probe][Sense][Categorize/Analyze][Respond]” to be a beautiful way of putting it. It appears to embody the Cynefin framework for a mature practitioner who knows where (and if) to use Act vs Probe and where (and if) to use Categorize vs Analyze. For early practitioners in complexity models, i found the different sense making model of Cynefin to be extremely helpful. But i love your “Everything:…” too.
Thanks for sharing.
Great article. Seems like a good framework for deciding how to approach problems rather than going in with a one-size-fits-all approach.
Ron, the complexity guys think we’re a bit too hung up on causality. Thinking about why something is happening, in a complex space, doesn’t necessarily help – it’s part of their take, and having seen some of their methods I’m beginning to understand. We see patterns where none exist (and you should hear what Dave thinks of Systems Thinking in this space 😉 )
As for doing things which can’t fail in chaos – well, if you don’t get out of your house or stem the bleeding, someone will die. There’s nothing safe-to-fail about that, but it won’t stop me doing it.
Other than that – yes, it’s just a model.
Nice article! This is my thoughts abut cynefin framework:
http://code-dojo.blogspot.ca/2011/12/cynefin-framework-and-software-code.html
I feel Scrum is a process of dealing with complex domain. The process is iterative, so it fits the probe-sense-respond model. But when you look at each sprint, it will fit into simple or complicated domain. Since during each sprint, the requirements are clear, the expected results are clear, and actually each sprint can be treated as waterfall, so it belongs to simple or complicated domain. So I think the Scrum split a complex problem into many small simple or complicated problems.
On the other hand, if we treat the complex problem using solutions of simple/complicated domain, like waterfall methodology, then the problem will move from complex domain to chaotic domain, that is why we have so many bugs, fire fighting…
What do you think?
Steve, if you’re treating your sprints as mini-Waterfalls, you’re missing a trick or two! And I’ve yet to see a Scrum team work in the complex domain and come up with clear, unambiguous requirements. Of course you’re *meant* to, but I don’t actually think it’s possible. Instead, I suggest spiking something and getting feedback as early in the sprint as you can.
Great intro into the model.
One comment, although Mindstorms is a really simple tool, you can use it to create complex, complicated and chaotic systems. Lots of code-gen tools are like this!
George Box famously wrote that all models are wrong, but some models are useful.
I find the Cynefin Framework useful.
As Patsy famously said in Monty Python and the Holy Grail: “It’s only a model.”
Ron, your collapsing of the actions ruins the idea. The order is actually significant. As is the distinction between Act and Probe. Check out Dave Snowden’s videos on Youtube. I wish I could find something written that summarizes the subject, but it seems the videos are the authoritative source, unless you hire Dave.
Ron, of course if you can make your actions in chaos safe to fail you do so that is common sense. The point is that you don’t have whe time in all cases to go through the portfolio analysis and checks. While in complex you do. So the distinction is important. Also I think there is a lot of mystification here. A lot of software development is complicated some is simple. Saying it is all complex is to my mind to miss several tricks. Oh and my the way many of use have years of experience ….
Pingback: How to Prioritize a User Story Map | Protegra
Pingback: Value Streams are Made of People | Lean Systems Society | Lean Systems Society
It seems that a general categorization of general software development is inherently considering it to be a simple process (probe, sense, respond). I find the Cynefin framework to be useful, but it needs to be considered and applied to the process at hand. I believe that this article is helpful in that regard.
Even beyond software development itself, the model often provides insight into the usefulness or futility of various approaches to issues as they develop. I have found this model very useful.
Liz – enjoying your writing about Cynefin and other topics. As a product manager looking for (and inventing) tools for product managers, I think complexity is the fundamental problem that existing tools don’t address. They – and this includes scrum, imho – treat the product process as complicated, rather than complex. But, as you put it in another post, the *interesting* stuff we do in the product world is a 4 or 5 – either the problem has only been solved once by someone we don’t know, or it’s a completely new problem and we don’t really know how to solve it (much less estimate it or turn it into stories or whatever).
Thanks Liz, great succinct summary of Cynefin – very useful when someone asked me to pass on my learning from your talk at LKUK13 🙂
I keep thinking of Einstein’s definition of insanity (“doing the same thing twice and expecting a different result”) being in the complicated domain, and needing a little rewrite to fit complex: “doing the same thing twice WILL give you a different result”
Pingback: A few words on the Cynefin framework | niksilver.com
I think @Ron’s distillation down to all-is-complexity is fair in general – in fact, it appears just to be the scientific method (as with all Lean-Agile). But are you having to do said scientific activity during an ambush, or while helping a child set up dominos?
Sure, all contexts can be seen as generated by the complex adaptive system of the universe (hence complexity science). But if the pattern of a particular context instance can be detected in a timely manner, then optimizations are to be had by _not_ applying overly-expensive reactions.
This is my first encounter with Cynefin, so I’m grateful to Liz for the introduction.
It seems to be suitable for tasks that have a singular, clear output (“balance the statement of account”; “don’t crash if someone renames the file”). It seems to help with getting things “correct.” But that’s only the first step. In my experience at least, maximizing total legibility/utility to a population (while preserving the correctness of discrete user stories) is at least as important, and far more difficult.
Sound exotic? Not really. The fitness of a UI depends on the population of its users. Likewise, an API on its clients. Even lines of code require this sort of judgment. Code is better (easier to reason about, more changeable) when it’s tailored to idioms and conventions that will be legible to your co-developers. And then there’s the question of what’s legible to customers and stakeholders.
Should I think of Cynefin as analogous to triage: a branching point in a decision tree, without promising anything about how to handle subsequent decisions? Just as a medic divides wounded into three categories without necessarily having surgical skills, does Cynefin help you size a task, without providing guidance on how to solve it or whether it will be done-done?
Yep, Cynefin doesn’t really solve problems. It just gives us a way of thinking about them and a suggestion for the kind of approach. I do also tend to think of things as being more or less complex or complicated, rather than categorising; the boundaries are fuzzy and things move. It also works for different scales of problem (though I’m looking into the idea that you can have more certainty at larger scales; capabilities for a project rarely change!)
Pingback: Making Sense of Today’s Mobile World
Pingback: Software Development Processes FAQ | Cosmin's Hooking testify
Pingback: Using BDD as a Sensemaking Technique | Liz Keogh, lunivore
Reblogged this on Changing when change is required.
Pingback: Everyday Lean The Cynefin Ogre - Everyday Lean
Pingback: Feedbackschleifen in Kanban – das 40. Treffen der Limited WIP Society Cologne | Limited WIP Society Cologne
Pingback: Cynefin In Software Testing | Duncan Nisbet
I suspect Ron’s simplification fails because the underlying model is also presented in oversimplified terms. Yes, all four primary domains include “Sense” and “Respond” yet the words have entirely different meanings in each case.
Here’s an attempt at disambiguation for “sense”:
Simple: general observation of the situation (of the “obvious”) for categorization.
Complicated: careful observation of the situation sufficient to inform later detailed analysis.
Complex: dynamic monitoring of feedback from “probes” to inform adjustments to our actions.
Chaotic: emergency observations of both situation and feedback to tweak real-time (often simultaneous) actions and impacts.
The timing, observational subject, purpose and more are quite different in each case. Very different tools, skill sets, etc are required.
I think a full understanding of Cynefin will require more than one book and possibly more than one lifetime… but this is insightful. More blogs on this can only help; please do write more and post a link!
One of these days 😉
I just discovered that there’s a vocabulary (Cynefin et al) for the work we’ve been doing for the last 15 years 😉
Hopefully we’ll find a way to put this in writing…
Pingback: The Cynefin Ogre | Amplifiers
Pingback: [NCrafts2016] No Estimates : Estimer sans estimer - Cellenza Blog
Pingback: # 8 Side notes JAX London 2016 – Automation Journal
Pingback: Measuring and defining risk with Cynefin – Mike Pearce
Pingback: With Cynefin, I can justify skepticism about inappropriate approaches and create better ones – ASYM APS
Pingback: [Back from NewCrafts] Des flux et des files d’attente | Le blog technique de Younited Credit
Pingback: Pull the other one… | blueskyline
Pingback: [NCrafts2016] No Estimates : Estimer sans estimer - Le blog de Cellenza