Cynefin Framework and Agile

Cynefin Framework

I remember hearing about the Cynefin framework for the first time from Mark McDonald when I started working for Appster, the company he co-founded. When I looked it up, it seemed like a categorisation model of dealing with problems/ solutions. I made a mental note to understand it better but forgot about it over time. I recently had an opportunity to attend a meet-up on Cynefin that prompted this blog post. Without claiming to have extensive knowledge about Cynefin framework, I would like to put forward a brief summary that is the result of my online research and crowd-sourced knowledge at meet-ups.

Cynefin is a Welsh word meaning the various factors in our environment that influence us. Google translates it simply to “habitat”. Cynefin Framework is a model devised by Dave Snowden to sort contexts based on their cause and effect relationship. Contrary to what I assumed early on, the Cynefin framework is a sense-making model, not a categorisation model. In a Sense-making model, the framework emerges from the data, while in a Categorisation model, the framework precedes the data. It’s a decision framework that helps you identify the solution approach when looking at problems/ situations at hand.

Based on cause-and-effect relationships, systems can be identified as one of the following:

  • Ordered systems (further broken down into Obvious systems and Complicated systems)
  • Complex systems
  • Chaotic systems

Obvious systems (previously called Simple systems) are those where the cause-and-effect relationship is conspicuous and easily understood. It is predictable and repeatable. For example, following a recipe for omelette du fromage (my staple breakfast lately) is a simple system (even though I always argue that cooking is more art than science). The approach in such a domain is to sense the situation/ issue at hand, categorise it into one of the previously defined situation types, and respond based on what is the best for this context. This is the realm of best practices.

Complicated systems are those where the cause-and-effect relationship, despite being present, is not conspicuous. The relationship here, in order to be uncovered, requires a dependence on experts. For example, diagnosing what’s wrong with a V-8 engine requires an expert. Yes, you can Google it based on the symptoms but that cannot replace years of expertise. The approach in such a domain is to sense the situation, analyse it, and then respond. This is the realm of good practices as there can be more than one practice that works well (unlike best practices in simple systems).

Complex systems are those where the cause-and-effect relationship can be revealed but only in retrospect. For example, the climate change crisis we are all witnessing falls partially in a complex domain as this is the result of our actions (and inactions) over decades that is now manifesting as freak storms, weird weather patterns, and random climatic conditions across the globe. The approach in such a domain is to probe what’s going on, sense the situation, and respond accordingly. This is the realm of emergent practices.

Chaotic systems are those where there is no relationship between cause-and-effect. Stabilising and getting out of chaos is the primary solution here. An example of this would be the scene from the movie Flight where (spoiler alert) Capt. Whip Whitaker (Denzel Washington) does the unthinkable by flying the plane upside down in order to stabilise uncontrolled descent. The approach in the chaotic domain is to act first, sense, and then respond further. This is the realm of novel practices.

Between the above 4 states lies the state of Disorder where one doesn’t know what type of causality is in play (“what the f*** is going on?”). In such a domain, one usually shrinks to his comfort zone and takes decisions based on what one thinks is best.

Now how does Cynefin fit with Agile thinking? During the days of Waterfall-based software development, it was assumed that extensively detailed software plans would result in successful projects. Some of these projects (which fell in the Obvious domain) were relatively straightforward and were successful indeed. Some of them were part of the Complicated domain and they were partially successful. The others which were part of the complex domain failed miserably – huge cost overruns, delays several times the original schedule, glaring mismatch with customer needs, etc.

Not only is software development complex (by-and-large), the prominence of the human factor makes it all the more so (sometimes even chaotic). Cut-and-dried recipes of the past do not survive today’s world of software development. This is why Agile stresses on being open to change and tweaking the plan as we go about it. A big-design-up-front (BDUF) causes more problems than it fixes. Because emergent practices would help deliver the right solution, it is imperative that we iterate frequently (while keeping the iterations short) as we continue to build the solution over time.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s