Cynefin introduce some new concepts, well for me at least. One of them is the use of constraints as a mean for systems. In Cynefin, which system you are in can be understood by looking at its constraints.
In Clear domain you have tight constraints, which means that you have low or no degree of freedom, you can’t make that many choices.
In Complicated domain you have governing constraints, which means that there are rules that restricts you, for example budget, government regulations, laws, etc. You have more freedom than in Clear but you are restricted.
In Chaos domain there are no constraints at all, everything is random.
In Complex domain you have enabling constraints. This was kind of a big mystery for me, I couldn’t at first understand what an enabling constraint may be. The other constraints you can get a pretty good idea on what it is by its name, but enabling constraints puzzled me. But, an enabling constraint is a constraint that restricts but at the same time enable, and is applied by a leader or someone else who have the ability and mandate to act on a team, preferably the team itself. This is where you gather the team and try to get a collective clear view of the problem in hope for emergence. So enabling constraints should enable the possibility for emergence. It might be a meeting, or a ritual of some sort, but you need many views or perspectives. Some seems to just line these up with the events in Scrum or SAFe. But the truth is that both Scrum and SAFe acts in Complicated or in liminal Cynefin, in the liminal space between Complex and Complicated. Usually Scrum and SAFe requires the task to be “figured” out and get a Story Point or an day/hour estimate before entering the Sprint. This means that there is no room for alternative solutions, i.e., you can’t probe or test other solutions and hence you have to move from the problem domain into the solution domain before a SP can be set. For some simpler tasks, this is just might work, for example in the Obvious domain, but when you want to test and find new ways of doing things this is not inherently obvious. The human brain is also known to match first-fit solutions and doesn’t consider best-fit solutions, that is, you will probably choose the first solution that comes into mind. That solution something that you have done before, something in your comfort-zone. So we have to move away from our comfort-zone and we need to probe, and test new ways. This is a context-sensitive task so it is up to you to decide how to do this. In my team we will start working with time-boxes in our sprints where we get time to explore. I do not believe this kind of work can be done in Backlog Refinement or Sprint Planning, I think we really need to get hands-on experience and try it for real, not letting it be some kind of on “paper-idea”. Maybe you can even divide your team in two and make parallell experiments. See how it goes. Remember, you will gain more knowledge in failing than in succeeding.