Cynefin – The decision makers framework for software engineering

Semantically, complex and complicated are used in an interchangeable manner by most people. In fact there is a clear distinction! By examining the use of these two words, by a well regarded thought framework, the distinction becomes apparent. The Cynefin framework, originally by Dave Snowden of IBM Global Services, was proposed to assist with managing intellectual capital within IBM. It was used to offer decision-makers a sense of place from which to view their perceptions [1], [2].

Cynefin describes five “contexts” – five different types of problems. These are: Obvious (Simple), Complicated, Complex, Chaotic (Chaos) and Disorder. As part of identifying these problems, the framework also suggests how to deal with these differing types of problems.

Simple / Obvious

A simple type of problem; is just that – simple / obvious. Cynefin recommends the actions of: Sense, Categorize and Respond. From a software engineering point of view, a simple problem could be solved using best practices and the Waterfall Model of software development. Sense – to observe the requirements of a project. Categorize – the requirements and find the best practices to solve the problem. Respond – by using those best practices to complete the project. The key to obvious problems is to make use of Best practices to solve existing problems. Simple/Obvious problems make use of templating and off-the-shelf tools and solutions that solve existing problems. These problems are easily solvable and heavily automated.

Complicated

Complicated problems expand upon the notion of simple/obvious, but are now “complicated”. Cynefin recommends the strategy of Sense, Analyze and Respond. Sense – estimate the requirements of a project. Analyze – instead of categorize the requirements and use best practices, use existing good practices or “near enough” solutions. Respond – by tailoring those good practices and near enough solutions, with minor tweaking, to solve the problem. Complicated problems use Good practices to solve problems. For software engineering, complicated problems can be seen as maintaining a large existing code base. Or can be seen as tailoring an off-the-shelf enterprise business software solution to meet a particular use case. Good practices and procedures exist, workflows exist, industries and companies make their business on complicated problems. There is an overlap between Complicated and Simple/Obvious because both sets of problems are deterministic.

Complex

Complex problems are non-deterministic and are only deterministic in hindsight. This means that the strategy to deal with these problems changes. Cynefin recommends the strategy of Probe, Sense and Respond. Probe – estimate the requirements of a project and add features. Sense – get feedback on those features, understand blockers, get a sense of future features. Respond – respond to change, discover emergent solutions and iterate on working software. If any of this sounds familiar, it is because the strategy of Complex problems is incredibly close to the approach of the Agile model of software development. Complex problems are the majority of the type of problems found, in say a Research and Development Lab or Startup. There are no existing immediate solutions. Good practices can be applied to the software development process but not always used in the solution. The key to solving these problems are Emergent solutions, usually found after working through a problem over a period of time.

Chaotic

While the majority of problems software engineers may face, fall into the Complex and/or Complicated contexts, there is still another context to explore: Chaos. A strategy for Chaotic problems is Act, Sense and Respond. Like Complex problems, Chaos is non-deterministic.Chaotic problems are just that: complete and utter chaos. This context usually comes about due to an emergency and the best course of action is to reduce the problem back to a Complex or Complicated one. Therefore, in Chaos, all you can hope to do is Act – do something! Do some novel action to change the situation. Sense – to see if that action has solved or changed the problem, or at least resolved the emergency. Respond – if not successful, respond and if need be Act again. Chaotic problems pop up from time to time in software engineering and I’m sure everyone has the odd story about how a Novel solution fixed the problem.

Disorder

The final context is Disorder. In fact it is not a context. Rather, Cynefin describes Disorder as the application of an inappropriate strategy for the incorrect problem. Disorder borders each context, because at any given time we are always bordering disorder.

Conclusion

Cynefin is a well regarded thought framework. It has been applied to a number of different domains, industries and problems. It proposes simple strategies to solve different types of problems. For software engineering, it can help to identify the correct approach to solve differing types of problems. As a thought exercise, Cynefin is useful for the distinction and breakdown of of complicated and complex problems. Complicated problems involve determinism, where solutions are “predictable”. Complex problems are non-deterministic, where the solution is only available in hindsight.

References

1. Snowden, David J.; Boone, Mary E. (November 2007). “A Leader’s Framework for Decision Making”. Harvard Business Review, 69–76. PMID 18159787. Link
2. Browning, Larry; Latoza, Roderick (31 December 2005). “The use of narrative to understand and respond to complexity: A comparative analysis of the Cynefin and Weickian models”, Emergence: Complexity and Organization, 7(3–4): 32–39. Link