The Cynefin Framework was developed by Dave Snowden back in 1999, and has since then been used in numerous situations and businesses to describe problems, situations and systems. The Cynefin Framework is a practical application of complexity theory to management science. The framework helps managers determine the prevailing operative context, enabling appropriate choices and decisions (ref Wikipedia).
The never ending religious discussion of agile vs. waterfall can hopefully be a little bit more nuanced seen in the context with the Cynefin Framework
Theory behind the Cynefin Framework
Wikipedia summarize this from Dave Snowden in “Multi-ontology sense making – a new simplicity in decision making” from Informatics in Primary Health Care 2005:13:00.
The Cynefin framework has five domains. The first four domains are:
- Simple, in which the relationship between cause and effect is obvious to all, the approach is to Sense – Categorise – Respond and we can apply best practice.
- Complicated, in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge, the approach is to Sense – Analyze – Respond and we can apply good practice.
- Complex, in which the relationship between cause and effect can only be perceived in retrospect, but not in advance, the approach is to Probe – Sense – Respond and we can sense emergent practice.
- Chaotic, in which there is no relationship between cause and effect at systems level, the approach is to Act – Sense – Respond and we can discover novel practice.
The fifth domain is Disorder, which is the state of not knowing what type of causality exists, in which state people will revert to their own comfort zone in making a decision. In full use, the Cynefin framework has sub-domains, and the boundary between simple and chaotic is seen as a catastrophic one: complacency leads to failure.
Cynefin in the context of agile vs. waterfall
In real life several elements of a project are often considered (or planned for) as complex, when they in reality should be categorized as complicated. Why? Because with the right knowledge and expertise we can see the cause-effect through a thorough analysis! In many cases the complicated falls into the complex category due to limited knowledge of the team members, and in my opinion they then still belong in the complex domain since we can’t conclude/design/decide upfront since we will only see the full effect and be able to see the cause-effect in retrospective!
Before we go into details on agile vs. waterfall, we also need to consider other aspects that are closely related to both the Cynefin Framework and development cost, namely the Cost of Change. If you have never seen the Cost of Change curves, I recommend this article: http://www.agilemodeling.com/essays/costOfChange.htm. The Cost of Change is strongly dependent on the methodology used for development, as we in an agile project normally try to (or at least should!) address risk at at early stage and also stick to an early-knowledge strategy as described by Alistair Cockburn. By keeping these principles close, we can reduce risk, and at the same time keep the cost of change low! Especially for a complex system/subsystem (as described by the Cynefin Framework), it’s critical to keep cost of change low, as we know we will need several iterations to get full control of cause-effect. Whereas on the other hand a simple system/subsystem where the cause-effect are easier to see we might not need any extra iterations to reach our goal!
Most real life projects contains concepts/systems that fall into each of the categories, at least simple, complicated and complex. Meaning some parts of the project will require several iterations whereas other parts will not need any iterations.
If you try to solve the whole project in a waterfall approach and do a BDUF (Big Design Up Front) you will not be able to handle complex problems without a rather high cost of change, unless you plan for design changes as the implementation starts. On the other hand you will probably keep the complicated and simple problems of the project in more control than what you would get in an agile approach.
If you on the other hand run the whole project agile, you will have a framework that is robust to handle complex problems, but you might have some overhead for the simple (and maybe some of the complicated?) problems! Even though you could run a simple or complicated project agile, the real advantage comes in the complex domains, this is where agile really makes the difference!