Every few months someone announces that Agile is dead—this season the culprit is AI and Spec-Driven Development. The milder version says SDD is the “real Agile.” Both make the same mistake: they flatten ideas that live on different layers into a single opposition.

I prefer a layered map. A map will not choose your process for you. It will stop an argument that never needed to start.

Name the confusion

“Agile” is overworked. Sometimes it means values, sometimes Scrum ceremonies, sometimes “we have Jira.” Lean suffers the same fate: Toyota-inspired thinking for some, a WIP limit on a board for others. SDD adds another muddle—treated as a new project-management framework by some, as a return to big upfront design by others.

When terms share one plane, conclusions go soft. A better habit is to ask: which layer is this sentence trying to answer?

Three layers

LayerQuestion it mainly answersTypical members
ValuesWhat do we care about? How do we choose?Agile, Lean
Activity frameworksHow does the team collaborate? How does work flow and sync?Scrum, Kanban, Scrumban
Work-item deliveryHow is a single change expressed, built, and accepted precisely?SDD (alongside practices such as TDD and pairing)

This is a working map, not a genealogy. Agile and Lean intertwine historically; Kanban carries clear Lean DNA; Scrumban is not a third “official” standard. The point of the layers is simpler: change the layer, and the question changes.

The map also sits comfortably with this site’s AI4SE layered technology model: activity frameworks lean toward Process; SDD toward Methods; the values layer is the language of trade-offs above both.

Values: Agile and Lean

The Agile Manifesto is first four values and twelve principles. It says that, under uncertainty, you bias toward working software, human collaboration, and responding to change. It does not require Sprint Planning.

Lean is likewise a way of seeing: follow customer value through the whole stream, reduce waste, respect people, improve continuously. In software it also yields operable mechanisms—value streams, pull, WIP limits, shorter feedback. Calling Lean “only values” undersells it; equating Lean with “we installed a board tool” oversells the tool.

What they share is a language for judgment, not a duty roster. A team can be both agile and lean; it can also quote the manifesto while waterfall governance chokes the stream. Values do not become process by proclamation.

Activity frameworks: Scrum, Kanban, Scrumban

At this layer the focus shifts to how people work together and how work items move through the system. Frameworks attend to both people and stuff.

Scrum leans on cadence and commitment. Roles, events, and artifacts give a fixed sync structure: plan, inspect, and adapt inside a timebox. It answers how a team regularly aligns and produces an inspectable increment amid complexity.

Kanban leans on flow and constraint. Visualize work, make policies explicit, limit WIP, manage flow. It answers how work can move at a rate the system can sustain—and where it gets stuck. Kanban is often Lean thinking made concrete for knowledge work, yet it remains an activity-and-policy framework, not the values layer itself.

Scrumban is a hybrid, not a third value system. Common shapes keep some Scrum rhythm or events while adopting Kanban’s visualization and WIP discipline; mixes vary, and there is no single orthodoxy. Agile Alliance and industry practice treat it as an evolutionary path or tailored blend, not a new denomination.

The three differ a lot, yet they share one job: organize collaboration and flow. They usually do not prescribe how precise a specification must be inside a single work item—that is the next layer.

ScrumKanbanScrumban
Primary knobsTimebox, roles, inspection cadenceFlow, WIP, explicit policiesA mix of cadence and flow
PeopleClear accountabilities and eventsImprovement via policies and collaborationBorrow structure from either side as needed
Work itemsCommitment and increment inside a SprintPull across a value streamBoth

Work-item delivery: SDD

Spec-Driven Development answers a different question: for a single work item—a requirement, a change, an acceptably thin slice—how do we make intent clear enough that humans and agents can implement and verify against it?

The habits are plain: spec first; pass a gate before building; change the spec before the code; keep the spec readable by people and machines. When Thoughtworks discusses SDD among AI-assisted engineering practices, the useful reminder is that it need not become waterfall—specs can evolve in small steps, and feedback should stay short.

Two confusions are worth separating from the framework layer:

  1. Compatible, not a replacement. Items on a Sprint Backlog or Kanban cards can (and should) pass a Spec gate before pull or commitment. Whether you keep Scrum is largely orthogonal to whether you practice SDD.
  2. The grain got harder. In the classic Agile era, a user story plus hallway conversation was often enough for people to deliver. Agents tolerate ambiguity poorly. “As a user, I want…”—if that is all you have—feeds a high-speed copier more than it practices SDD. Batches can stay small; small batches are not obsolete. What changes is that intent inside the batch must be reviewable and verifiable.

SDD concerns how work is stated and delivered. It does not decide whether you have a Scrum Master, or how many columns your board needs. Those are framework-layer design choices.

How the layers stack

A usable composition looks like this:

Values:      Agile / Lean supply the language of trade-offs
                ↓ guide
Frameworks:  Scrum / Kanban / Scrumban organize collaboration and flow
                ↓ carry
Delivery:    card / backlog item → Spec gate → build → accept against Spec

In Scrum, Spec review can sit before or inside Sprint Planning; ungated items do not enter the commitment. In Kanban, Spec readiness can be an explicit column policy or pull criterion—WIP still limits how many items are in play; SDD limits whether the one you start is clear enough. In Scrumban, use both: keep the sync points you need, and use flow discipline plus Spec gates to avoid busy futility.

For leads, the practical payoff is cheaper conversation. Too many ceremonies? Framework layer. Agents thrashing? Check whether work items cleared the Spec gate. Fast delivery that customers do not feel? Return to values and the value stream—not another AI plugin.

For practitioners, the payoff is that you need not burn the board to adopt SDD. Making every item that enters “In Progress” carry an acceptable Spec usually beats arguing whether the team “is Agile.”

Anti-patterns

  • Using SDD to dismantle Scrum (or any framework). Spec precision will not create cross-person sync or flow visibility; removing the framework usually just moves the mess upstairs.
  • Reading Kanban as “no planning.” Limiting WIP and managing flow is discipline; a board without policies is a sticker wall.
  • Treating Scrumban as a third value system. It is a hybrid configuration at the framework layer, not a new creed.
  • Feeding agents story-point grain. Points estimate relative size, not executable intent; sizing is not a substitute for a spec.
  • Equating a giant Spec with “more Agile.” Oversized specification batches lengthen feedback—waterfall in markdown clothing. Small batches still apply; what changes is clarity inside the batch, not a mandate to make batches larger.

Closing

Agile and Lean help you judge what “better” means. Scrum, Kanban, and Scrumban put people and work items into a sustainable structure for collaboration and flow. SDD makes each item moving through that structure clear enough to deliver—and when agents do much of the building, that clarity shifts from nice habit to structural necessity.

They do not fight on one plane. Draw the layers, and many arguments thin out. What remains are the design choices actually worth making.

References