A while back, I wrote about Cynefin, a framework for making sense of the world, and for approaching different situations and problems depending on how much certainty or uncertainty they have.

As a quick summary, Cynefin has five domains:

Simple / Obvious: Problems are easy to solve and have one best solution. You can categorise and say, “Oh, it’s one of those problems.”

Complicated: Often made up of parts which add together predictably. Requires expertise to solve. You can analyse this problem if you have the expertise.

Complex: Properties emerge as a result of the interactions of the parts. Cause and effect are only correlated in retrospect. Problems must be approached by experiment, or probe. Both outcomes and practices emerge.

Chaos: Resolves itself quickly, and not always in your favour. Often disastrous and to be avoided, but can also be entered deliberately (a shallow dive into chaos) to help generate innovation. Problems need someone to act quickly. Throwing constraints around the problem can help move it into complexity. Practices which come from this space are novel.

Disorder: We don’t know which domain dominates, so we behave according to our preferred domain (think PMs demanding predictability even when we’re doing something very new that we’ve never done before, or devs reinventing the wheel rather than getting an off-the-shelf library). Often leads to chaos when the domain resolves (I know least about this domain, but it’s way more important than I originally thought it was!)

By looking to see what kind of problems we have, we can choose an appropriate approach and avoid disorder.

However, we can also use BDD in conversation as a sensemaking technique!

BDD uses examples in conversation to illustrate behaviour. We sometimes call those examples scenarios, but really they mean the same thing. My favourite technique for eliciting examples is just to ask for them: “Can you give me an example?”

If the scenarios are imminent and dangerous, and we want to avoid them, we’re probably in chaos – and honestly, you won’t be having a “huddle” or a “scenario-writing session”; you’ll be having a hands-on emergency meeting. You’ll know if you’re in chaos. Don’t worry about talking through the scenarios any more. Get people who know how to stem the blood-flow into the room and throw some constraints around the problem like a torniquet (shut down that problematic server, or put up a maintenance page, or send an apology to your customers).

If the scenarios are causing a lot of discussion, and people are looking worried or confused, it’s probably because you’re in complexity. BDD is essentially an analysis tool, and analysis doesn’t work in complexity. You’ll see analysis paralysis, in which people try to thrash out various outcomes, and every answer generates yet more unanswered questions. As a check to see if you’re really in this space, ask, “Are we having trouble analysing this because it’s so new?” If so, see if you can think of a way to spike or prototype the ideas you’re generating, as cheaply as possible, so you can start getting feedback on them rather than deciding everything up-front. These are the 4s and 5s on my complexity estimation scale. We want to do these as early as possible, because they carry the most risk and the most value, so it’s very important not to push back on the business for clear acceptance criteria here! That will just end up pushing the riskiest requirements towards the end of the project, when we have less time to react to discoveries.

If BDD is working well for understanding the problem and gaining expertise in the business domain, you’re probably in complicated territory. Fantastic! BDD will work well for you here. People will be interested, and asking questions about scenarios generates a few more scenarios and helps create a common understanding. This is a 3 on the complexity estimation scale. Don’t forget to get feedback quickly anyway, because we’re all human and we all make mistakes. I tend to get devs to write the scenarios down, either during or after the conversations, since they can then get feedback on their understanding (or lack of it) early, before they even write any code.

If people are getting bored with discussion around scenarios, look to see if the problem is well-understood, or very similar to something that the team is familiar with. This is either a 2, which means it’s on the border of complicated and simple, and well-understood by people who work in that business domain, or a 1, which means it’s simple and obvious and easy to solve. You can always use Dan North’s “Ginger Cake” pattern here. Find a chocolate cake recipe that’s similar (“log in like Twitter”) and replace the chocolate with ginger (“but make them upload a photo instead of creating a username”). I find it enough just to name the scenarios here, without going into the actual steps. As a check, you can ask, “Is there anything different about <scenario> compared to <the other time we did it>?” That will help flush out anything which isn’t obvious.

The most important part of using BDD this way is to pay attention to people’s spoken and body language – bored, interested, worried or panicked, depending on the domain you’re in. I find BDD particularly good for locating the borders of complex/complicated and complicated/simple, and isolating which bits of problems are the most complex. And that’s how I use BDD across all the Cynefin domains, including the ones in which it doesn’t work!

(I’ll be teaching this and other BDD / Cynefin techniques as part of the BDD Kickstart open course with Cucumber founder Aslak Hellesøy in Berlin, 22 to 24 October – tickets available here!)