Why Agile Exists: Navigating Complexity With the Cynefin Framework
This is the third post in our series on agile ways of working. Part 1 dismantled the common misconceptions. Part 2 explored the frameworks. This post asks the deeper question: why does agile exist at all?
The answer has nothing to do with software.
Agile exists because complex environments don't respond to detailed upfront plans. They respond to short feedback loops, empirical learning, and the humility to change course when reality doesn't match your assumptions. That was true before software existed and it will be true long after today's frameworks have been replaced.
The tool that makes this clearest is the Cynefin framework. And getting it wrong, treating a complex problem as if it were merely complicated, or a clear one as if it were complex, is the single most expensive mistake I see organisations make.
The Problem With Treating Everything the Same Way
Anyone who tells you they know exactly what will happen on an initiative is lying. But not everything is equally uncertain. Some work is genuinely predictable. Some is genuinely chaotic. Most sits somewhere in between.
The mistake is applying the same approach to all of it. Legacy project management treats everything as if it were predictable: specify it upfront, plan it in detail, execute the plan. Agile enthusiasts sometimes make the opposite mistake: treating everything as if it were complex, applying iterative approaches to work that would be better handled with a simple checklist.
The right question isn't "should we be agile?" It's "what kind of problem are we dealing with, and what does that demand?"
The Cynefin Framework
Cynefin (pronounced "kuh-NEV-in") is a sense-making framework developed by Dave Snowden, originally at IBM in 1999 and refined extensively since. It helps you understand the nature of the situation you're in before you choose how to respond.[^1]
This matters because the nature of the situation determines what kind of approach will work. Using the wrong approach doesn't just slow you down. It can make things actively worse.
The Cynefin Sensemaking Framework. Developed by Dave Snowden. Image credit: The Cynefin Co, www.thecynefin.co
The framework has four main domains and a central space. Each domain has a different relationship between cause and effect, a different type of constraint, a different category of practice, and a different decision-making approach.
Clear Domain
Constraints: Fixed. Practices: Best practices. Approach: Sense, categorise, respond.
In the Clear domain, cause and effect relationships are self-evident. The situation is stable, repeatable, and well understood. There is a right answer, and everyone can see it.
Think of a bicycle chain coming off, a password reset, or processing a standard invoice. The problem is easy to categorise ("it's one of those") and there is a known procedure to follow. Standard Operating Procedures, checklists, and automation belong here. This is where best practice genuinely applies, because the situation is constrained enough that one approach reliably works.
Agile is not needed in the Clear domain. A checklist is better than a Sprint.
The danger: Complacency. If you sit in the Clear domain too long without questioning whether conditions have changed, you can catastrophically fall into Chaos. This is one of Cynefin's most powerful insights: the boundary between Clear and Chaotic is a cliff, not a gentle slope. Organisations that assume their environment is stable and predictable when it isn't are the ones blindsided by disruption.
Complicated Domain
Constraints: Governing. Practices: Good practices (note: good, not best). Approach: Sense, analyse, respond.
In the Complicated domain, cause and effect can be discovered through analysis and expertise, but they are not self-evident. There are multiple valid approaches. You need someone who knows what they're looking at.
Think of a car that won't start. A mechanic can diagnose the problem because they have expertise and experience, but the answer isn't obvious to a layperson. Or think of financial analysis, architectural design, or regulatory compliance. The right answer exists, but it takes expertise to find it.
The key difference from Clear: there is no single best practice. Multiple good practices exist. The expert analyses the situation and chooses between them. Governing constraints set boundaries but leave room for judgment.
Some agile approaches are useful here, particularly where the analysis involves iterative exploration. But this is also where structured analytical methods, expert review, and traditional business analysis add genuine value.
Complex Domain
Constraints: Enabling. Practices: Exaptive practices (novel applications of existing capabilities). Approach: Probe, sense, respond.
This is where agile comes into its own.
In the Complex domain, cause and effect can only be understood in hindsight. The situation is emergent. What worked before may not work again. There is no right answer waiting to be discovered through analysis, because the answer doesn't exist yet. It has to emerge through experimentation.
Think of launching a new product into an uncertain market, transforming an organisation's culture, navigating a political stakeholder landscape, or adopting a new technology where nobody yet knows what good looks like.
The approach is fundamentally different from the Complicated domain. You don't analyse your way to an answer. You probe: run small, safe-to-fail experiments. Then you sense: look for emerging patterns in the results. Then you respond: amplify what's working and dampen what isn't. The constraints are enabling, meaning they create the conditions for good things to emerge without prescribing what those things should be.
This is why agile exists. Short iterations, frequent feedback, incremental delivery, retrospectives, the willingness to change direction based on evidence. These are all responses to complexity. They don't make complex problems simple. They make complex problems navigable.
The critical point: Analysis belongs in the Complicated domain. In the Complex domain, analysis is premature because you don't yet have enough information to analyse. You need to act first (probe), observe what happens (sense), and then decide what to do next (respond). Teams that try to analyse their way through complexity end up in paralysis or, worse, in false confidence based on incomplete data.
Chaotic Domain
Constraints: No effective constraints. Practices: Novel practices. Approach: Act, sense, respond.
In the Chaotic domain, there is no discernible relationship between cause and effect. The situation is urgent and unstable. Every second counts.
Think of a major production outage, a security breach, a building on fire, or a sudden market collapse. There is no time for analysis or experimentation. Someone must act immediately to stabilise the situation, then sense what's happening, then respond with a longer-term plan.
The famous example: the fire chief who survived a forest fire by burning a patch of grass and lying on it, so the fire passed around him. That was a novel practice born from desperation. It couldn't have been planned or predicted.
Agile frameworks don't apply in the Chaotic domain. What applies is decisive leadership, clear authority, and the willingness to act without complete information. Once the situation is stabilised, you can move it into Complex or Complicated and start using more structured approaches.
The Centre: Confusion and Aporia
At the centre of the framework sits the space where you don't yet know which domain you're in. Snowden distinguishes between two states here:
Confusion is the negative state: you're lost, you don't know what's happening, and you need to get out. The risk is that people default to the practices of their preferred domain. A project manager treats everything as Complicated and reaches for analysis. An agile coach treats everything as Complex and reaches for experimentation. Both can be wrong if they haven't first determined what domain they're actually in.
Aporia is the productive version: deliberate uncertainty, a pause before clarity, learning through exploration. This is where safe-to-fail experiments are designed and where assumptions are challenged before committing to an approach.
The most important human judgment in the entire framework happens here: determining which domain you're in before choosing how to respond. No AI system can do this reliably. It requires context, experience, and the ability to question your own assumptions.
Why This Matters for AI in 2026
The connection between Cynefin and AI adoption is one of the most practical applications of the framework right now. The Cynefin Co themselves published a piece in March 2026 specifically on where machines work best and why humans remain indispensable.[^2]
The mapping is straightforward:
In the Clear domain, AI excels. Automation, rules engines, and AI agents perform best when outcomes are known and variation is undesirable. Automate here with confidence.
In the Complicated domain, AI supports human expertise. AI can process large volumes of data, surface patterns, and draft analysis. But the interpretation, the judgment about what the patterns mean and what to do about them, belongs to the expert.
In the Complex domain, humans must lead. AI can help detect emerging patterns after experiments have been run, but it cannot design the experiments, cannot create meaning, and cannot exercise the moral and political judgment that complex situations demand.
In the Chaotic domain, humans act. AI has no model for what's happening and no basis for choosing the right action. Human leadership is essential.
The most common mistake organisations make with AI right now is treating Complex problems as if they were Clear: deploying autonomous agents into situations that require human judgment. The rogue agent incidents we're seeing, inbox deletions, unauthorised database changes, unexpected behaviour, are what happens when Complex or Chaotic problems get treated as Clear ones.
For a deeper treatment of this, see our post Humans in the Loop Is Not a Checkbox, which maps each Cynefin domain to practical guidance on AI deployment.
Choosing the Right Approach
Cynefin's value is not as a classification exercise. It's a decision-making tool. Once you understand which domain your work sits in, the right approach becomes much clearer:
Clear work needs procedures, checklists, automation. Agile adds overhead here. Keep it simple.
Complicated work needs expertise, analysis, and good practices. Structured methods, whether agile or otherwise, add value. This is where frameworks like DSDM and traditional business analysis earn their keep.
Complex work needs short feedback loops, safe-to-fail experiments, and the willingness to change direction based on evidence. This is where agile approaches, Scrum, Kanban, and principles-based working, are most valuable.
Chaotic work needs decisive action first, sense-making second. No framework helps here. Leadership does.
Most organisations have work in all four domains simultaneously. The skill is recognising which is which and resisting the temptation to treat everything the same way. A single team might have Clear operational tasks, Complicated technical challenges, and Complex strategic decisions all running in parallel. Each needs a different response.
The Real Reason Agile Exists
Agile wasn't invented because software is special. It was invented because the world is complex, and complex environments demand a different way of working. Short cycles, frequent feedback, incremental delivery, and continuous adaptation are not trendy management practices. They are rational responses to uncertainty.
The Cynefin framework makes this visible. It shows you why agile works where it does, why it fails where it doesn't, and why the answer to "should we be agile?" is always "it depends on the nature of the problem."
Get that right, and the choice of framework, tools, and practices follows naturally. Get it wrong, and no framework will save you.
Previous in this series: Agile Is Not What You Think It Is and Choosing the Right Agile Approach in 2026.
Related reading:
- Humans in the Loop Is Not a Checkbox - Cynefin applied to AI agent deployment
- The Best AI Strategy Is 200 Years Old - why empiricism works for technology adoption
- The PDCA Cycle: Why the Best Teams Learn Faster Than They Plan - the learning loop behind every agile approach
References
[^1]: Dave Snowden and Mary Boone, "A Leader's Framework for Decision Making," Harvard Business Review, November 2007. For current thinking on the framework, see The Cynefin Co.
[^2]: The Cynefin Co, "A Cynefin Framework Lens: Where Machines Work Best and Why Humans Remain Indispensable," March 2026.
Alun Davies-Baker is an agile coach, trainer, and the founder of Altogether Agile. He is an assessor for the Agile Business Consortium and a visiting lecturer at the University of Westminster. He helps organisations navigate complexity using empirical approaches grounded in Business Agility.