One of my favorite questions to ask a group of agilists is:
“Scrum or Kanban—Which should you use and why?”
I often get answers like this:
- “Scrum is for planned work. Kanban is for unplanned work.”
- “Scrum is for building new features. Kanban is for operations or production support ticket resolution.”
These answers are nonsense. Scrum and Kanban are not alternatives to one another. Let’s examine how this thinking developed—and then let’s blow it all up. Scrum and Kanban are far more flexible and usable than the false dichotomy in my trick question suggests.
Cynefin
The Cynefin Sense-Making Model, created by David Snowden in 1999, helps people understand problem-solving within specific contexts while making sense of their own and others’ behavior. Pronounce it “Kin-evin”—it rhymes with “Kevin.”
Cynefin is a Welsh word meaning “habitat,” chosen by Snowden to emphasize that problems exist in context, not isolation. The model helps people move beyond linear thinking to see that problem-solving is deeply tied to its environment.
Cynefin has five domains:
- Clear (aka Simple/Obvious)
- Complicated
- Complex
- Chaotic
- Disorder (aka Confusion)
Each domain calls for a unique approach to problem-solving. For example:
- In the clear domain, cause and effect are obvious, so you can identify the best solution quickly.
- In the chaotic domain, predictability is impossible—you just try something and see what happens.
This framework is often used in agile leadership circles to map different agile practices to problem-solving contexts.
Misusing Cynefin for Agile Practices
A common explanation links agile practices to Cynefin domains like this:
- Project management belongs in the clear domain (e.g., construction projects).
- Kanban fits the complicated domain (e.g., troubleshooting).
- Scrum belongs in the complex domain (e.g., emergent product development).
- Lean Startup is best for the chaotic domain (e.g., working with complete uncertainty).
While this might sound plausible, it doesn’t hold up.
Breaking the Myths
Kanban: Kanban isn’t tied to a specific type of work. Whether the unknowns are vast or the work is straightforward, Kanban is a flexible system for visualizing and managing workflow. Any team can use it for any kind of work.
Scrum: Scrum is excellent for solving complex problems with an empirical approach, as noted in the Scrum Guide (2020). But Scrum isn’t restricted to the complex domain. It can be used in chaos, complication, and even clarity. While Scrum is most effective when uncertainty is embraced, it works just fine for fixed-scope projects with a delivery date—its most common application.
Project Management: There’s an ongoing misunderstanding between Agile and traditional project management. Many project managers mistakenly equate Agile with Scrum or refer to “The Agile Methodology” (which doesn’t exist). Similarly, agilists often mischaracterize project management as synonymous with Waterfall.
Scrum can manage projects. A project manager can plan using techniques like rolling-wave planning, which can start looking very much like Scrum. The truth? Project management and agile practices aren’t adversaries—they’re tools that can complement one another.
Lean Startup: Lean Startup is undoubtedly relevant in the chaotic domain, where the future is a blank slate. However, its principles—early feedback, prototyping, and discovering market truths—also apply in the complex domain of emergence and experimentation.
Here’s the corrected seating chart: Agile practices don’t belong to fixed Cynefin domains—they move fluidly across them.
Scrum or Kanban? Why Not Both?
The question is moot. Scrum and Kanban aren’t mutually exclusive. A Scrum team can simultaneously follow the Scrum Guide and embrace Kanban principles.
For example, a Scrum team can use a Kanban board to visualize their sprint backlog and progress toward the sprint goal. By measuring cycle time, item aging, and controlling WIP, they’ve effectively become a Kanban team too. This way of working is called Scrum with Kanban.
Scrumban? Sure, you can call it that if you like.
When to Use Kanban Without Scrum
Scrum can create friction. When enacted fully, it shines a spotlight on organizational obstacles. Scrum’s output often involves the Scrum Master asking management to eliminate wasteful policies, pull more functions into the team, or give the team more authority.
If introducing Scrum risks political fallout, consider starting with Kanban instead. People seem to be more flexible in their thinking around Kanban. They usually accept that Kanban can be adapted to the existing status quo without the same level of disruption, making it a less risky first step.
There is nothing stopping you from introducing Scrum in steps the same way. In fact, it would probably be best to start with the minimal features of Kanban and then keep adding to it until you arrived at as much Scrum as your organization can stand. How to do this is a topic for another article.
The Real Answer
Scrum, Kanban, and other approaches are tools for enacting empiricism, lean thinking, and empowered teams. Which one to apply—and when—depends on how well you understand these principles and your courage to act on them.
