Simple, Complicated, Complex, and Chaotic Systems: The Cynefin Framework

Perhaps you’ve previously encountered concepts such as complex systems, complicated systems, or complex adaptive systems, for instance when reading Jurgen Appelo’s Management 3.0, or when considering Ken Schwaber’s thoughts on the applicability of Scrum. This might sound intriguing, but it can be difficult to find logical sense in it if one lacks a certain theoretical foundation. This is where it’s worthwhile to examine Dave Snowden’s concept called Cynefin, which is based on complex systems theory, anthropology, evolutionary psychology, and cognitive psychology.

What is Software Development About?

For nearly forty years, those interested in software development have pondered what it truly is, what it can be compared to, and what type of issue it represents. Initially, classical thinking associated with management from Ford’s factories was applied (think hierarchies, divided work, specialization, and plans). This, unfortunately, didn’t work well. Likewise, the metaphor of comparing software creation to designing and building buildings was not entirely applicable. Agile thinking went further, assuming that change is a natural part of projects. Technologies change, requirements change, and the people we work with change (which is quite natural in projects that span several months or years). Thus, the approach to project execution should account for this change and adapt to it. This is how various Agile methodologies, including the currently most popular Scrum, were developed. Sometimes they worked, sometimes they didn’t. This led to a search for a theoretical foundation that would explain why Agile works at all, along with clear criteria for when it’s worth considering its application and when it is not.

The Cynefin Framework

The Cynefin concept mentioned earlier can help here and is a model for ordering domains of problems and the adequacy of applied approaches. The basis for this model is the relationship between cause and effect. The following areas of complexity for problems (systems) have been distinguished:

• Simple: These are systems where the cause-effect relationship is straightforward. Well-recognized and described domains where knowledge is available, and where problems do not require complex interpretation or experience, belong to this category. For example, if you’ve just acquired a new phone and you set it up according to the user manual, you’re dealing with a simple domain (provided the manual suffices). In this area, all recipes, best strategies, and models that can be directly applied in practice are located.

• Complicated: These systems have a cause-effect relationship, but it’s not easy to detect. They often require expert knowledge, substantial experience, and complex analysis to solve problems in the domain. Furthermore, this system is static or at least not rapidly changing (variability can be anticipated and analyzed). Examples include a watch, a car, or a house. They are static, but to create or fix them requires expert knowledge.

• Complex: Systems where there are no straightforward connections between cause and effect, as they change over time. They can be understood through experiments and efforts to discern the current state. Expert knowledge does not provide clear answers but can serve as a basis for deciding the direction of explorations. Such a system is living, organic, and changeable over time. Typically, wherever we deal with people, we are dealing with complex systems. Complex systems also include the stock market, the brain, the immune system, and communities.

• Chaotic: Systems where there are no connections between cause and effect. They cannot be discovered because they aren’t there. All emergency situations, fires, and disasters are examples of such systems.

• Disorder: This is a situation where we can’t determine the type of system we are dealing with.

What’s the Connection with Software Development?

Let’s provide some examples. We deal with a simple system when considering first-line support. The client calls because they don’t know how to add a new lead in CRM. The first-line worker guides the client and helps solve the problem (which the client could wahrscheinlich solve independently if they spent more time on it).

In another scenario, you want to install additional software on a PC. It turns out that it requires drivers. You download them, install them, and it works. This is an example of a problem from a simple system. But suppose that you’re dealing with a Linux operating system, and installing drivers requires recompiling the kernel. This is beyond the capabilities of a layperson. Clearly, we enter the realm of a complicated system.

In programming, much of our work involves complicated systems. Configuring a container, a build system, authorization, and authentication are examples of expert knowledge needed to construct software. Essentially, in their basic form, design and programming are also complicated systems. However, it’s not always apparent. If you consider a scenario where you’re programming for yourself, being the source of requirements, writing a piece of code that can be done within several hours, and your code won’t be dramatically modified, then it is a complicated system. Or even in situations where we consider long-term and non-trivial ventures (several months to a year), and we’re lucky because our requirements are fairly well-defined, documented, and don’t change, we are still dealing with a complicated system.

Speaking of maintenance, we can also talk about a complicated system, provided the maintained system doesn’t significantly evolve (the work mainly involves bug fixes).

If, however, this is not the case—requirements change and are refined during the project, people involved in the project change, then we deal with a complex system. In that case, programming - the emerging design and code as a consequence - should also be considered in the category of complex systems. It’s pretty clear that a large part of programming projects falls into this category.

Of course, a portion also falls into the category of chaotic systems—where there are no operating rules, the team works ad hoc, and the work mainly involves firefighting. That’s a scenario of chaos, both literally and figuratively.

What Can Be Taken from This?

Indeed. The theory is the theory. But the question remains—why bother with all this? According to the Cynefin Framework, once we determine the type of system we’re dealing with, we can choose the appropriate tools for the context. These means include:

• Main strategy
• Leader’s actions
• Tools

Practically no project is purely one form. Types of contexts are mixed together, but usually, a dominant type exists. If we deal with a dominating simple or complicated system, tools from the PMBoK family will be useful. If we deal with complicated or complex systems, tools from the Agile, Lean/Kanban family will be useful (with a note that, in its original form—Lean Manufacturing is primarily a tool for complicated systems, providing additional means to organize the problem domain).

In Conclusion

As we have seen, Cynefin offers us a way to view the complexity of problems we encounter. It divides them into four main areas, suggesting possible actions in these areas. This way, we understand that a self-organizing team may not be the best solution in every software project, and when there is significant chaos, hard-handed management (command-and-control) will be best. Chaos can result from frequent and unpredictable changes in the project, people, or be a natural consequence of poor team skills. Conversely, in predictable environments, we don’t necessarily have to force ourselves to use Agile, claiming it’s the only right solution. Conversely, using classical methodologies will be inefficient for complex projects.

However, Cynefin is not just this model. It also encompasses a range of strategies that can be applied, particularly in complex domains, but that’s another story.

Of course, the model itself doesn’t provide definitive answers. Even its creator, Dave Snowden, has doubts about how to categorize some issues related to agile methodologies, which you can track on his blog. Nevertheless, it’s still an interesting perspective worth considering in your decision-making process.

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)