The Cynefin framework (pronounced "ku-NEV-in," from Welsh for "habitat") was developed by Dave Snowden at IBM in 1999. It is the most useful sense-making tool available to Scrum Masters and Product Owners — yet it appears in almost no Agile certification content. CREA-SM is an exception.
The Five Cynefin Domains
| Domain | Nature of problem | Decision approach | Agile fit? |
|---|---|---|---|
| Clear (formerly Simple) | Cause and effect obvious; best practice exists | Sense → Categorise → Respond | Low — process/checklist works better |
| Complicated | Cause and effect knowable with analysis; expert knowledge needed | Sense → Analyse → Respond | Medium — structured iteration |
| Complex | Cause and effect only visible in retrospect; multiple right answers | Probe → Sense → Respond | High — Agile was designed for this domain |
| Chaotic | No discernible cause-effect relationship; crisis mode | Act → Sense → Respond | Very low — stabilise first, then adapt |
| Disorder | Cannot determine which domain applies | Break into sub-problems | N/A |
Why This Matters for Agile Practitioners
Agile was designed for the Complex domain — environments where requirements emerge through use, solutions cannot be defined upfront, and experimentation is the only way to learn. When organisations apply Agile to Complicated or Clear domain problems, they add overhead without benefit. When they try to apply Waterfall to Complex domain problems, they fail because the assumption of knowable requirements is false.
Practical Applications for Scrum Masters
Handling Stakeholders Who Want Upfront Estimates
When a stakeholder demands a fixed 12-month delivery plan for a complex product, Cynefin gives you the language to push back: "This problem is in the complex domain — cause and effect only become visible through delivery. A fixed plan assumes we know what we don't yet know. Here is what we can commit to: a 3-month outcome target, a sprint cadence, and regular checkpoint reviews."
Retrospective Facilitation
When a team is stuck on the same impediment across multiple retrospectives, check which domain the problem lives in. If it is complex (e.g. "how do we improve cross-team collaboration?"), experiments and safe-to-fail probes are the right intervention — not root cause analysis and a corrective action plan (which works in the complicated domain).
Backlog Prioritisation
Clear-domain backlog items (well-understood technical tasks) can be estimated and planned precisely. Complex-domain items (new features with uncertain user adoption) should be treated as hypotheses with success metrics, not as tasks with fixed estimates. Product Owners who apply this distinction make better prioritisation decisions.
The Danger Zone: Complacency
Snowden identified a particular failure mode: treating Complex problems as Clear. Organisations that have "solved" something once tend to treat it as settled best practice — even as conditions change. This is the Cynefin "cliff edge" — a sudden fall from Clear into Chaos when the best practice stops working in changed conditions. Agile retrospectives are one of the mechanisms that prevent complacency by continuously testing whether current practices are still producing good outcomes.