Navigating Contextual Complexity with Cynefin

TABLE OF CONTENTS

• Frameworks and Models
  • Cynefin, a Decision-Making Framework
  • Cynefin and Context
  • Cynefin's Impact on Processes

Frameworks and Models

A few weeks back, a friend asked me about the SDLC (Software Development Life Cycle) and its associated frameworks and models. I answered directly based on the context of the question. I mentioned the primary model that divides product development into discovery and delivery. I talked about delivery models, but I mainly focused on discovery.

Since the emergence of Agile software development and its associated practices, there has been a better understanding of what needs to be part of the delivery phase. However, the phase that demands our immediate attention and improvement is discovery. It's crucial to note that many product discovery frameworks have emerged in the last ten years alone, underlining the importance and relevance of this phase in our software development journey.

While I covered some of the most exciting product discovery frameworks, something was bothering me about my answer. After a recent blog post about BDD (Behavior-Driven Development) that I wrote, I realized there is a more nuanced answer.

Cynefin, a decision-making framework

In that blog post, I talked about Cynefin (pronounced kuh-nev-in). Cynefin is a decision-making framework. Cynefin means habitat. Dave Snowden created Cynefin in 1999. Cynefin offers five decision-making domains. The following diagram describes the domains:

SOURCE: Agility11. (2020, January 7). Understanding Complexity to Make Better Decisions: Cynefin Demystified. Retrieved from https://www.agility11.com/blog/2020/1/7/understanding-complexity-to-make-better-decisions-cynefin-demystified

Cynefin and Context

While Cynefin is a decision-making framework, the first thing it does is help you identify your context. In this case, the domain you are in right now. How do you do that? Liz Keogh has a heuristic she uses to help you get to that answer. It depends on the answer to the question: “Who has done this before?” Here are the potential answers:

Complex domain

5. Nobody has ever done it before.
4. Someone outside the organization has done it before (probably a competitor).

Complicated domain

3. Someone in the company has done it before.
2. Someone in the team has done it before.

Obvious domain

1. We all know how to do it.

Answer 1 puts you in the Obvious domain. For example, suppose you are in a team that has worked together for five years on the same application. When a customer finds a defect, most of the time, anyone on the team can handle the work in more or less the same time and way. That is only true for some defects customers find, but it is common in well-established products where everyone on the team knows the codebase.

Answers 2 and 3 put you in the Complicated domain. For example, suppose you are working on a new Payroll engine for the United Kingdom. If your team is unfamiliar with UK laws and regulations, you must find someone who is. In this case, it might be someone from the London office.

Answers 4 and 5 put you in the Complex domain. For example, if you work on an AI/ML team developing self-driving car software, you spend a lot of time in this domain. While Tesla fans will suggest there are self-driving Tesla cars everywhere, as a Tesla owner with an FSD (Full Self-Driving) system, I can confirm that is not the case.

Cynefin's Impact on Processes

You can follow the most straightforward process possible to complete the work in the Obvious domain. Liz Keogh says you can write user stories without BDD scenarios and complete the job. Per Dan North, in this domain, you optimize for efficiency.

In the Complicated domain, you need to develop a more refined process. By definition, you want to expand the number of people with the knowledge required to complete the work. Your product manager might do the heavy lifting of working with the London office to capture all the requirements for the UK payroll system. To ensure the information is widely available, you must document that information. If you want to make your code self-verifying regarding those requirements in your CI/CD pipeline, you will use something like BDD. Per Dan North, you optimize for repeatability.

At Testaify, we are building an autonomous software testing platform using AI/ML. Often, we find ourselves trying to resolve problems that no one in the organization knows the answer to. In other words, we spend a lot of time in the Complex domain. In our case, our competitors have yet to do what we are doing.

In that context, our process matches a typical research lab process. Someone needs to go and find out if someone outside the company has done work related to our problem and bring that information to the team. Usually, that means a paper or presentation sharing the findings. Sometimes, it means creating a prototype. To paraphrase Dan North, you optimize for discovery. We have too many unanswered questions and want to accelerate the speed at which we get answers.

Also, remember that you are trying to move from Complex to Complicated and hopefully make it to the Obvious domain. Imagine you are part of a team working on self-driving car software. Initially, you knew very little about it and spent a lot of time researching and building prototypes. Eventually, you will find good answers to some of the issues your team is tackling and move from building prototypes to implementing and testing. Finally, you feel comfortable implementing your solution in specific contexts, as Waymo did by rolling out their service only in San Francisco (and eventually Phoenix). In other words, it is moving from Complex to Complicated. There are still many aspects that fall within the Complex domain, but what you are trying to do is to move them to the Complicated domain so you can roll them out.

Applying the Cynefin framework to your software development journey is like having a versatile toolbox. Each domain of the framework corresponds to a specific context in software development. For instance, you might use user stories for straightforward tasks, a feature file with numerous BDD scenarios for complicated issues, or a framework with many experimental tools, like continuous discovery, for situations requiring innovation. This flexibility empowers you to choose the most effective approach for your context.

Remember, the choice of framework or tool in software development is not arbitrary. It's a strategic decision that should be based on your context. Understanding the Cynefin framework can help you confidently navigate these decisions, ensuring you always choose the most appropriate approach for your current situation.