In the Cynefin framework, the Disorder domain is the one in the middle. It’s the state of not knowing what kind of causality exists. Over on the right we have the predictable domains of Simple and Complicated, and on the left the unpredictable Complex and Chaotic domains. When we aren’t sure which domain dominates, we tend to behave according to our preferred domain.

I’ve become used to seeing the Complex domain treated as if it’s Complicated by people who desire predictability. We do it all the time with Scrum, trying to estimate things we’ve never done before, or with BDD when we try to define outcomes in scenarios where the right answer isn’t certain. Getting a grip on Cynefin helped me to spot that very easily, but I laughed; of course I would never fall into Disorder myself!

The Story of the Green Screen

I can easily tell the difference between something that’s Complex and something that’s Complicated, and am very unlikely to treat the first as the second (Spoiler: all humans have bias). Of course, it helps that my preferred domain is Complex (like most developers).

Then one day, my photography screen arrived.

This screen turns up in a neat little circular bag, about a metre wide. When you take it out, you find three layers of circular wood, with some fabric smooshed together in the middle. As you unfold it, the wood starts to act as a kind of spring, and suddenly – Bang! – it pops out into a screen that’s 1.5m by 2m big.

Huge.

Far too big for my little flat! So I needed to put the screen back away in its bag again.

I’ve found that lots of us who have a preference for the Complex also don’t always read the instructions before trying something out. I wrestled with the screen a bit. I couldn’t see how to get it back into the bag again. The wood is incredibly springy, so it takes a bit of strength to bend it back into shape. After a few minutes, I realised that reading the instructions would probably be helpful.

The instructions made no sense.

So I went looking for a video that I thought might explain it to me. I found this one, in which three photography/video professionals attempt to do the same thing. It had me giggling for a few minutes. At least I wasn’t the only person who struggles with this! At the end of the video they finally get the screen away. I watched, but I couldn’t see exactly how they’d managed it.

Still, they managed it after several tries. Trying something – experimenting – is the right thing to do in the Complex domain! So I thought I should experiment a bit more. After all, it worked for them…

I wrestled with the screen some more. I twisted. I turned. I pushed, and let go of one side for just one second…

Thwack! The screen popped out, whacking me in the eye. I’m very lucky it only drove my glasses back into my face, skidding them up onto my eyebrow, rather than breaking them.

After a few tears and a bit of a tantrum (it’s OK to be unprofessional when you’re alone!), I patiently looked for another video that would help. After all, someone had done this before, and others must have had the same problem, the first time they did this. After some searching, I came across this site, where the kind Dr. Daniel C. Doolan shows us how to do it with a smaller reflector, from several different angles, before progressing to the screen.

Finally, having learnt from the expert, I followed his steps. It still took a bit of strength, but – Plop! – the screen collapsed back into its metre-wide circle again, allowing me to pop it back into its case.

Of course, I couldn’t record any videos that week, on account of my swollen and multi-coloured face.

We Are All Biased to Our Domain

The main problem with my “experiment” was that it really wasn’t. Experiments are safe-to-fail, and wrestling with wood without wearing any safety goggles was a bit negligent on my part. I’m sure if I had asked a Tester they would have spotted the possibility of accidents. Testers are very good at coming up with scenarios we haven’t thought of, and not just in software development! Applying Cognitive Edge’s Ritual Dissent might also have helped me spot the problem.

But really, we didn’t need a safe-to-fail experiment. I should have seen that the problem was predictable. People had done it before, and the fact that the screen came with a nice little bag to store it in should have told me that the solution was repeatable, and merely required expertise – and not very much, at that. Once I understood the trick, it reminded me a little bit of a Rubik’s Magic game, which I used to play with as a child. So this was definitely a predictable problem, and learning from the experts was the right thing to do.

Of course the real problem was my impatience, and my bias towards my own domain.

Some Hints and Tips for Avoiding Disorder

A short while back, I wrote a blog post on how to estimate complexity. I’ve found it does help to bring people out of Disorder. Particularly, I’ve found it useful to consider whether someone has solved a problem before, in the same or similar context, and whether their expertise is accessible. We developers do like to “reinvent the wheel”, but a lot of times it’s not really necessary when the problem has been solved before (Complicated). Project Managers and Scrum Masters often demand predictability where none exists, and recognizing that when nobody has done it before the outcome will be emergent can help us communicate the need for experiment (Complex).

Occasionally making sense of our domain is itself a complex process, because we’re human. So if you’re not sure which domain you’re in, here are my hints and tips for making sense of the domain safely.

• If you have several solutions and you don’t have enough information to be certain which one is right, pick the one that seems right and is safest and easiest to change. In a Complex domain this will be safest to fail, and in a Complicated problem with several solutions (Good Practices as opposed to Best Practice) chances are that the easiest to change is also the simplest to understand. If it turns out to be wrong (Emergent Practices) then you will have better information for making the right choice. This is Real Options 101.
• If you don’t know whether a solution exists or not, make sure that your experiment really is safe to fail. Ritual Dissent, Black Hat or Evil Hat thinking, and bringing problem-focused Testers into conversations are all useful ways of checking this.
• Try looking it up. Google, StackExchange, and our many ways of accessing the Lazyweb give us several fairly safe-to-fail experiments, right there.
• For those of you who love Chaos and prefer command-and-control, treating everything as an emergency, consider delegating to someone else when it isn’t. It’ll be less stress for everyone involved. And for the rest of us, remember that we tend to treat things this way when we’re stressed, because everything feels urgent. Let other people support you occasionally, especially if you’re feeling low on personal resourcefulness.
• Try bringing people who have different biases into your conversations. As far as I can tell, Testers and Myers-Briggs J-Types generally prefer Complicated domains; developers prefer Complex; children prefer things Simple; emergency services personnel specialize in dealing with the Chaotic. Their perspective can help. Yes, even (sometimes especially) the kids.
• Be aware of the bias of your own domain, and be forgiving of yourself when you get it wrong. You yourself are a Complex creature, and everyone fails occasionally, whether it’s safe to do so or not.

Like this? Want to know more? I will be running a workshop on BDD with Cynefin in Brisbane, 11th December, as part of Yow! Australia. Registration is still open!