Cynefin and how not to use a hammer all the time

For almost 20 years of my professional career I have struggled to find the best way to approach certain problems. It was something I always had concerns about – how to understand the context of a particular problem so that I could better see the full picture. 

In the game development industry, this is a huge issue as we tend to focus on very narrow solutions to specific problems, while at the same time ignoring the rest of the picture. In these situations, I have found that the Cynefin framework can be a very useful approach to adopt. 

Cynefin essentially depicts a safe place (or “habitat”) for people to help them in their decision-making process, and it raises many interesting thoughts. Here, I will discuss my own journey of discovery, explaining how I first came across this approach, and share some thoughts on how it has influenced my own perception. 

TYPES OF REASONING: BUILDING KNOWLEDGE AND INTUITION BY SOLVING PROBLEMS 

There are essentially three main approaches to solving a problem. First comes Deductive reasoning, where the solution to a problem comes as the result of a logical consequence – in other words, moving from a general rule to a specific conclusion. 

Next is Inductive reasoning (using a specific observation to reach a general conclusion), which is basically generalization, and often thought of as the source of all evil: “I know something, and I will assume that this solution is good for everything.”  

And finally, there is Abductive reasoning – or in other words, moving from an incomplete observation to an “educated guess”. Safe to say, this is the most common approach in our industry.  

Sometimes, the problem can be more complicated than usual. A good example of this is the Apollo space program – which we now know was a failure from the project management perspective.  

Although it was a huge success for humanity, it wasn’t from the management point of view as the budget and scope didn’t go as planned. 

WBS and waterfall models may seem perfect, but they’re all based on the assumption that if we do X, then the outcome will be Y. We usually make our assumption at the beginning of a project, and then after some time it turns out to be different. 

Imagine this situation with the Apollo project, and its huge scale. Project management-wise, it was a disaster – mainly because every ambitious space exploration and military project is prone to oversimplification. 

Many people thought long and hard about how to solve this issue – and the conclusion was that if we know around two weeks into the work that something is likely to break, maybe we should reduce the scope or timeframe of the project to just those two weeks. This idea was introduced, with the result being significant improvements in terms of control over a project’s scope and budget, but it still didn’t solve the problem of how best to deliver information from the person that possesses it to the one who must act on it. 

This problem led to the creation of the Agile movement, although the Scrum framework quickly started to go down the route of over-constraint. There is something called the theory of constraints (TOC), which states that if you have a complex system that you want to evolve somehow, the situation may arise where you put some constraints into it and you either block the flow completely – or it’s too broad and it just does whatever it wants. Agile gives us a false sense of security and understanding of the situation. 

So, what’s the solution? Well, firstly, you should bear in mind what your own personal inclination is: is it realistic idealism, pragmatism, ignorance, or dogmatism, or a mixture? 

Cynefin was an approach that helped me deal with the fact that I’m “dogmatic” – it helped me realize that maybe I shouldn’t plan everything, because not everything can be planned. 

A plan requires causation, so cause and effect must be linked for you to be able to plan accordingly. For me, that’s the basis behind this concept of “domains”, which enables us to use the proper tools to manage situations and solve problems based on the classification below. 

MINDSET: THE LEVEL OF COMPLEXITY MATTERS 

Clear domain: This is a simple situation representing the “known knowns”, where we have full clarity about the cause-and-effect relationship. For example, if I put certain ingredients into an ice cream machine, I know I’m going to get ice cream back. 

Complicated domain: Here we have the relationship between cause and effect, but it’s not so straightforward and it’s not a simple one-step process. The relationship is one-to-one, but we need a variety of sources to help us get to the end result. In software development, for example, there are often multiple specialists with partial knowledge, and it is only when they come together that they find the solution.  

Complex domain: There is no relationship here between cause and effect, and no way for us to draw a line between them as these relationships are a little more complex. As a result, there can be multiple ways of getting to the same point. In this case, we approach the problem differently – by doing a set of experiments and responding based on a small degree of research. 

Chaotic domain: “Chaotic” may not sound great, but it’s actually a very good situation to be in if you are able to control it somehow as this is when you have all the innovations and new ideas. This is where we have hackathons, and space for people to free their minds. For innovative companies, this is the most important thing to secure what is called a safe-to-fail environment. 

The strange shape in the middle of the diagram is also crucial here as it describes things which are oversimplified. So basically, it means that although we may assume that we know about a problem’s complexity, we can suddenly just fall off a cliff. And that’s what this shape basically represents – a cliff. 

PHASES AND DOMAINS 

These are simple classifications of what it means for people managing projects.  

This is a breakdown of the main phases that occur during the production of a game. In a nutshell, we have the concept phase, the pre-production phase, and the production phase. 

In an ideal world, we would have the production phase defined very precisely, but obviously it doesn’t always work out that way. That’s the end goal that I would like to have as a producer, however. 

Before that, I must allow the concept to emerge, and obviously we know that many games that are not exactly innovative can still sell very well, so maybe not every game has to be so innovative. Sometimes it can be enough if we simply combine certain things, and it will still be attractive – innovation essentially means something different, and different things are attractive for customers.  

And there is still a place in the concept phase where we can go a little wild. Once we deal with this slightly chaotic phase and do the pitch, we then have the concept phase when we have some sort of idea, before it goes to the pre-production phase. 

Here, we must start nailing down those things that we will have to deliver. At the end of pre-production, we would like to have a vertical slice – or at least a horizontal slice – so that we have something solid.  

We could have experience; we can judge the game as a whole and after that we just scale it up. This route is usually the most difficult one, and it’s usually the phase that goes deepest into the formal production phase as well. We don’t usually do enough pre-production phase because we must find discoveries smaller than those at the beginning. 

TAKEAWAYS 

• Context matters 
• Be mindful when choosing the suboptimal way 
• Accept that you don’t know certain things 
• Go deeper on a daily basis  

It is extremely important to understand that sometimes we must take the lesser evil when it comes to our choice of tools. Switching working methods is no trivial matter, though, which is why the second point is so important and why we need to be mindful when choosing the suboptimal way.  

For example, if we know that our team has the skill sets for working in a Scrum environment, we should utilize Scrum as much as possible because the price of switching, and then having to upskill the team to work in a different environment, would be too high. Also, we must be constantly mindful of where we are in terms of the domains discussed above. 

WATCH VIDEO: